Opportunistically split != to successfully parse never type

[fmease]

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 != (edit: this is not true actually, my bad, I don't know what snippet I tested to come to that conclusion) 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 !=).

[fmease]

r? petrochenkov or reassign

[fmease]

Maybe add this, too:

#![feature(default_field_values)]

struct X<T> {
    w: fn(T) -> ! = |_| loop {},
    s: fn(T) -> != |_| loop {},
}

Doesn't really matter tho.

[petrochenkov]

Yeah, let's add this one too.

[petrochenkov]

It will probably work if the support is added to break_two_token_op.

[traviscross]

As this changes the language grammar, this will need a lang FCP. If you could talk a bit about the analysis and motivation here for the nomination, that would be helpful.

This change would allow, e.g.,

let _: fn() -> != || loop {};

to be accepted both syntactically and semantically.

It'd be good for us to find a way to document this in the Reference as well.

cc @rust-lang/lang-docs

(H/t to our lang advisor @ehuss for raising this.)

[fmease]

Sorry for not getting back to you. To be honest, there's no practical motivation. However, I really liked what [@]ehuss wrote in rust-lang/reference#1983, however it's been two weeks since I last read it.

I guess the general question is: Is there a more principled approach to this (not necessarily wrt. the implementation but also how we want to categorize or describe it in the Reference etc.) or do we "want to keep" adding these things in an ad hoc manner. A possible point of contention: It might hurt forward compatibility since it takes away a bit of whitespace sensitivity (Rust is obv. mostly whitespace insensitive but not fully).

[petrochenkov]

The more principled approach is to migrate rustc's parser to the single-character token model with Spacing, which is used by proc macros.
In that model the notion of "multi-character operators" is only relevant in compatibility cases, like parsing tt, otherwise they are just sequences of single-character punctuation with joint spacing, and can be broken up arbitrarily.

Until then we need to consider cases like this as bugs and fix them when they are discovered. That matches what we did in practice in the previous years, all more popular multi-character tokens are already split in the parser when necessary.

[traviscross]

Makes sense. Good enough for me.

@rfcbot fcp merge

[rust-rfcbot]

Team member @traviscross has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @scottmcm
• @tmandry
• @traviscross

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[tmandry]

My understanding from the lang team discussion is that this should be transparent to users at the lexing level and shouldn't limit us in the future (beyond the decision to support parsing this).

@rfcbot reviewed

[rust-rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[scottmcm]

On the same assumption as Tyler,
@rust-rfcbot reviewed

[rust-rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.