-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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
Tracking Issue for Rust 2024: Make !
fall back to !
#123748
Comments
!
fall back to !
!
fall back to !
It turned out that this is actually tricky/impossible to implement, because we can loose the relationships between inference variables by unifying them: // easy to lint
// coercion graph edges: [?1t -> ?3t, ?2t -> ?3t]
match true {
false => return /* ?1t */,
true => Default::default() /* ?2t */,
} /* ?3t */;
// impossible to lint
// coercion graph edges: [?2t -> ?1t]
match true {
true => Default::default() /* ?1t */,
false => return /* ?2t */,
} /* ?1t */; Even though these examples are very similar, they have enough of a difference in the coercion graph, that we can't lint them both reliably. I talked with Niko at RustNL and we agreed that given these circumstances this lint can be omitted. |
…rovements, r=compiler-errors Never type unsafe lint improvements - Move linting code to a separate method - Remove mentions of `core::convert::absurd` (rust-lang#124311 was rejected) - Make the lint into FCW The last thing is a bit weird though. On one hand it should be `EditionSemanticsChange(2024)`, but on the other hand it shouldn't, because we also plan to break it on all editions some time later. _Also_, it's weird that we don't have `FutureReleaseSemanticsChangeReportInDeps`, IMO "this might cause UB in a future release" is important enough to be reported in deps... IMO we ought to have three enums instead of [`FutureIncompatibilityReason`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint_defs/enum.FutureIncompatibilityReason.html#): ```rust enum IncompatibilityWhen { FutureRelease, Edition(Edition), } enum IncompatibilyWhat { Error, SemanticChange, } enum IncompatibilityReportInDeps { No, Yes, } ``` Tracking: - rust-lang#123748
Rollup merge of rust-lang#125282 - WaffleLapkin:never-type-unsafe-improvements, r=compiler-errors Never type unsafe lint improvements - Move linting code to a separate method - Remove mentions of `core::convert::absurd` (rust-lang#124311 was rejected) - Make the lint into FCW The last thing is a bit weird though. On one hand it should be `EditionSemanticsChange(2024)`, but on the other hand it shouldn't, because we also plan to break it on all editions some time later. _Also_, it's weird that we don't have `FutureReleaseSemanticsChangeReportInDeps`, IMO "this might cause UB in a future release" is important enough to be reported in deps... IMO we ought to have three enums instead of [`FutureIncompatibilityReason`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint_defs/enum.FutureIncompatibilityReason.html#): ```rust enum IncompatibilityWhen { FutureRelease, Edition(Edition), } enum IncompatibilyWhat { Error, SemanticChange, } enum IncompatibilityReportInDeps { No, Yes, } ``` Tracking: - rust-lang#123748
zerocopy ran into a potentially sharp edge with the
We ran into this issue when updating to the latest nightly. Here's the error message:
Here's the offending macro: /// Do `t` and `u` have the same size? If not, this macro produces a compile
/// error. It must be invoked in a dead codepath. This is used in
/// `transmute_ref!` and `transmute_mut!`.
#[doc(hidden)] // `#[macro_export]` bypasses this module's `#[doc(hidden)]`.
#[macro_export]
macro_rules! assert_size_eq {
($t:ident, $u:ident) => {{
// The comments here should be read in the context of this macro's
// invocations in `transmute_ref!` and `transmute_mut!`.
if false {
// SAFETY: This code is never run.
$u = unsafe {
// Clippy:
// - It's okay to transmute a type to itself.
// - We can't annotate the types; this macro is designed to
// infer the types from the calling context.
#[allow(clippy::useless_transmute, clippy::missing_transmute_annotations)]
$crate::macro_util::core_reexport::mem::transmute($t)
};
} else {
loop {}
}
}};
} Note that I believe that this lint isn't actually an issue, and we could soundly However, I will admit to being spooked by this since it's new to me and I haven't spent the time to really wrap my head around it to convince myself that it's definitely fine. I might instead just rewrite that macro. In particular, it's always called from dead code, but has the /// Do `t` and `u` have the same size? If not, this macro produces a compile
/// error. It must be invoked in a dead codepath. This is used in
/// `transmute_ref!` and `transmute_mut!`.
///
/// # Safety
///
/// The code generated by this macro must never be executed at runtime.
#[doc(hidden)] // `#[macro_export]` bypasses this module's `#[doc(hidden)]`.
#[macro_export]
macro_rules! assert_size_eq {
($t:ident, $u:ident) => {{
// Clippy:
// - It's okay to transmute a type to itself.
// - We can't annotate the types; this macro is designed to
// infer the types from the calling context.
#[allow(clippy::useless_transmute, clippy::missing_transmute_annotations)]
$crate::macro_util::core_reexport::mem::transmute($t)
}};
} |
Hmmm, confusingly the "remove the |
@joshlf note that this only happens when there is an error already, so I don't think this is a problem. The reason warning is emitted is that compiler can't infer type of |
Okay that makes sense, thanks for investigating! |
Implement lint for obligations broken by never type fallback change This is the second (and probably last major?) lint required for the never type fallback change. The idea is to check if the code errors with `fallback = ()` and if it errors with `fallback = !` and if it went from "ok" to "error", lint. I'm not happy with the diagnostic, ideally we'd highlight what bound is the problem. But I'm really unsure how to do that (cc `@jackh726,` iirc you had some ideas?) r? `@compiler-errors` Thanks `@BoxyUwU` with helping with trait solver stuff when I was implementing the initial version of this lint. Tracking: - rust-lang#123748
…mpiler-errors Implement lint for obligations broken by never type fallback change This is the second (and probably last major?) lint required for the never type fallback change. The idea is to check if the code errors with `fallback = ()` and if it errors with `fallback = !` and if it went from "ok" to "error", lint. I'm not happy with the diagnostic, ideally we'd highlight what bound is the problem. But I'm really unsure how to do that (cc `@jackh726,` iirc you had some ideas?) r? `@compiler-errors` Thanks `@BoxyUwU` with helping with trait solver stuff when I was implementing the initial version of this lint. Tracking: - rust-lang#123748
…mpiler-errors Implement lint for obligations broken by never type fallback change This is the second (and probably last major?) lint required for the never type fallback change. The idea is to check if the code errors with `fallback = ()` and if it errors with `fallback = !` and if it went from "ok" to "error", lint. I'm not happy with the diagnostic, ideally we'd highlight what bound is the problem. But I'm really unsure how to do that (cc `@jackh726,` iirc you had some ideas?) r? `@compiler-errors` Thanks `@BoxyUwU` with helping with trait solver stuff when I was implementing the initial version of this lint. Tracking: - rust-lang#123748
This comment was marked as resolved.
This comment was marked as resolved.
* fix never type warning: this function depends on never type fallback being `()` --> src/services/redis/backend.rs:438:5 | 438 | async fn append(&self, key: &str, value: &[u8]) -> Result<()> { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #123748 <rust-lang/rust#123748> = help: specify the types explicitly note: in edition 2024, the requirement `!: FromRedisValue` will fail --> src/services/redis/backend.rs:442:22 | 442 | conn.append(key, value).await.map_err(format_redis_error)?; | ^^^^^^ = note: `#[warn(dependency_on_unit_never_type_fallback)]` on by default Signed-off-by: xxchan <xxchan22f@gmail.com> * fix needless borrow warning: the borrowed expression implements the required traits --> src/services/s3/backend.rs:1240:55 | 1240 | let mut err: Error = Error::new(kind, &format!("{i:?}")); | ^^^^^^^^^^^^^^^^^ help: change this to: `format!("{i:?}")` | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_borrows_for_generic_args = note: `#[warn(clippy::needless_borrows_for_generic_args)]` on by default warning: the borrowed expression implements the required traits --> src/services/dropbox/core.rs:437:29 | 437 | ... &format!("delete failed with error {} {}", error.tag, error_cause), | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: change this to: `format!("delete failed with error {} {}", error.tag, error_cause)` | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_borrows_for_generic_args warning: the borrowed expression implements the required traits --> src/services/dropbox/core.rs:446:25 | 446 | &format!("delete failed with unexpected tag {}", entry.tag), | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: change this to: `format!("delete failed with unexpected tag {}", entry.tag)` | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_borrows_for_generic_args Signed-off-by: xxchan <xxchan22f@gmail.com> --------- Signed-off-by: xxchan <xxchan22f@gmail.com>
Replace `IntoLua(Multi)` generic with positional arg (impl trait) where possible This allow to shorten syntax from `a.get::<_, T>` to `a.get::<T>`
* fix never type warning: this function depends on never type fallback being `()` --> src/services/redis/backend.rs:438:5 | 438 | async fn append(&self, key: &str, value: &[u8]) -> Result<()> { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #123748 <rust-lang/rust#123748> = help: specify the types explicitly note: in edition 2024, the requirement `!: FromRedisValue` will fail --> src/services/redis/backend.rs:442:22 | 442 | conn.append(key, value).await.map_err(format_redis_error)?; | ^^^^^^ = note: `#[warn(dependency_on_unit_never_type_fallback)]` on by default Signed-off-by: xxchan <xxchan22f@gmail.com> * fix needless borrow warning: the borrowed expression implements the required traits --> src/services/s3/backend.rs:1240:55 | 1240 | let mut err: Error = Error::new(kind, &format!("{i:?}")); | ^^^^^^^^^^^^^^^^^ help: change this to: `format!("{i:?}")` | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_borrows_for_generic_args = note: `#[warn(clippy::needless_borrows_for_generic_args)]` on by default warning: the borrowed expression implements the required traits --> src/services/dropbox/core.rs:437:29 | 437 | ... &format!("delete failed with error {} {}", error.tag, error_cause), | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: change this to: `format!("delete failed with error {} {}", error.tag, error_cause)` | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_borrows_for_generic_args warning: the borrowed expression implements the required traits --> src/services/dropbox/core.rs:446:25 | 446 | &format!("delete failed with unexpected tag {}", entry.tag), | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: change this to: `format!("delete failed with unexpected tag {}", entry.tag)` | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_borrows_for_generic_args Signed-off-by: xxchan <xxchan22f@gmail.com> --------- Signed-off-by: xxchan <xxchan22f@gmail.com>
The TryFrom approach resulted in warnings, following Rust updates aimed at stabilizing the never type. rust-lang/rust#123748
The TryFrom approach resulted in warnings, following Rust updates aimed at stabilizing the never type. rust-lang/rust#123748
on 1.81, this expression caused rustc warning, and clippy error: ``` warning: this function depends on never type fallback being `()` --> bin/propolis-cli/src/main.rs:497:1 | 497 | / async fn migrate_instance( 498 | | src_client: Client, 499 | | dst_client: Client, 500 | | src_addr: SocketAddr, 501 | | dst_uuid: Uuid, 502 | | disks: Vec<DiskRequest>, 503 | | ) -> anyhow::Result<()> { | |_______________________^ | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #123748 <rust-lang/rust#123748> = help: specify the types explicitly note: in edition 2024, the requirement `!: FromIterator<()>` will fail --> bin/propolis-cli/src/main.rs:598:20 | 598 | .collect::<anyhow::Result<_>>()?; | ^^^^^^^^^^^^^^^^^ = note: `#[warn(dependency_on_unit_never_type_fallback)]` on by default warning: `propolis-cli` (bin "propolis-cli") generated 1 warning ``` i am, honestly, entirely missing how the never type is involved here, or how changing the `collect`'s type from `anyhow::Result<_>` to `anyhow::Result<()>` changes things in a direction to satisfy rustc. but bounding the type further doesn't seem like it would cause a problem?
New in Rust 1.81.0, scheduled to be an error in edition 2024: rust-lang/rust#123748 It looks like mlua v0.10 won't need this workaround: mlua-rs/mlua@3641c98
* Add support for `-J` option group This commit adds support for the `-J` option group and enables `javy-json` and `override-json-parse-and-stringify` by default. Additionally, this change improves how the javy cli integration tests are defined by introducing a `javy_cli_test` which: * Produces a test per supported command (`compile` and `build`) * Provides a set of defaults depending on the command under test Generating a test per command improves the developer experience of determining failures on particular command configurations. Lastly, this change bumps the provider to v3, given that new funcionality is introduced as part of enabling `javy-json` and `override-json-parse-and-stringify`. In order to test that the `compile` command remains "frozen", using version 2 of the provider, this commit introduces a static copy of the v2 provided downloaded from the releases section. * Add explicit types to `this.eval[_with_options]` calls To address: rust-lang/rust#123748 * Clarify the usage of `clippy::too_many_arguments` * Clippy fixes * Rename `override-json-parse-and-stringify` to `simd-json-builtins` * Update `javy-fuzz` * More migration * Update test-macros to use `simd_json_builtins`
* fix new 1.81.0 warning and clippy error on 1.81, this expression caused rustc warning, and clippy error: ``` warning: this function depends on never type fallback being `()` --> bin/propolis-cli/src/main.rs:497:1 | 497 | / async fn migrate_instance( 498 | | src_client: Client, 499 | | dst_client: Client, 500 | | src_addr: SocketAddr, 501 | | dst_uuid: Uuid, 502 | | disks: Vec<DiskRequest>, 503 | | ) -> anyhow::Result<()> { | |_______________________^ | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #123748 <rust-lang/rust#123748> = help: specify the types explicitly note: in edition 2024, the requirement `!: FromIterator<()>` will fail --> bin/propolis-cli/src/main.rs:598:20 | 598 | .collect::<anyhow::Result<_>>()?; | ^^^^^^^^^^^^^^^^^ = note: `#[warn(dependency_on_unit_never_type_fallback)]` on by default warning: `propolis-cli` (bin "propolis-cli") generated 1 warning ``` i am, honestly, entirely missing how the never type is involved here, or how changing the `collect`'s type from `anyhow::Result<_>` to `anyhow::Result<()>` changes things in a direction to satisfy rustc. but bounding the type further doesn't seem like it would cause a problem? * the unused pub(crate) struct warnings are new also, allow these cases
rustc 1.81 produces a warning (see rust-lang/rust#123748) in a few places. This change fixes that.
This relates to - rust-lang/rust#123748 - https://doc.rust-lang.org/nightly/edition-guide/rust-2024/never-type-fallback.html And frankly I still don't really understand why never type was involved in our code in the first place.
This relates to - rust-lang/rust#123748 - https://doc.rust-lang.org/nightly/edition-guide/rust-2024/never-type-fallback.html And frankly I still don't really understand why never type was involved in our code in the first place.
Work around for Rust 2024 implementing Never type (!) rust-lang/rust#123748
Work around for Rust 2024 implementing Never type (!) rust-lang/rust#123748
As per <rust-lang/rust#123748> ! will no longer degrade into () which in this situation breaks type deduction; so specify it explicitly.
As per <rust-lang/rust#123748> ! will no longer degrades into () which in this situation breaks type deduction; so specify it explicitly.
As per <rust-lang/rust#123748> ! will no longer degrades into () which in this situation breaks type deduction; so specify it explicitly.
This is a tracking issue for the change to make fallback fall back from
!
to!
(rather than to()
) in Rust 2024. This is part of a plan that leads to eventually stabilizing the never (!
) type.What this change means
This change means that
!
does not spontaneously decay to()
. For example, consider this code:todo!()
"returns"!
, but before this change this!
decayed to()
when being returned from the closure. In general, this can happen at any coercion site, if the type is not set by something else.If your code is broken with errors like
`!: Trait` is not satisfied
, then you need to make sure the type is specified explicitly. For example:Before this change
!
fromreturn
decays to()
, meaning thatcreate_zst
will also return()
, and since()
implementsFrom<()>
this was fine. With this change however,!
fromreturn
keeps being!
and inference makescreate_zst
also return!
, however!
does not implementFrom<()>
causing a compilation error.The easiest fix is to specify the type explicitly:
However, this can also be a sign that you don't care what the type is, and maybe the better solution is to refactor the code.
Also note that this "create something or return" pattern can also be caused by
?
with code like this:Because
deserialize
's output type is not bound to be anything, it gets inferred from?
's desugaring that includes areturn
. (there is a separate initiative to stop?
from affecting inference like this: #122412)About tracking issues
Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Steps
!
fall back to!
#123508unsafe
functions.?
guiding inference.!
's docs #124419Unresolved Questions
unsafe
function)deny-by-default
or a hard error in Rust 2024.NEVER_TYPE_FALLBACK_FLOWING_INTO_UNSAFE
a deny-by-default lint in edition 2024 #126881Related
!
#123482!
fall back to!
#123508NeverToAny
#123571!
's docs #124419DEPENDENCY_ON_UNIT_NEVER_TYPE_FALLBACK
#126367NEVER_TYPE_FALLBACK_FLOWING_INTO_UNSAFE
a deny-by-default lint in edition 2024 #126881The text was updated successfully, but these errors were encountered: