Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005854OCamlOCaml generalpublic2012-12-14 14:102014-06-02 20:36
Reporterppedrot 
Assigned Tofrisch 
PrioritynormalSeverityfeatureReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version4.02.0+dev 
Summary0005854: Add a deprecated warning
DescriptionIt would be nice to be able to flag functions as deprecated directly in the source code, so that ocamlc/opt would spit out a warning when using such a function.

This would ease code maintenance a lot.
Tagspatch
Attached Filesdiff file icon patch_deprecated_5854.diff [^] (9,446 bytes) 2013-09-18 11:09 [Show Content]

- Relationships
related to 0006160confirmed disable shadowing warning for deprecated identifiers? 

-  Notes
(0008610)
gasche (developer)
2012-12-14 14:34
edited on: 2012-12-14 14:36

I guess it is currently possible to do that by inspection of the .cmt file spit out by the -bin-annot files: traverse AST in the .cmt and check for uses of deprecated functions; to be integrated in your compilation&test toolchain. To declare a function deprecated you could either just give the traverser-tool a list of deprecated functions, or use a hack to embed the annotation as valid OCaml source code (not what I would choose):


deprecate.mli
  type 'a t = 'a

in your code:
  let f = ... in
  ignore (f : _ Deprecate.t);


I'm not sure we want to integrate this ad-hoc feature directly in the language itself -- I'd rather wait until someone comes with a decent pragmas/annotations proposal. In the meantime I think a bin-annot-based tool could suit your needs.

(0009634)
doligez (administrator)
2013-06-28 17:33

This will certainly become easy to do when the extension_points feature gets integrated.
(0010372)
frisch (developer)
2013-09-18 11:21

Now that extension_points has been integrated, I've uploaded a patch against trunk which triggers warning 3 (Deprecated feature) when we refer to a value whose declaration (in a signature) has been marked with the [@@deprecated] attribute.

To make the information easily accessible to the type-checker (without forcing it to read .cmti files), the patch keeps the attributes in the Types.value_description records (and value descriptions coming from implementation, not interface, currently don't generate any attribute) which are stored in particular in .cmi files. After this patch, detecting a reference to a value marked as deprecated is indeed trivial.

Gabriel suggests a different approach, based on an external tool reading both .cmt files (to find value references) and .cmti files (to find value declarations). Unfortunately, finding the value declaration in a .cmti file corresponding to a value reference in a .cmt file is not absolutely straightforward: this amounts to redoing part of the symbol resolution strategy done by the compiler, which is not trivial. Consider for instance the case where the .mli file has an "include" statement: the .cmti file will contain only a symbolic Tsig_include item, and to find the real value declaration, we need to follow the link.

If we start giving some special meaning to a few attributes in the compiler itself, it makes sense, in my opinion, to keep attributes in .cmi files as well. Would anyone object to it? This is also related to the work on runtime types: it would be natural to keep (some) attributes on type declarations in the runtime description of types. This would also probably require to keep them in .cmi files.


(We could also question the relation between .cmi and .cmti files and maybe somehow merge them.)
(0010374)
gasche (developer)
2013-09-18 15:09

> Unfortunately, finding the value declaration in a .cmti file
> corresponding to a value reference in a .cmt file is not absolutely
> straightforward: this amounts to redoing part of the symbol
> resolution strategy done by the compiler, which is not
> trivial. Consider for instance the case where the .mli file has an
> "include" statement: the .cmti file will contain only a symbolic
> Tsig_include item, and to find the real value declaration, we need
> to follow the link.

Could we provide a facility to do just that in compiler-libs? I think
we have a blind spot around "referring to declarations" that we're
hitting from several different sides (this was also one of the major
aspects of the "integrate location information into
.cmi" discussion) -- and that has to be redone by ocamlspotter,
Merlin, ocp-index, etc..

(Do tell if you think it's a good idea but don't have the time or will
do implement it. We may ask the developers of those projects if
they've something that we could integrate.)
(0010381)
frisch (developer)
2013-09-20 18:31
edited on: 2013-09-27 19:03

> Could we provide a facility to do just that in compiler-libs?

This would certainly be useful (but indeed I don't plan to work on it). That being said, I don't think that the compiler should read the .cmt/.cmti files and redo some lookup in them; some features deserve to be incorporated in the compiler directly (warnings on unused or deprecated stuff, etc). But yes, external tools would need similar resolution logic and it would be useful to provide it somewhere.

(0010404)
frisch (developer)
2013-09-26 17:25

The patch has been integrated (commit 14188 in trunk).
(0010408)
frisch (developer)
2013-09-27 12:55

Commit 14191: also detect references to types or constructors marked as deprecated.
(0011569)
doligez (administrator)
2014-05-25 20:32

Please note: the name of the attribute was changed to [@@ocaml.deprecated].
(0011570)
frisch (developer)
2014-05-25 21:31

Actually, both deprecated and ocaml.deprecated are accepted (and similarly for all built-in attributes).

- Issue History
Date Modified Username Field Change
2012-12-14 14:10 ppedrot New Issue
2012-12-14 14:34 gasche Note Added: 0008610
2012-12-14 14:36 gasche Note Edited: 0008610 View Revisions
2013-06-28 17:33 doligez Note Added: 0009634
2013-06-28 17:33 doligez Target Version => 4.02.0+dev
2013-06-28 17:33 doligez Status new => confirmed
2013-07-12 18:15 doligez Target Version 4.02.0+dev => 4.01.1+dev
2013-09-11 22:12 doligez Relationship added related to 0006160
2013-09-18 11:09 frisch File Added: patch_deprecated_5854.diff
2013-09-18 11:21 frisch Note Added: 0010372
2013-09-18 11:21 frisch Assigned To => frisch
2013-09-18 11:21 frisch Status confirmed => assigned
2013-09-18 11:21 frisch Target Version 4.01.1+dev => after-4.02.0
2013-09-18 15:09 gasche Note Added: 0010374
2013-09-20 18:31 frisch Note Added: 0010381
2013-09-26 17:25 frisch Note Added: 0010404
2013-09-27 12:55 frisch Note Added: 0010408
2013-09-27 19:03 frisch Note Edited: 0010381 View Revisions
2013-09-27 19:03 frisch Note Edited: 0010381 View Revisions
2013-12-16 13:41 doligez Tag Attached: patch
2014-05-13 16:46 frisch Status assigned => resolved
2014-05-13 16:46 frisch Fixed in Version => 4.02.0+dev
2014-05-13 16:46 frisch Resolution open => fixed
2014-05-25 20:32 doligez Note Added: 0011569
2014-05-25 21:31 frisch Note Added: 0011570
2014-06-02 20:36 doligez Target Version after-4.02.0 =>


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker