-
Notifications
You must be signed in to change notification settings - Fork 13.7k
Opportunistically split !=
to successfully parse never type
#145536
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
base: master
Are you sure you want to change the base?
Conversation
This comment was marked as outdated.
This comment was marked as outdated.
r? petrochenkov or reassign |
|
||
#[cfg(false)] struct W<const X: ! = { loop {} }>; | ||
#[cfg(false)] struct S<const X: != { loop {} }>; | ||
} |
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.
Maybe add this, too:
#![feature(default_field_values)]
struct X<T> {
w: fn(T) -> ! = |_| loop {},
s: fn(T) -> != |_| loop {},
}
Doesn't really matter tho.
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.
Yeah, let's add this one too.
5dd2c57
to
d1e84da
Compare
// Parse `!` | ||
// Ideally we'd use `eat_bang` here to allow us to parse `!=>` as `! =>`. However, | ||
// `break_and_eat` doesn't "reglue" the split-off `=` with any following `>` (since | ||
// that would likely be super fragile and complex). |
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.
It will probably work if the support is added to break_two_token_op
.
Accept code like
let _: != loop {};
orlet _: fn() -> != || loop {};
(previously: syntax error). Similar to sth. like #51068.There's no inherent need to update
can_begin_type
from what I can tell, since macro matcher$ty:ty =
already accepts!=
and since no other current direct/transitive callers would 'benefit' from doing that either, so I didn't do it. It's a conservative choice to avoid odd consequences (concrete example: it would widen the follow set of:vis
to include!=
).