Comment author: @alainfrisch

(Note for myself: dropping the "deprecated" attribute in Typedecl.enter_type should work.)

Comment author: @alainfrisch

I wonder if there isn't a deeper problem. Usually, if a deprecated type is exposed, operations working on it will also be exposed and be marked as deprecated, as in:

type t = ..... [@@ocaml.deprecated]
val f: t -> unit [@@ocaml.deprecated]

In such cases, the reference to t in "val f:..." will also trigger the warning when compiling the interface.

Fixing only the reported issue would have the effect that:

type t = int [@@ocaml.deprecated]
and s = A of t

would not trigger the warning while:

type t = int [@@ocaml.deprecated]
type s = A of t

would trigger it, which does not looks right.

A different direction would be to consider that all deprecation warnings apply only outside the signature where they appear, not when processing subsequent declarations in the same signature. I.e. deprecation markers are not kept in the type-checking environment (used for later signature items) but only in the synthesized signature.

Comment author: @alainfrisch

#1237

Comment author: @alainfrisch

Cf discussion on #1237. I reached the conclusion that there is no reason to special case self-references. Other heuristics were considered ((i) make the deprecated warning visible only outside the current signature/structure; (ii) automatically disable deprecation warning when processing a deprecated declaration) but rejected for now.

Instead, I've opened #1248 to allow a finer control of warning settings, including within type expressions, and, in fact, everywhere an attribute is allowed (with the natural scope). So it becomes straightforward, if needed, to disable warning 3 at the same time that marking a declaration as deprecated, as in:

  type t = A of t | B of t * t | C
     [@@ocaml.deprecated]
     [@@ocaml.warning "-3"]