Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

disable shadowing warning for deprecated identifiers? #6160

Closed
vicuna opened this issue Sep 5, 2013 · 3 comments
Closed

disable shadowing warning for deprecated identifiers? #6160

vicuna opened this issue Sep 5, 2013 · 3 comments

Comments

@vicuna
Copy link

vicuna commented Sep 5, 2013

Original bug ID: 6160
Reporter: @ygrek
Status: confirmed (set by @damiendoligez on 2013-09-11T20:12:29Z)
Resolution: open
Priority: normal
Severity: feature
Version: 4.01.0+beta/+rc
Category: typing
Related to: #5854
Monitored by: "Dmitry Grebeniuk" @hcarty

Bug description

Consider :

module Z = struct let (&) f x = f x end
open Z
let () = print_int & 10

4.01 will emit warning 44 on the above code :
Warning 44: this open statement shadows the value identifier & (which is later used)

The suggestion is to disable this warning when the shadowed identifier is marked deprecated..

@vicuna
Copy link
Author

vicuna commented Sep 11, 2013

Comment author: @damiendoligez

Unfortunately, this would be pretty hard to implement with the way the deprecated warning works now. It will probably have to wait until #5854 is implemented (and used for "or" and "&" in the standard library).

@vicuna
Copy link
Author

vicuna commented Sep 26, 2013

Comment author: @alainfrisch

Generally, we refrain from using brand new features too quickly in the compiler code base (to avoid headaches in case this feature change, and to avoid bootstrapping issues for people maintaining a fork of the compiler). Maybe this particular case could be an exception, given that it would be particularly easy to comment out the attributes if needed.

@github-actions
Copy link

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant