-
Notifications
You must be signed in to change notification settings - Fork 13k
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
language version markers #3392
Comments
This need not block 0.6. |
nominating for backwards compatible |
accepted for backwards-compatible milestone |
Visiting for triage; nothing to add |
Nominating. This ought to be done with #3795. |
If you want fully-general language versioning, then the approach of #3795 does not seem sufficient. (In particular, you still need to be able to parse in order to deal with the |
(we're going to leave I-nominated so we can wait until next week and see if @brson can explain his thoughts further.) |
((it seems like some of the discussion on #3795 elaborates further on what @brson might have been thinking. E.g. @cmr said there that one should only attempt to work at the level of per-crate granularity, which would probably side-step the parser issue, though I think that per-crate may be too coarse -- per mod-in-a-file is more what I was thinking...)) |
P-low, not 1.0 |
If something ever happens here it will be done as-needed. It's not really on the horizon right now. Closing. |
fix compile_fail doctests with post-mono errors Fixes rust-lang/miri#2423
We need a way (using the hash-comment "pre-parse" form similar to shebang comments) to mark a crate's (symbolic) language version, so we don't try parsing rust when we don't have a parser that can handle it. We'll mandate the presence of this sort of marker on a packaged-for-distribution rust file.
The text was updated successfully, but these errors were encountered: