-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
2018 edition ?
Kleene operator
#51587
Conversation
@nikomatsakis Is this close to what you had in mind? |
Also, I think I should add some more tests for 2015 vs 2018 behavior. |
?
Kleene operator?
Kleene operator
Nice work, @mark-i-m! Hoping we can get this merged in soon. |
I'm not quite sure I got the lint right... it's currently a straight up warning... |
@mark-i-m Yes, there look to be 1001 different ways of linting in the compiler code. This is the sort of thing that could really do with a chapter in the rustc book! |
@mark-i-m Oh gosh, I really should have checked before making that comment! The rustc book has come a long way since I last read it. The one thing still really deficient is the macros chapter, sadly... Also, it reminds me I should submit a PR about incremental compilation tests. |
src/libsyntax/ext/tt/quoted.rs
Outdated
} | ||
return (Some(token::Question), op); | ||
} | ||
Ok(Ok(op)) => return (Some(token::Question), op), | ||
Ok(Ok(op)) => { | ||
if !features.macro_at_most_once_rep |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the feature gate is not quite acting like I expect. My expectation is:
- In Edition 2015:
- If you do
$()?[*+]
, then you get "?
as separator". - Else, if you do
$(foo)?[^*+]
, treat as "optional":- But if feature gate is not enabled, error
- If you do
- In Edition 2018:
- If you do
$(foo)?
, then treat as "optional":- But if feature gate is not enabled, error.
- If you do
My goal is that, when it comes time to stabilize, we can just "constant propagate" as if the feature gate was always enabled and get the final behavior we want:
- in Rust 2015 we fallback to old behavior
- in Rust 2018 we use new behavior all the time
(Is this the plan? Do we have an official, FCP'd proposal somewhere, anyway?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Is this the plan? Do we have an official, FCP'd proposal somewhere, anyway?)
No, we don't TMK
in Rust 2015 we fallback to old behavior
Given that this is behavior that will only last for another couple of months, my preference is to
- just keep this unstable on 2015 and only enable in 2018
- make the feature flag always turn on 2018 behavior
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So to clarify:
- In edition 2015:
- Without feature flag:
?
is a separator.?
is not a Kleene op. - With feature flag: same as 2018
- Without feature flag:
- In edition 2018
?
is not a separator.?
is a Kleene op that does not accept a separator.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer this:
- In edition 2015:
- With or without feature flag:
?
is a separator and there is no?
- However, using
?
as a separator issues arust_2018_migration
warning
- With or without feature flag:
- In edition 2018:
?
is always a separator- and feature-gate is required until we stabilize
Point is, as before, that the feature-gate should just be a "error or no error" filter -- the behavior should model what we eventually want when all is said and done otherwise. And we never want Rust 2015 to support ?
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In edition 2018:
? is always a separator
You mean "in 2018, ?
is always a kleene op", right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(I'd sure hope so heh!)
@nikomatsakis I think I have implemented what you specified with one major exception: currently, the warning for using Do you know how I can hook up the warning to fire when the lint group is set? Also, should it be a |
This comment has been minimized.
This comment has been minimized.
This still needs some work. I am currently fixing/writing some tests. |
@nikomatsakis I pushed a few tests. Do these tests represent the behavior you were expecting? |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
21562f6
to
e5ba108
Compare
Ok, I think I've implemented and added tests for everything except that the migration warning is currently an unconditional warning. All feedback is welcome! |
?
Kleene operator?
Kleene operator
This comment has been minimized.
This comment has been minimized.
Doh. I forgot that I started using this in places in the compiler 😛 |
Hmm... some of these are going to be hard to fix... |
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me!
// Feature gate test for macro_at_most_once_rep under 2018 edition. | ||
|
||
// gate-test-macro_at_most_once_rep | ||
// compile-flags: --edition=2018 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unrelated, but we should really add a // edition: 2018
option, shouldn't we?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Created #51800
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done!
@@ -0,0 +1,71 @@ | |||
error[E0658]: Using the `?` macro Kleene operator for "at most one" repetition is unstable (see issue #48075) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: start compiler messages w/ lower-case letters
@mark-i-m travis is unhappy, but this code looks good to me overall |
@nikomatsakis Is it ok that the warning is unconditional? |
Great! @mark-i-m want to rebase and I'll do a final once-over and r+? |
42d4142
to
10ee0f6
Compare
🎉 Rebased :) |
@bors: r+ |
📌 Commit 10ee0f6 has been approved by |
2018 edition `?` Kleene operator This is my first attempt at implementing the migration lint + 2018 behavior as discussed in #48075 r? @nikomatsakis
☀️ Test successful - status-appveyor, status-travis |
📣 Toolstate changed by #51587! Tested on commit f498e4e. 💔 rls on windows: test-pass → build-fail (cc @nrc, @rust-lang/infra). |
Tested on commit rust-lang/rust@f498e4e. Direct link to PR: <rust-lang/rust#51587> 💔 rls on windows: test-pass → build-fail (cc @nrc, @rust-lang/infra). 💔 rls on linux: test-pass → build-fail (cc @nrc, @rust-lang/infra). 💔 rustfmt on windows: test-pass → build-fail (cc @nrc, @rust-lang/infra). 💔 rustfmt on linux: test-pass → build-fail (cc @nrc, @rust-lang/infra).
We need to update Edit: We'll need to wait for |
This should fix the breakage caused by rust-lang/rust#51587.
This is my first attempt at implementing the migration lint + 2018 behavior as discussed in #48075
r? @nikomatsakis