|Anonymous | Login | Signup for a new account||2016-09-27 22:46 CEST|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005854||OCaml||OCaml general||public||2012-12-14 14:10||2015-12-11 19:27|
|Priority||normal||Severity||feature||Reproducibility||have not tried|
|Target Version||Fixed in Version||4.02.0+dev|
|Summary||0005854: Add a deprecated warning|
|Description||It 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.
|Attached Files||patch_deprecated_5854.diff [^] (9,446 bytes) 2013-09-18 11:09 [Show Content]|
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):
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.
This will certainly become easy to do when the extension_points feature gets integrated.
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.)
> 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.)
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.
|The patch has been integrated (commit 14188 in trunk).|
|Commit 14191: also detect references to types or constructors marked as deprecated.|
|Please note: the name of the attribute was changed to [@@ocaml.deprecated].|
|Actually, both deprecated and ocaml.deprecated are accepted (and similarly for all built-in attributes).|
|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 => 4.02.1+dev|
|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||4.02.1+dev =>|
|2015-12-11 19:27||xleroy||Status||resolved => closed|
|Copyright © 2000 - 2011 MantisBT Group|