Skip to content

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

fmease
Copy link
Member

@fmease fmease commented Aug 17, 2025

Accept code like let _: != loop {}; or let _: 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 !=).

@rustbot

This comment was marked as outdated.

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Aug 17, 2025
@fmease
Copy link
Member Author

fmease commented Aug 17, 2025

r? petrochenkov or reassign

@rustbot rustbot assigned petrochenkov and unassigned lcnr Aug 17, 2025

#[cfg(false)] struct W<const X: ! = { loop {} }>;
#[cfg(false)] struct S<const X: != { loop {} }>;
}
Copy link
Member Author

@fmease fmease Aug 17, 2025

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.

Copy link
Contributor

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.

@fmease fmease added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 17, 2025
@fmease fmease force-pushed the split-bang-eq-for-never-ascr branch from 5dd2c57 to d1e84da Compare August 17, 2025 19:36
@fmease fmease added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 17, 2025
// 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).
Copy link
Contributor

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.

@petrochenkov petrochenkov added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 18, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants