stabilize never type#155499
Conversation
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
|
|
@bors try |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
2895d33 to
3e8df8d
Compare
|
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
|
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
|
🎉 Experiment
Footnotes
|
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
| // Only suggest the `never_type` if the feature is enabled | ||
| && cx.tcx.features().never_type() |
There was a problem hiding this comment.
I think this Clippy lint should not fire if the project have an MSRV that supports Rust before this stabilization.
Also, I'm not sure I agree with current lint description which suggests writing a struct Thing(pub !);
There was a problem hiding this comment.
Checking MSRV requires knowing in which release the never type will be merged, so I'll leave this as a follow-up.
Don't really agree with the lint either, but that's unrelated to this PR.
There was a problem hiding this comment.
There was a problem hiding this comment.
If we're changing this in this PR, then I think these docs need updating.
|
I'm unclear if the Infallible changes will also be made in this PR at the same time? Either way, I recommend addressing the docs here saying never is unstable. |
@WaffleLapkin had mentioned wanting to land that in a separate PR. We do need to ensure these land in the same release, of course. |
|
What's the story with If you want to keep it, I suggest updating it so that it is |
Probably I wouldn't expect us to make this a hard error (the semantics are clear and making it a hard error would not simplify the language definition). I'm happy with it at deny-by-default for now. Looking at it: pub NEVER_TYPE_FALLBACK_FLOWING_INTO_UNSAFE,
Deny,
"never type fallback affecting unsafe function calls",
@future_incompatible = FutureIncompatibleInfo {
reason: fcw!(EditionAndFutureReleaseSemanticsChange 2024 "never-type-fallback"),
report_in_deps: true,
};
@edition Edition2024 => Deny;
report_in_external_macroProbably I'd expect we want to remove the FCW- and edition-related bits and make this a plain deny-by-default lint — once this PR goes in, it will no longer be linting about anything happening in the future. |
This would mean it'd not show up for dependencies, which was useful. |
02de51f to
5675e12
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
The reason `rustc_ast_ir` and `rustc_pattern_analysis` have nested `cfg_attr`s is so that they don't mention `cfg(bootstrap)` when nightly or rustc cargo feature turned on. If you don't do it like that, they stop compiling on stable (or rather, they emit unexpected cfg warnings...).
??? why wasn't this detected by compiletest ???
5675e12 to
8b0d675
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
|
The job Click to see the possible cause of the failure (guessed by this bot) |
View all comments
This PR:
!on all editions (breaking change, see crater report analysis and refresher on never type fallback)dependency_on_unit_never_type_fallbacklint (there is no more never type fallback to()so this lint can't be triggered)Cat:

Tracking:
!to a type (RFC 1216) #35121Stabilization plan FCP:
!fall back to!#123508Lint bump:
Rust 2024 edition change:
!fall back to!#123748!fall back to!#123508