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

Provide a parametrized tags to fix the default warnings "as in version X" #6873

Closed
vicuna opened this issue May 16, 2015 · 6 comments
Closed

Comments

@vicuna
Copy link

vicuna commented May 16, 2015

Original bug ID: 6873
Reporter: @gasche
Status: acknowledged (set by @damiendoligez on 2015-06-15T15:25:44Z)
Resolution: open
Priority: low
Severity: feature
Category: compiler driver
Monitored by: @hcarty @dbuenzli

Bug description

In
#147 (comment)
Thomas Leonard suggests a parametrized tag warning_target(4.02) that would set the warnings as is per default on version 4.02 -- combinable with specific warn(..) specifications overriding said defaults.

This would help people progressively migrate their code to new warning conventions, without being obsessed with doing this as soon as the next version gets some adoption.

@vicuna
Copy link
Author

vicuna commented May 16, 2015

Comment author: @gasche

Note that this might be done upstream under some form of direct command-line support for compilation invocation (instead of transforming these to more precise warning sets at the ocamlbuild level), but I'm not sure what a good command-line interface would be, and whether the compiler-frontend maintainers would appreciate the corresponding maintenance burden.

@vicuna
Copy link
Author

vicuna commented May 16, 2015

Comment author: talex

Note: my suggestion was for a slightly more general "target(4.03)" tag, which means that the tagged code has been updated for 4.03 and the compiler should use default to whatever options were judged best for that release (e.g. -safe-string and -use-ocamlfind, in addition to any new warnings). Currently, OCaml has various sub-optimal defaults, in order to avoid breaking old code.

@vicuna
Copy link
Author

vicuna commented May 16, 2015

Comment author: @dbuenzli

@gasche Upstream support is clearly better, this allows all build systems to benefit and support the feature in a consistent fashion.

@vicuna
Copy link
Author

vicuna commented Jun 15, 2015

Comment author: @damiendoligez

Note that if we implement this it won't be perfect, as we sometimes change the meaning of existing warnings (or when we mark more functions as deprecated) and guaranteeing perfect compatibility would be too much of a burden.

@vicuna
Copy link
Author

vicuna commented Mar 1, 2017

Comment author: @damiendoligez

ocamlbuild is now a separate project that lives on GitHub.
Since it's not clear whether this should be implemented in the compiler or in ocamlbuild, I'm duplicating the PR (to ocaml/ocamlbuild#186 ).

@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