Question:
The struct is meant to not be constructible. Also the behavior is incoherent between tuple structs (correct behavior) and named structs (incorrect behavior). Also, this is a regression, this didn't use to be the case. No response No response
label +F-never_Type +D-inconsistent
We will also get such warnings for private structs with fields of never type (): The struct is never constructed although it is not constructible. This behavior is expected and is not a regression. Did you meet any cases using this way in real world? For the incoherent behavior, we also have: This because we only skip positional ZST (PhantomData and generics), this policy is also applied for never read fields:
Can you elaborate in which sense it is expected? I can understand that it is expected given the current implementation of Rust. It seems between stable and nightly a new lint was implemented. This lint is expected for inhabited types. However it has false positives on inhabited types, i.e. types that are only meant for type-level usage (for example to implement a trait). I agree we should probably categorize this issue as a false positive of a new lint rather than a regression (technically). Thanks, I can see the idea behind it. I'm not convinced about it though, but it doesn't bother me either. So let's just keep this issue focused on the false positive rather than the inconsistent behavior.
How do you think about private structs with fields of never type?
I would consider it the same as public structs, because they can still be "constructed" at the type-level. So they are dynamic dead--code but not dead-code since they are used statically. It would be dead-code though if the type is never used (both in dynamic code and static code, i.e. types).
Actually, thinking about this issue, I don't think this is a false positive only for the never type. I think the whole lint is wrong. The fact that the type is empty is just a proof that constructing it at term-level is not necessary for the type to be "alive" (aka usable). This could also be the case with non-empty types. A lot of people just use unit types for type-level usage only (instead of empty types). So my conclusion would be that linting a type to be dead-code because it is never constructed is brittle as it can't be sure that the type is not meant to be constructed at term-level (and thus only used at type-level). Adding is not a solution because if the type is actually not used at all (including in types) then we actually want the warning. Here is an example: The same thing with a private struct: And now actual dead code:
I think a better way is: is usually used to do such things like just a proof. Maybe we can add a help for this case.
But I agree that we shouldn't emit warnings for pub structs with any fields of never type (and also unit type), this is an intentional behavior.
Oh yes good point. So all good to proceed with adding never type to the list of special types.
Thanks a lot for the quick fix! Once it hits nightly, I'll give it a try. I'm a bit afraid though that this won't fix the underlying problem of understanding which types are not meant to exist at runtime. For example, sometimes instead of using the never type, I also use empty enums such that I can give a name and separate identity to that type. Let's see if it's an issue. If yes, I guess ultimately there would be 2 options: Just use in those cases. Introduce a trait (or better name) for types that are not meant to exist at runtime like unit, never, and phantom types, but could be extended with user types like empty enums. I'll ping this thread again if I actually hit this issue.
I could test it (using nightly-2024-08-01) and . I just had to change a to in a crate where I didn't have already. Ultimately, is going to be a type alias for so maybe it's not worth supporting it. And thinking about empty enums, this should never be an issue for my particular usage, which is to build empty types. Because either the type takes no parameters in which case I use an empty enum directly. Or it takes parameters and I have to use a struct with fields, and to make the struct empty I also have to add a never field. So my concern in the previous message is not an issue for me.

<del> error: struct `Whatever` is never constructed --> $DIR/clone-debug-dead-code-in-the-same-struct.rs:4:12 </del> <ins> error: fields `field1`, `field2`, `field3`, and `field4` are never read --> $DIR/clone-debug-dead-code-in-the-same-struct.rs:6:5 </ins> | LL | pub struct Whatever { <del> |            ^^^^^^^^ </del> <ins> |            -------- fields in this struct LL |     pub field0: (), LL |     field1: (), |     ^^^^^^ LL |     field2: (), |     ^^^^^^ LL |     field3: (), |     ^^^^^^ LL |     field4: (), |     ^^^^^^ </ins> | <ins> = note: `Whatever` has a derived impl for the trait `Debug`, but this is intentionally ignored during dead code analysis </ins> note: the lint level is defined here --> $DIR/clone-debug-dead-code-in-the-same-struct.rs:1:11 |


Question:
The struct is meant to not be constructible. Also the behavior is incoherent between tuple structs (correct behavior) and named structs (incorrect behavior). Also, this is a regression, this didn't use to be the case. No response No response
label +F-never_Type +D-inconsistent
We will also get such warnings for private structs with fields of never type (): The struct is never constructed although it is not constructible. This behavior is expected and is not a regression. Did you meet any cases using this way in real world? For the incoherent behavior, we also have: This because we only skip positional ZST (PhantomData and generics), this policy is also applied for never read fields:
Can you elaborate in which sense it is expected? I can understand that it is expected given the current implementation of Rust. It seems between stable and nightly a new lint was implemented. This lint is expected for inhabited types. However it has false positives on inhabited types, i.e. types that are only meant for type-level usage (for example to implement a trait). I agree we should probably categorize this issue as a false positive of a new lint rather than a regression (technically). Thanks, I can see the idea behind it. I'm not convinced about it though, but it doesn't bother me either. So let's just keep this issue focused on the false positive rather than the inconsistent behavior.
How do you think about private structs with fields of never type?
I would consider it the same as public structs, because they can still be "constructed" at the type-level. So they are dynamic dead--code but not dead-code since they are used statically. It would be dead-code though if the type is never used (both in dynamic code and static code, i.e. types).
Actually, thinking about this issue, I don't think this is a false positive only for the never type. I think the whole lint is wrong. The fact that the type is empty is just a proof that constructing it at term-level is not necessary for the type to be "alive" (aka usable). This could also be the case with non-empty types. A lot of people just use unit types for type-level usage only (instead of empty types). So my conclusion would be that linting a type to be dead-code because it is never constructed is brittle as it can't be sure that the type is not meant to be constructed at term-level (and thus only used at type-level). Adding is not a solution because if the type is actually not used at all (including in types) then we actually want the warning. Here is an example: The same thing with a private struct: And now actual dead code:
I think a better way is: is usually used to do such things like just a proof. Maybe we can add a help for this case.
But I agree that we shouldn't emit warnings for pub structs with any fields of never type (and also unit type), this is an intentional behavior.
Oh yes good point. So all good to proceed with adding never type to the list of special types.
Thanks a lot for the quick fix! Once it hits nightly, I'll give it a try. I'm a bit afraid though that this won't fix the underlying problem of understanding which types are not meant to exist at runtime. For example, sometimes instead of using the never type, I also use empty enums such that I can give a name and separate identity to that type. Let's see if it's an issue. If yes, I guess ultimately there would be 2 options: Just use in those cases. Introduce a trait (or better name) for types that are not meant to exist at runtime like unit, never, and phantom types, but could be extended with user types like empty enums. I'll ping this thread again if I actually hit this issue.
I could test it (using nightly-2024-08-01) and . I just had to change a to in a crate where I didn't have already. Ultimately, is going to be a type alias for so maybe it's not worth supporting it. And thinking about empty enums, this should never be an issue for my particular usage, which is to build empty types. Because either the type takes no parameters in which case I use an empty enum directly. Or it takes parameters and I have to use a struct with fields, and to make the struct empty I also have to add a never field. So my concern in the previous message is not an issue for me.

<ins> #![feature(never_type)] #![deny(dead_code)] pub struct T1(!); pub struct T2(()); pub struct T3<X>(std::marker::PhantomData<X>); pub struct T4 { _x: !, } pub struct T5<X> { _x: !, _y: X, } pub struct T6 { _x: (), } pub struct T7<X> { _x: (), _y: X, } pub struct T8<X> { _x: std::marker::PhantomData<X>, } pub struct T9<X> { //~ ERROR struct `T9` is never constructed _x: std::marker::PhantomData<X>, _y: i32, } fn main() {} </ins>


Question:
The struct is meant to not be constructible. Also the behavior is incoherent between tuple structs (correct behavior) and named structs (incorrect behavior). Also, this is a regression, this didn't use to be the case. No response No response
label +F-never_Type +D-inconsistent
We will also get such warnings for private structs with fields of never type (): The struct is never constructed although it is not constructible. This behavior is expected and is not a regression. Did you meet any cases using this way in real world? For the incoherent behavior, we also have: This because we only skip positional ZST (PhantomData and generics), this policy is also applied for never read fields:
Can you elaborate in which sense it is expected? I can understand that it is expected given the current implementation of Rust. It seems between stable and nightly a new lint was implemented. This lint is expected for inhabited types. However it has false positives on inhabited types, i.e. types that are only meant for type-level usage (for example to implement a trait). I agree we should probably categorize this issue as a false positive of a new lint rather than a regression (technically). Thanks, I can see the idea behind it. I'm not convinced about it though, but it doesn't bother me either. So let's just keep this issue focused on the false positive rather than the inconsistent behavior.
How do you think about private structs with fields of never type?
I would consider it the same as public structs, because they can still be "constructed" at the type-level. So they are dynamic dead--code but not dead-code since they are used statically. It would be dead-code though if the type is never used (both in dynamic code and static code, i.e. types).
Actually, thinking about this issue, I don't think this is a false positive only for the never type. I think the whole lint is wrong. The fact that the type is empty is just a proof that constructing it at term-level is not necessary for the type to be "alive" (aka usable). This could also be the case with non-empty types. A lot of people just use unit types for type-level usage only (instead of empty types). So my conclusion would be that linting a type to be dead-code because it is never constructed is brittle as it can't be sure that the type is not meant to be constructed at term-level (and thus only used at type-level). Adding is not a solution because if the type is actually not used at all (including in types) then we actually want the warning. Here is an example: The same thing with a private struct: And now actual dead code:
I think a better way is: is usually used to do such things like just a proof. Maybe we can add a help for this case.
But I agree that we shouldn't emit warnings for pub structs with any fields of never type (and also unit type), this is an intentional behavior.
Oh yes good point. So all good to proceed with adding never type to the list of special types.
Thanks a lot for the quick fix! Once it hits nightly, I'll give it a try. I'm a bit afraid though that this won't fix the underlying problem of understanding which types are not meant to exist at runtime. For example, sometimes instead of using the never type, I also use empty enums such that I can give a name and separate identity to that type. Let's see if it's an issue. If yes, I guess ultimately there would be 2 options: Just use in those cases. Introduce a trait (or better name) for types that are not meant to exist at runtime like unit, never, and phantom types, but could be extended with user types like empty enums. I'll ping this thread again if I actually hit this issue.
I could test it (using nightly-2024-08-01) and . I just had to change a to in a crate where I didn't have already. Ultimately, is going to be a type alias for so maybe it's not worth supporting it. And thinking about empty enums, this should never be an issue for my particular usage, which is to build empty types. Because either the type takes no parameters in which case I use an empty enum directly. Or it takes parameters and I have to use a struct with fields, and to make the struct empty I also have to add a never field. So my concern in the previous message is not an issue for me.

<ins> error: struct `T9` is never constructed --> $DIR/unconstructible-pub-struct.rs:30:12 | LL | pub struct T9<X> { |            ^^ | note: the lint level is defined here --> $DIR/unconstructible-pub-struct.rs:2:9 | LL | #![deny(dead_code)] |         ^^^^^^^^^ error: aborting due to 1 previous error </ins>


Question:
I do not have minimised code. This was a sudden CI build failure on nightly for aarch64-unknown-linux-musl () Note that this is a cross compile using cross-rs. It fails on rust version 1.82.0-nightly ( 2024-07-29) but works on 1.82.0-nightly ( 2024-07-28). Needless to say it also works perfectly fine on stable. The error is reproducible on rebuild and locally with cross-rs. It is not reproducible with cargo-zigbuild interestingly enough. I also checked that the version of cross-rs didn't change between the successful and failing builds (no new releases of that project since february). The only change between the successful and failing CI runs were a typo fix to an unrelated CI pipeline (the release one, so it didn't even run yet). As such I'm forced to conclude that the blame lies with Rustc. Steps to reproduce: I expected to see this happen: Compilation successful (as it is with stable for same target, or with -gnu and nightly) Instead, this happened () It most recently worked on: 1.82.0-nightly ( 2024-07-28) (or stable 1.80.0 or beta 1.81.0, take your pick for triaging) :
cc (of cross-rs fame) in case he has any insight on this regression
I have hit the same issue in a similar situation. Cross compiling to aarch64-unknown-linux-musl from x86_64 linux in a Github CI pipeline using cross-rs. Link to pipeline failing logs:
Seems rune isn't needed based on the comment by Updated the title.
This is probably
WG-prioritization assigning priority (). label -I-prioritize +P-high
Yeah that's probably it. We used to build the C version of those symbols but switched to Rust versions with the compiler builtins update. Unfortunately we can't enable them on all platforms because LLVM has crashes, and the logic that would allow optional configuration is apparently not working. After that part is fixed, we will need to enable the symbols on all platforms where is f128 (which includes aarch64), since these errors probably come from here I think anyone who needs a quick workaround can add to their dependencies to get the symbols directly, as described near the top of Note that this requires nightly.
Is it possible to add a dependency conditionally based on if it is nightly? (In a specific range of dates even?) I cannot and will not depend on nightly, but I do test my code on nightly in CI (in order to find breakages like this early). For now I just disabled that nightly build on aarch64 musl.
Same for me. Not using cross-rs though. Logs are here:
Same for me, both using as host toolchain and cross compiling.
Looks like it is happening now too for x86_64.
Not for my projects, so you should probably provide a reproducer on x86-64 GNU if possible, since that is a tier 1 platform (unlike Aarch64 on Musl). Or is this about some other x8664 variation that is also tier 2?
Woops, sorry, the x86_64 build failed too, but then i looked at the aarch64 build logs :) which still fail.

[[package]] name = "compiler_builtins" <del> version = "0.1.114" </del> <ins> version = "0.1.117" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "eb58b199190fcfe0846f55a3b545cd6b07a34bdd5930a476ff856f3ebcc5558a" </del> <ins> checksum = "a91dae36d82fe12621dfb5b596d7db766187747749b22e33ac068e1bfc356f4a" </ins> dependencies = [ "cc", "rustc-std-workspace-core",


Question:
I do not have minimised code. This was a sudden CI build failure on nightly for aarch64-unknown-linux-musl () Note that this is a cross compile using cross-rs. It fails on rust version 1.82.0-nightly ( 2024-07-29) but works on 1.82.0-nightly ( 2024-07-28). Needless to say it also works perfectly fine on stable. The error is reproducible on rebuild and locally with cross-rs. It is not reproducible with cargo-zigbuild interestingly enough. I also checked that the version of cross-rs didn't change between the successful and failing builds (no new releases of that project since february). The only change between the successful and failing CI runs were a typo fix to an unrelated CI pipeline (the release one, so it didn't even run yet). As such I'm forced to conclude that the blame lies with Rustc. Steps to reproduce: I expected to see this happen: Compilation successful (as it is with stable for same target, or with -gnu and nightly) Instead, this happened () It most recently worked on: 1.82.0-nightly ( 2024-07-28) (or stable 1.80.0 or beta 1.81.0, take your pick for triaging) :
cc (of cross-rs fame) in case he has any insight on this regression
I have hit the same issue in a similar situation. Cross compiling to aarch64-unknown-linux-musl from x86_64 linux in a Github CI pipeline using cross-rs. Link to pipeline failing logs:
Seems rune isn't needed based on the comment by Updated the title.
This is probably
WG-prioritization assigning priority (). label -I-prioritize +P-high
Yeah that's probably it. We used to build the C version of those symbols but switched to Rust versions with the compiler builtins update. Unfortunately we can't enable them on all platforms because LLVM has crashes, and the logic that would allow optional configuration is apparently not working. After that part is fixed, we will need to enable the symbols on all platforms where is f128 (which includes aarch64), since these errors probably come from here I think anyone who needs a quick workaround can add to their dependencies to get the symbols directly, as described near the top of Note that this requires nightly.
Is it possible to add a dependency conditionally based on if it is nightly? (In a specific range of dates even?) I cannot and will not depend on nightly, but I do test my code on nightly in CI (in order to find breakages like this early). For now I just disabled that nightly build on aarch64 musl.
Same for me. Not using cross-rs though. Logs are here:
Same for me, both using as host toolchain and cross compiling.
Looks like it is happening now too for x86_64.
Not for my projects, so you should probably provide a reproducer on x86-64 GNU if possible, since that is a tier 1 platform (unlike Aarch64 on Musl). Or is this about some other x8664 variation that is also tier 2?
Woops, sorry, the x86_64 build failed too, but then i looked at the aarch64 build logs :) which still fail.

[dependencies] core = { path = "../core" } <del> compiler_builtins = { version = "0.1.114", features = ['rustc-dep-of-std'] } [target.'cfg(not(any(target_arch = "aarch64", target_arch = "x86", target_arch = "x86_64")))'.dependencies] compiler_builtins = { version = "0.1.114", features = ["no-f16-f128"] } </del> <ins> compiler_builtins = { version = "0.1.117", features = ['rustc-dep-of-std'] } </ins> [dev-dependencies] rand = { version = "0.8.5", default-features = false, features = ["alloc"] }


Question:
I do not have minimised code. This was a sudden CI build failure on nightly for aarch64-unknown-linux-musl () Note that this is a cross compile using cross-rs. It fails on rust version 1.82.0-nightly ( 2024-07-29) but works on 1.82.0-nightly ( 2024-07-28). Needless to say it also works perfectly fine on stable. The error is reproducible on rebuild and locally with cross-rs. It is not reproducible with cargo-zigbuild interestingly enough. I also checked that the version of cross-rs didn't change between the successful and failing builds (no new releases of that project since february). The only change between the successful and failing CI runs were a typo fix to an unrelated CI pipeline (the release one, so it didn't even run yet). As such I'm forced to conclude that the blame lies with Rustc. Steps to reproduce: I expected to see this happen: Compilation successful (as it is with stable for same target, or with -gnu and nightly) Instead, this happened () It most recently worked on: 1.82.0-nightly ( 2024-07-28) (or stable 1.80.0 or beta 1.81.0, take your pick for triaging) :
cc (of cross-rs fame) in case he has any insight on this regression
I have hit the same issue in a similar situation. Cross compiling to aarch64-unknown-linux-musl from x86_64 linux in a Github CI pipeline using cross-rs. Link to pipeline failing logs:
Seems rune isn't needed based on the comment by Updated the title.
This is probably
WG-prioritization assigning priority (). label -I-prioritize +P-high
Yeah that's probably it. We used to build the C version of those symbols but switched to Rust versions with the compiler builtins update. Unfortunately we can't enable them on all platforms because LLVM has crashes, and the logic that would allow optional configuration is apparently not working. After that part is fixed, we will need to enable the symbols on all platforms where is f128 (which includes aarch64), since these errors probably come from here I think anyone who needs a quick workaround can add to their dependencies to get the symbols directly, as described near the top of Note that this requires nightly.
Is it possible to add a dependency conditionally based on if it is nightly? (In a specific range of dates even?) I cannot and will not depend on nightly, but I do test my code on nightly in CI (in order to find breakages like this early). For now I just disabled that nightly build on aarch64 musl.
Same for me. Not using cross-rs though. Logs are here:
Same for me, both using as host toolchain and cross compiling.
Looks like it is happening now too for x86_64.
Not for my projects, so you should probably provide a reproducer on x86-64 GNU if possible, since that is a tier 1 platform (unlike Aarch64 on Musl). Or is this about some other x8664 variation that is also tier 2?
Woops, sorry, the x86_64 build failed too, but then i looked at the aarch64 build logs :) which still fail.

panic_unwind = { path = "../panic_unwind", optional = true } panic_abort = { path = "../panic_abort" } core = { path = "../core", public = true } <del> compiler_builtins = { version = "0.1.114" } </del> <ins> compiler_builtins = { version = "0.1.117" } </ins> profiler_builtins = { path = "../profiler_builtins", optional = true } unwind = { path = "../unwind" } hashbrown = { version = "0.14", default-features = false, features = [


Question:
Found by grepping through the compiler via while reviewing an unrelated PR. File : File : : . or move source file . : . <details<summaryFull compiler output</summary</details:
Solution: Get rid of altogether and use a multi-part suggestion (, ).

.suggestion = escape `box` to use it as an identifier parse_box_syntax_removed = `box_syntax` has been removed <del> .suggestion = use `Box::new()` instead </del> <ins> parse_box_syntax_removed_suggestion = use `Box::new()` instead </ins> parse_cannot_be_raw_ident = `{$ident}` cannot be a raw identifier


Question:
Found by grepping through the compiler via while reviewing an unrelated PR. File : File : : . or move source file . : . <details<summaryFull compiler output</summary</details:
Solution: Get rid of altogether and use a multi-part suggestion (, ).

#[derive(Diagnostic)] #[diag(parse_box_syntax_removed)] <del> pub struct BoxSyntaxRemoved<'a> { </del> <ins> pub struct BoxSyntaxRemoved { </ins> #[primary_span] <del> #[suggestion( code = "Box::new({code})", applicability = "machine-applicable", style = "verbose" )] </del> pub span: Span, <del> pub code: &'a str, </del> <ins> #[subdiagnostic] pub sugg: AddBoxNew, } #[derive(Subdiagnostic)] #[multipart_suggestion( parse_box_syntax_removed_suggestion, applicability = "machine-applicable", style = "verbose" )] pub struct AddBoxNew { #[suggestion_part(code = "Box::new(")] pub box_kw_and_lo: Span, #[suggestion_part(code = ")")] pub hi: Span, </ins> } #[derive(Diagnostic)]


Question:
Found by grepping through the compiler via while reviewing an unrelated PR. File : File : : . or move source file . : . <details<summaryFull compiler output</summary</details:
Solution: Get rid of altogether and use a multi-part suggestion (, ).

/// Parse `box expr` - this syntax has been removed, but we still parse this /// for now to provide a more useful error fn parse_expr_box(&mut self, box_kw: Span) -> PResult<'a, (Span, ExprKind)> { <del> let (span, _) = self.parse_expr_prefix_common(box_kw)?; let inner_span = span.with_lo(box_kw.hi()); let code = self.psess.source_map().span_to_snippet(inner_span).unwrap(); let guar = self.dcx().emit_err(errors::BoxSyntaxRemoved { span: span, code: code.trim() }); </del> <ins> let (span, expr) = self.parse_expr_prefix_common(box_kw)?; // Make a multipart suggestion instead of `span_to_snippet` in case source isn't available let box_kw_and_lo = box_kw.until(self.interpolated_or_expr_span(&expr)); let hi = span.shrink_to_hi(); let sugg = errors::AddBoxNew { box_kw_and_lo, hi }; let guar = self.dcx().emit_err(errors::BoxSyntaxRemoved { span, sugg }); </ins> Ok((span, ExprKind::Err(guar))) }


Question:
Found by grepping through the compiler via while reviewing an unrelated PR. File : File : : . or move source file . : . <details<summaryFull compiler output</summary</details:
Solution: Get rid of altogether and use a multi-part suggestion (, ).

help: use `Box::new()` instead | LL |     let _ = Box::new(()); <del> |             ~~~~~~~~~~~~ </del> <ins> |             ~~~~~~~~~  + </ins> error: `box_syntax` has been removed --> $DIR/removed-syntax-box.rs:10:13


Question:
Found by grepping through the compiler via while reviewing an unrelated PR. File : File : : . or move source file . : . <details<summaryFull compiler output</summary</details:
Solution: Get rid of altogether and use a multi-part suggestion (, ).

help: use `Box::new()` instead | LL |     let _ = Box::new(1); <del> |             ~~~~~~~~~~~ </del> <ins> |             ~~~~~~~~~ + </ins> error: `box_syntax` has been removed --> $DIR/removed-syntax-box.rs:11:13


Question:
Found by grepping through the compiler via while reviewing an unrelated PR. File : File : : . or move source file . : . <details<summaryFull compiler output</summary</details:
Solution: Get rid of altogether and use a multi-part suggestion (, ).

help: use `Box::new()` instead | LL |     let _ = Box::new(T { a: 12, b: 18 }); <del> |             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ </del> <ins> |             ~~~~~~~~~                  + </ins> error: `box_syntax` has been removed --> $DIR/removed-syntax-box.rs:12:13


Question:
Found by grepping through the compiler via while reviewing an unrelated PR. File : File : : . or move source file . : . <details<summaryFull compiler output</summary</details:
Solution: Get rid of altogether and use a multi-part suggestion (, ).

help: use `Box::new()` instead | LL |     let _ = Box::new([5; 30]); <del> |             ~~~~~~~~~~~~~~~~~ </del> <ins> |             ~~~~~~~~~       + </ins> error: `box_syntax` has been removed --> $DIR/removed-syntax-box.rs:13:22


Question:
Found by grepping through the compiler via while reviewing an unrelated PR. File : File : : . or move source file . : . <details<summaryFull compiler output</summary</details:
Solution: Get rid of altogether and use a multi-part suggestion (, ).

help: use `Box::new()` instead | LL |     let _: Box<()> = Box::new(()); <del> |                      ~~~~~~~~~~~~ </del> <ins> |                      ~~~~~~~~~  + </ins> error: aborting due to 5 previous errors


Question:
<!-- ICE: Rustc '-Zpolymorphize=on -Zinline-mir=yes -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'mentioneditems for DefId(0:15 ~ a[1172]::unsound) have not yet been set'', 'thread 'rustc' panicked at 'mentioneditems for DefId(0:15 ~ a[1172]::unsound) have not yet been set'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [optimizedmir] optimizing MIR for [unusedgenericparams] determining which generic parameters are unused by -- label +F-traitupcasting
Regression in nightly-2024-08-03 Regression in cc
Looks like another tainting issue to me -- we shouldn't be inlining MIR bodies that don't even pass type-checking... Cc

) -> Result<(), &'static str> { let tcx = self.tcx; <ins> if let Some(_) = callee_body.tainted_by_errors { return Err("Body is tainted"); } </ins> let mut threshold = if self.caller_is_inline_forwarder { self.tcx.sess.opts.unstable_opts.inline_mir_forwarder_threshold.unwrap_or(30) } else if cross_crate_inlinable {


Question:
<!-- ICE: Rustc '-Zpolymorphize=on -Zinline-mir=yes -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'mentioneditems for DefId(0:15 ~ a[1172]::unsound) have not yet been set'', 'thread 'rustc' panicked at 'mentioneditems for DefId(0:15 ~ a[1172]::unsound) have not yet been set'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [optimizedmir] optimizing MIR for [unusedgenericparams] determining which generic parameters are unused by -- label +F-traitupcasting
Regression in nightly-2024-08-03 Regression in cc
Looks like another tainting issue to me -- we shouldn't be inlining MIR bodies that don't even pass type-checking... Cc

<del> //@ compile-flags: -Zvalidate-mir -Zinline-mir=yes //@ known-bug: #122909 use std::sync::{Arc, Context, Weak}; pub struct WeakOnce<T>(); impl<T> WeakOnce<T> { extern "rust-call" fn try_get(&self) -> Option<Arc<T>> {} pub fn get(&self) -> Arc<T> { self.try_get() .unwrap_or_else(|| panic!("Singleton {} not available", std::any::type_name::<T>())) } } </del>


Question:
<!-- ICE: Rustc '-Zpolymorphize=on -Zinline-mir=yes -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'mentioneditems for DefId(0:15 ~ a[1172]::unsound) have not yet been set'', 'thread 'rustc' panicked at 'mentioneditems for DefId(0:15 ~ a[1172]::unsound) have not yet been set'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [optimizedmir] optimizing MIR for [unusedgenericparams] determining which generic parameters are unused by -- label +F-traitupcasting
Regression in nightly-2024-08-03 Regression in cc
Looks like another tainting issue to me -- we shouldn't be inlining MIR bodies that don't even pass type-checking... Cc

<ins> //@ compile-flags: -Zvalidate-mir -Zinline-mir=yes #![feature(unboxed_closures)] use std::sync::Arc; pub struct WeakOnce<T>(); //~^ ERROR type parameter `T` is never used impl<T> WeakOnce<T> { extern "rust-call" fn try_get(&self) -> Option<Arc<T>> {} //~^ ERROR functions with the "rust-call" ABI must take a single non-self tuple argument //~| ERROR mismatched types pub fn get(&self) -> Arc<T> { self.try_get() .unwrap_or_else(|| panic!("Singleton {} not available", std::any::type_name::<T>())) } } fn main() {} </ins>


Question:
<!-- ICE: Rustc '-Zpolymorphize=on -Zinline-mir=yes -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'mentioneditems for DefId(0:15 ~ a[1172]::unsound) have not yet been set'', 'thread 'rustc' panicked at 'mentioneditems for DefId(0:15 ~ a[1172]::unsound) have not yet been set'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [optimizedmir] optimizing MIR for [unusedgenericparams] determining which generic parameters are unused by -- label +F-traitupcasting
Regression in nightly-2024-08-03 Regression in cc
Looks like another tainting issue to me -- we shouldn't be inlining MIR bodies that don't even pass type-checking... Cc

<ins> error[E0392]: type parameter `T` is never used --> $DIR/inline-tainted-body.rs:7:21 | LL | pub struct WeakOnce<T>(); |                     ^ unused type parameter | = help: consider removing `T`, referring to it in a field, or using a marker such as `PhantomData` = help: if you intended `T` to be a const parameter, use `const T: /* Type */` instead error: functions with the "rust-call" ABI must take a single non-self tuple argument --> $DIR/inline-tainted-body.rs:11:35 | LL |     extern "rust-call" fn try_get(&self) -> Option<Arc<T>> {} |                                   ^^^^^ error[E0308]: mismatched types --> $DIR/inline-tainted-body.rs:11:45 | LL |     extern "rust-call" fn try_get(&self) -> Option<Arc<T>> {} |                           -------           ^^^^^^^^^^^^^^ expected `Option<Arc<T>>`, found `()` |                           | |                           implicitly returns `()` as its body has no tail or `return` expression | = note:   expected enum `Option<Arc<T>>` found unit type `()` error: aborting due to 3 previous errors Some errors have detailed explanations: E0308, E0392. For more information about an error, try `rustc --explain E0308`. </ins>


Question:
Right now using to manage the rust-lang/rust repo locally causes to fail: This is a result of which is responsible for adding the character to the failing test. While I would love to get that support to jj upstream I'm assuming it is non-trivial and I'd like a better solution in the short term so I can continue to use while contributing to the compiler. suggested I use in the meantime which I'm fine with but I'd like a way to set this in my or some equivalent mechanism doesn't require manually adding this set of arguments to every invocation of I make.
note this is essentially the same as i actually would like an even more general solution, where the flags and configs are completely interchangable and you can specify either in either place, but a solution just for seems ok too. label T-bootstrap A-contributor-roadblock
So it turns out that won't work as a short term fix even because does not work with tidy atm. For now I'm going with but I expect this to break frequently and be a source of annoyance so I'll be looking towards fixing this soon if it does in fact end up being a problem.
re crlf, as a source control expert I'd recommend never using any kind of autoconversion -- it is a bit of a nightmare to work with in too many cases. Rather, I'd consider checking in the file with CRLFs, and disabling autoconversion so files are always checked out as-is. (Another option is to effectively treat the file as binary content, e.g. use some other means of encoding the file, such as base64 or putting it in a tarball. But I don't know how practical that is)

<del> warning-crlf.rs eol=crlf </del> <ins> warning-crlf.rs -text </ins>


Question:
Right now using to manage the rust-lang/rust repo locally causes to fail: This is a result of which is responsible for adding the character to the failing test. While I would love to get that support to jj upstream I'm assuming it is non-trivial and I'd like a better solution in the short term so I can continue to use while contributing to the compiler. suggested I use in the meantime which I'm fine with but I'd like a way to set this in my or some equivalent mechanism doesn't require manually adding this set of arguments to every invocation of I make.
note this is essentially the same as i actually would like an even more general solution, where the flags and configs are completely interchangable and you can specify either in either place, but a solution just for seems ok too. label T-bootstrap A-contributor-roadblock
So it turns out that won't work as a short term fix even because does not work with tidy atm. For now I'm going with but I expect this to break frequently and be a source of annoyance so I'll be looking towards fixing this soon if it does in fact end up being a problem.
re crlf, as a source control expert I'd recommend never using any kind of autoconversion -- it is a bit of a nightmare to work with in too many cases. Rather, I'd consider checking in the file with CRLFs, and disabling autoconversion so files are always checked out as-is. (Another option is to effectively treat the file as binary content, e.g. use some other means of encoding the file, such as base64 or putting it in a tarball. But I don't know how practical that is)

<del> // ignore-tidy-cr //@ check-pass // This file checks the spans of intra-link warnings in a file with CRLF line endings. The // .gitattributes file in this directory should enforce it. /// [error] pub struct A; //~^^ WARNING `error` /// /// docs [error1] //~^ WARNING `error1` /// docs [error2] /// pub struct B; //~^^^ WARNING `error2` /** * This is a multi-line comment. * * It also has an [error]. */ pub struct C; //~^^^ WARNING `error` </del> <ins> // ignore-tidy-cr //@ check-pass // This file checks the spans of intra-link warnings in a file with CRLF line endings. The // .gitattributes file in this directory should enforce it. /// [error] pub struct A; //~^^ WARNING `error` /// /// docs [error1] //~^ WARNING `error1` /// docs [error2] /// pub struct B; //~^^^ WARNING `error2` /** * This is a multi-line comment. * * It also has an [error]. */ pub struct C; //~^^^ WARNING `error` </ins>


Question:
<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: 536 | Err(#[stable(feature = "rust1", since = "1.0.0")] E), [typeck] type-checking [analysis] running analysis passes on this crate --
Probably one of those cases... We should almost have an internal deny lint that bans explicit manipulations for suggestions. Possibly
Strongly agree. It's so easy to find these kinds of ICEs: simply needs to look for inside , out which ASCII character is meant to one's favorite Unicode table website that can list Confusables a Confusable whose is 1 and :boom:
For example, here's another one which I organically found while reviewing an unrelated PR: This code uses a Medium Right Parenthesis Ornament (U+2769) which is confusable with Right Parenthesis
I'll open an issue for the internal lint.

use rustc_middle::{bug, span_bug}; use rustc_session::Session; use rustc_span::symbol::{kw, Ident}; <del> use rustc_span::{sym, BytePos, Span, DUMMY_SP}; </del> <ins> use rustc_span::{sym, Span, DUMMY_SP}; </ins> use rustc_trait_selection::error_reporting::infer::{FailureCode, ObligationCauseExt}; use rustc_trait_selection::infer::InferCtxtExt; use rustc_trait_selection::traits::{self, ObligationCauseCode, SelectionContext};


Question:
<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: 536 | Err(#[stable(feature = "rust1", since = "1.0.0")] E), [typeck] type-checking [analysis] running analysis passes on this crate --
Probably one of those cases... We should almost have an internal deny lint that bans explicit manipulations for suggestions. Possibly
Strongly agree. It's so easy to find these kinds of ICEs: simply needs to look for inside , out which ASCII character is meant to one's favorite Unicode table website that can list Confusables a Confusable whose is 1 and :boom:
For example, here's another one which I organically found while reviewing an unrelated PR: This code uses a Medium Right Parenthesis Ornament (U+2769) which is confusable with Right Parenthesis
I'll open an issue for the internal lint.

.get(arg_idx + 1) .map(|&(_, sp)| sp) .unwrap_or_else(|| { <del> // Subtract one to move before `)` call_expr.span.with_lo(call_expr.span.hi() - BytePos(1)) </del> <ins> // Try to move before `)`. Note that `)` here is not necessarily // the latin right paren, it could be a Unicode-confusable that // looks like a `)`, so we must not use `- BytePos(1)` // manipulations here. self.tcx().sess.source_map().end_point(call_expr.span) </ins> }); // Include next comma


Question:
<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: 536 | Err(#[stable(feature = "rust1", since = "1.0.0")] E), [typeck] type-checking [analysis] running analysis passes on this crate --
Probably one of those cases... We should almost have an internal deny lint that bans explicit manipulations for suggestions. Possibly
Strongly agree. It's so easy to find these kinds of ICEs: simply needs to look for inside , out which ASCII character is meant to one's favorite Unicode table website that can list Confusables a Confusable whose is 1 and :boom:
For example, here's another one which I organically found while reviewing an unrelated PR: This code uses a Medium Right Parenthesis Ornament (U+2769) which is confusable with Right Parenthesis
I'll open an issue for the internal lint.

<ins> //! Previously, we tried to remove extra arg commas when providing extra arg removal suggestions. //! One of the edge cases is having to account for an arg that has a closing delimiter `)` //! following it. However, the previous suggestion code assumed that the delimiter is in fact //! exactly the 1-byte `)` character. This assumption was proven incorrect, because we recover //! from Unicode-confusable delimiters in the parser, which means that the ending delimiter could be //! a multi-byte codepoint that looks *like* a `)`. Subtracing 1 byte could land us in the middle of //! a codepoint, triggering a codepoint boundary assertion. //! //! issue: rust-lang/rust#128717 fn main() { // The following example has been modified from #128717 to remove irrelevant Unicode as they do // not otherwise partake in the right delimiter calculation causing the codepoint boundary // assertion. main(rahh）; //~^ ERROR unknown start of token //~| ERROR this function takes 0 arguments but 1 argument was supplied //~| ERROR cannot find value `rahh` in this scope } </ins>


Question:
<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: 536 | Err(#[stable(feature = "rust1", since = "1.0.0")] E), [typeck] type-checking [analysis] running analysis passes on this crate --
Probably one of those cases... We should almost have an internal deny lint that bans explicit manipulations for suggestions. Possibly
Strongly agree. It's so easy to find these kinds of ICEs: simply needs to look for inside , out which ASCII character is meant to one's favorite Unicode table website that can list Confusables a Confusable whose is 1 and :boom:
For example, here's another one which I organically found while reviewing an unrelated PR: This code uses a Medium Right Parenthesis Ornament (U+2769) which is confusable with Right Parenthesis
I'll open an issue for the internal lint.

<ins> error: unknown start of token: u{ff09} --> $DIR/suggest-arg-comma-delete-ice.rs:15:14 | LL |     main(rahh）; |              ^^ | help: Unicode character '）' (Fullwidth Right Parenthesis) looks like ')' (Right Parenthesis), but it is not | LL |     main(rahh); |              ~ error[E0425]: cannot find value `rahh` in this scope --> $DIR/suggest-arg-comma-delete-ice.rs:15:10 | LL |     main(rahh）; |          ^^^^ not found in this scope error[E0061]: this function takes 0 arguments but 1 argument was supplied --> $DIR/suggest-arg-comma-delete-ice.rs:15:5 | LL |     main(rahh）; |     ^^^^ ---- unexpected argument | note: function defined here --> $DIR/suggest-arg-comma-delete-ice.rs:11:4 | LL | fn main() { |    ^^^^ help: remove the extra argument | LL -     main(rahh）; LL +     main(）; | error: aborting due to 3 previous errors Some errors have detailed explanations: E0061, E0425. For more information about an error, try `rustc --explain E0061`. </ins>


Question:
<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: --
Can you start pingbacking at least for all of these?
ice since
can you add a filter for is:issue is:open label:I-ICE "bpos.to_u32" into the ticket you mentioned? That should find all relevant past an future issues automatically I think.
A filter? How do I do that?
oh, you mean a link
I a label , I'll go back and tag some of them later.

fn parse_initializer(&mut self, eq_optional: bool) -> PResult<'a, Option<P<Expr>>> { let eq_consumed = match self.token.kind { token::BinOpEq(..) => { <del> // Recover `let x <op>= 1` as `let x = 1` </del> <ins> // Recover `let x <op>= 1` as `let x = 1` We must not use `+ BytePos(1)` here // because `<op>` can be a multi-byte lookalike that was recovered, e.g. `➖=` (the // `➖` is a U+2796 Heavy Minus Sign Unicode Character) that was recovered as a // `-=`. let extra_op_span = self.psess.source_map().start_point(self.token.span); </ins> self.dcx().emit_err(errors::CompoundAssignmentExpressionInLet { span: self.token.span, <del> suggestion: self.token.span.with_hi(self.token.span.lo() + BytePos(1)), </del> <ins> suggestion: extra_op_span, </ins> }); self.bump(); true


Question:
<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: --
Can you start pingbacking at least for all of these?
ice since
can you add a filter for is:issue is:open label:I-ICE "bpos.to_u32" into the ticket you mentioned? That should find all relevant past an future issues automatically I think.
A filter? How do I do that?
oh, you mean a link
I a label , I'll go back and tag some of them later.

<ins> //! Previously we would try to issue a suggestion for `let x <op>= 1`, i.e. a compound assignment //! within a `let` binding, to remove the `<op>`. The suggestion code unfortunately incorrectly //! assumed that the `<op>` is an exactly-1-byte ASCII character, but this assumption is incorrect //! because we also recover Unicode-confusables like `➖=` as `-=`. In this example, the suggestion //! code used a `+ BytePos(1)` to calculate the span of the `<op>` codepoint that looks like `-` but //! the mult-byte Unicode look-alike would cause the suggested removal span to be inside a //! multi-byte codepoint boundary, triggering a codepoint boundary assertion. //! //! issue: rust-lang/rust#128845 fn main() { // Adapted from #128845 but with irrelevant components removed and simplified. let x ➖= 1; //~^ ERROR unknown start of token: u{2796} //~| ERROR: can't reassign to an uninitialized variable } </ins>


Question:
<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: --
Can you start pingbacking at least for all of these?
ice since
can you add a filter for is:issue is:open label:I-ICE "bpos.to_u32" into the ticket you mentioned? That should find all relevant past an future issues automatically I think.
A filter? How do I do that?
oh, you mean a link
I a label , I'll go back and tag some of them later.

<ins> error: unknown start of token: u{2796} --> $DIR/suggest-remove-compount-assign-let-ice.rs:13:11 | LL |     let x ➖= 1; |           ^^ | help: Unicode character '➖' (Heavy Minus Sign) looks like '-' (Minus/Hyphen), but it is not | LL |     let x -= 1; |           ~ error: can't reassign to an uninitialized variable --> $DIR/suggest-remove-compount-assign-let-ice.rs:13:11 | LL |     let x ➖= 1; |           ^^^ | = help: if you meant to overwrite, remove the `let` binding help: initialize the variable | LL -     let x ➖= 1; LL +     let x = 1; | error: aborting due to 2 previous errors </ins>


Question:
Since GDB used on CI is recent enough to run the new tests. However, there are three failures that have been ignored in : <details<summary<codetestsdebuginfomethod-on-</code(happened only on 32-bits)</summary</details<details<summary<codetestsdebuginfooption-like-</code(happened only on 32-bits)</summary</details<details<summary<codetestsdebuginfoby-value-non-immediate-argument</code</summary</details
modify labels: +O-windows-gnu +A-debuginfo
The by-value-non-immediate-argument is Upon further inspection, I am now confident that the enums test failures are actually a change in layout with targets. Such nonsense is typical of the debuginfo tests. Take this example program, using the enum extracted from the test: Which we can run on any target that can print using Miri x8664-pc-windows-msvc, x86-64-pc-windows-gnu, and x8664-unknonw-linux-gnu all print 1. s390x-unknown-linux-gnu and i686-pc-windows-gnu print 0 i686-unknown-linux-gnu reports UB, didn't bother figuring out where its discriminant is at but uh that's sus So I think the debuggers in the tests are correctly reporting that the discriminant value for change between platforms.
Oh I see! says this: As far as I can tell, this test has been broken since it was written. You can't rely on field order like this, and indeed as I demonstrated above, fields get reordered differently across targets. The structs and enums also have different field ordering on a single target.

// gdb-command:run // gdb-command:print some <del> // gdb-check:$1 = core::option::Option<&u32>::Some(0x12345678) </del> <ins> // gdb-check:$1 = core::option::Option<&u32>::Some(0x[...]) </ins> // gdb-command:print none // gdb-check:$2 = core::option::Option<&u32>::None // gdb-command:print full <del> // gdb-check:$3 = option_like_enum::MoreFields::Full(454545, 0x87654321, 9988) </del> <ins> // gdb-check:$3 = option_like_enum::MoreFields::Full(454545, 0x[...], 9988) </ins> <del> // gdb-command:print empty_gdb.discr // gdb-check:$4 = (*mut isize) 0x1 </del> <ins> // gdb-command:print empty // gdb-check:$4 = option_like_enum::MoreFields::Empty </ins> // gdb-command:print droid <del> // gdb-check:$5 = option_like_enum::NamedFields::Droid{id: 675675, range: 10000001, internals: 0x43218765} </del> <ins> // gdb-check:$5 = option_like_enum::NamedFields::Droid{id: 675675, range: 10000001, internals: 0x[...]} </ins> <del> // gdb-command:print void_droid_gdb.internals // gdb-check:$6 = (*mut isize) 0x1 </del> <ins> // gdb-command:print void_droid // gdb-check:$6 = option_like_enum::NamedFields::Void </ins> // gdb-command:print nested_non_zero_yep // gdb-check:$7 = option_like_enum::NestedNonZero::Yep(10.5, option_like_enum::NestedNonZeroField {a: 10, b: 20, c: 0x[...]})


Question:
Since GDB used on CI is recent enough to run the new tests. However, there are three failures that have been ignored in : <details<summary<codetestsdebuginfomethod-on-</code(happened only on 32-bits)</summary</details<details<summary<codetestsdebuginfooption-like-</code(happened only on 32-bits)</summary</details<details<summary<codetestsdebuginfoby-value-non-immediate-argument</code</summary</details
modify labels: +O-windows-gnu +A-debuginfo
The by-value-non-immediate-argument is Upon further inspection, I am now confident that the enums test failures are actually a change in layout with targets. Such nonsense is typical of the debuginfo tests. Take this example program, using the enum extracted from the test: Which we can run on any target that can print using Miri x8664-pc-windows-msvc, x86-64-pc-windows-gnu, and x8664-unknonw-linux-gnu all print 1. s390x-unknown-linux-gnu and i686-pc-windows-gnu print 0 i686-unknown-linux-gnu reports UB, didn't bother figuring out where its discriminant is at but uh that's sus So I think the debuggers in the tests are correctly reporting that the discriminant value for change between platforms.
Oh I see! says this: As far as I can tell, this test has been broken since it was written. You can't rely on field order like this, and indeed as I demonstrated above, fields get reordered differently across targets. The structs and enums also have different field ordering on a single target.

// lldb-command:run // lldb-command:v some <del> // lldb-check:[...] Some(&0x12345678) </del> <ins> // lldb-check:[...] Some(&0x[...]) </ins> // lldb-command:v none // lldb-check:[...] None // lldb-command:v full <del> // lldb-check:[...] Full(454545, &0x87654321, 9988) </del> <ins> // lldb-check:[...] Full(454545, &0x[...], 9988) </ins> // lldb-command:v empty // lldb-check:[...] Empty // lldb-command:v droid <del> // lldb-check:[...] Droid { id: 675675, range: 10000001, internals: &0x43218765 } </del> <ins> // lldb-check:[...] Droid { id: 675675, range: 10000001, internals: &0x[...] } </ins> // lldb-command:v void_droid // lldb-check:[...] Void


Question:
Since GDB used on CI is recent enough to run the new tests. However, there are three failures that have been ignored in : <details<summary<codetestsdebuginfomethod-on-</code(happened only on 32-bits)</summary</details<details<summary<codetestsdebuginfooption-like-</code(happened only on 32-bits)</summary</details<details<summary<codetestsdebuginfoby-value-non-immediate-argument</code</summary</details
modify labels: +O-windows-gnu +A-debuginfo
The by-value-non-immediate-argument is Upon further inspection, I am now confident that the enums test failures are actually a change in layout with targets. Such nonsense is typical of the debuginfo tests. Take this example program, using the enum extracted from the test: Which we can run on any target that can print using Miri x8664-pc-windows-msvc, x86-64-pc-windows-gnu, and x8664-unknonw-linux-gnu all print 1. s390x-unknown-linux-gnu and i686-pc-windows-gnu print 0 i686-unknown-linux-gnu reports UB, didn't bother figuring out where its discriminant is at but uh that's sus So I think the debuggers in the tests are correctly reporting that the discriminant value for change between platforms.
Oh I see! says this: As far as I can tell, this test has been broken since it was written. You can't rely on field order like this, and indeed as I demonstrated above, fields get reordered differently across targets. The structs and enums also have different field ordering on a single target.

// contains a non-nullable pointer, then this value is used as the discriminator. // The test cases in this file make sure that something readable is generated for // this kind of types. <del> // If the non-empty variant contains a single non-nullable pointer than the whole // item is represented as just a pointer and not wrapped in a struct. // Unfortunately (for these test cases) the content of the non-discriminant fields // in the null-case is not defined. So we just read the discriminator field in // this case (by casting the value to a memory-equivalent struct). </del> enum MoreFields<'a> { Full(u32, &'a isize, i16),


Question:
Since GDB used on CI is recent enough to run the new tests. However, there are three failures that have been ignored in : <details<summary<codetestsdebuginfomethod-on-</code(happened only on 32-bits)</summary</details<details<summary<codetestsdebuginfooption-like-</code(happened only on 32-bits)</summary</details<details<summary<codetestsdebuginfoby-value-non-immediate-argument</code</summary</details
modify labels: +O-windows-gnu +A-debuginfo
The by-value-non-immediate-argument is Upon further inspection, I am now confident that the enums test failures are actually a change in layout with targets. Such nonsense is typical of the debuginfo tests. Take this example program, using the enum extracted from the test: Which we can run on any target that can print using Miri x8664-pc-windows-msvc, x86-64-pc-windows-gnu, and x8664-unknonw-linux-gnu all print 1. s390x-unknown-linux-gnu and i686-pc-windows-gnu print 0 i686-unknown-linux-gnu reports UB, didn't bother figuring out where its discriminant is at but uh that's sus So I think the debuggers in the tests are correctly reporting that the discriminant value for change between platforms.
Oh I see! says this: As far as I can tell, this test has been broken since it was written. You can't rely on field order like this, and indeed as I demonstrated above, fields get reordered differently across targets. The structs and enums also have different field ordering on a single target.

let some_str: Option<&'static str> = Some("abc"); let none_str: Option<&'static str> = None; <del> let some: Option<&u32> = Some(unsafe { std::mem::transmute(0x12345678_usize) }); </del> <ins> let some: Option<&u32> = Some(&1234); </ins> let none: Option<&u32> = None; <del> let full = MoreFields::Full(454545, unsafe { std::mem::transmute(0x87654321_usize) }, 9988); </del> <ins> let full = MoreFields::Full(454545, &1234, 9988); </ins> let empty = MoreFields::Empty; <del> let empty_gdb: &MoreFieldsRepr = unsafe { std::mem::transmute(&MoreFields::Empty) }; </del> let droid = NamedFields::Droid { id: 675675, range: 10000001, <del> internals: unsafe { std::mem::transmute(0x43218765_usize) } </del> <ins> internals: &1234, </ins> }; let void_droid = NamedFields::Void; <del> let void_droid_gdb: &NamedFieldsRepr = unsafe { std::mem::transmute(&NamedFields::Void) }; let x = 'x'; </del> let nested_non_zero_yep = NestedNonZero::Yep( 10.5, NestedNonZeroField { a: 10, b: 20, <del> c: &x </del> <ins> c: &'x', </ins> }); let nested_non_zero_nope = NestedNonZero::Nope; zzz(); // #break


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: The warning fires on all three lines of , and the suggestions should only suggest removing the parentheses, not the attribute also. Instead, this happened: The fires on the first and last lines of , and the suggestion also removes the . No warning fires on the second line (but this is probably a separate issue, unrelated to attributes; it happens even when the attribute is removed; maybe overrides it or something). <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: Requires use of , otherwise the is not legal in that position (though note that the warning and suggestion is the same on stable, there's just an first). The issue is not specific to closures and , but that was the simplest example of a reasonable attribute-on-expression I thought of. label +A-diagnostics +requires-nightly <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim

.find_ancestor_inside(value.span) .map(|span| (value.span.with_hi(span.lo()), value.span.with_lo(span.hi()))), ast::ExprKind::Paren(ref expr) => { <del> expr.span.find_ancestor_inside(value.span).map(|expr_span| { </del> <ins> // For the expr with attributes, like `let _ = (#[inline] || println!("Hello!"));`, // the span should contains the attributes, or the suggestion will remove them. let expr_span_with_attrs = if let Some(attr_lo) = expr.attrs.iter().map(|attr| attr.span.lo()).min() { expr.span.with_lo(attr_lo) } else { expr.span }; expr_span_with_attrs.find_ancestor_inside(value.span).map(|expr_span| { </ins> (value.span.with_hi(expr_span.lo()), value.span.with_lo(expr_span.hi())) }) }


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: The warning fires on all three lines of , and the suggestions should only suggest removing the parentheses, not the attribute also. Instead, this happened: The fires on the first and last lines of , and the suggestion also removes the . No warning fires on the second line (but this is probably a separate issue, unrelated to attributes; it happens even when the attribute is removed; maybe overrides it or something). <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: Requires use of , otherwise the is not legal in that position (though note that the warning and suggestion is the same on stable, there's just an first). The issue is not specific to closures and , but that was the simplest example of a reasonable attribute-on-expression I thought of. label +A-diagnostics +requires-nightly <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim

<ins> //@ run-rustfix // Check the `unused_parens` suggestion for paren_expr with attributes. // The suggestion should retain attributes in the front. #![feature(stmt_expr_attributes)] #![deny(unused_parens)] pub fn foo() -> impl Fn() { let _ = #[inline] #[allow(dead_code)] || println!("Hello!"); //~ERROR unnecessary parentheses #[inline] #[allow(dead_code)] || println!("Hello!") //~ERROR unnecessary parentheses } fn main() { let _ = foo(); } </ins>


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: The warning fires on all three lines of , and the suggestions should only suggest removing the parentheses, not the attribute also. Instead, this happened: The fires on the first and last lines of , and the suggestion also removes the . No warning fires on the second line (but this is probably a separate issue, unrelated to attributes; it happens even when the attribute is removed; maybe overrides it or something). <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: Requires use of , otherwise the is not legal in that position (though note that the warning and suggestion is the same on stable, there's just an first). The issue is not specific to closures and , but that was the simplest example of a reasonable attribute-on-expression I thought of. label +A-diagnostics +requires-nightly <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim

<ins> //@ run-rustfix // Check the `unused_parens` suggestion for paren_expr with attributes. // The suggestion should retain attributes in the front. #![feature(stmt_expr_attributes)] #![deny(unused_parens)] pub fn foo() -> impl Fn() { let _ = (#[inline] #[allow(dead_code)] || println!("Hello!")); //~ERROR unnecessary parentheses (#[inline] #[allow(dead_code)] || println!("Hello!")) //~ERROR unnecessary parentheses } fn main() { let _ = foo(); } </ins>


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: The warning fires on all three lines of , and the suggestions should only suggest removing the parentheses, not the attribute also. Instead, this happened: The fires on the first and last lines of , and the suggestion also removes the . No warning fires on the second line (but this is probably a separate issue, unrelated to attributes; it happens even when the attribute is removed; maybe overrides it or something). <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: Requires use of , otherwise the is not legal in that position (though note that the warning and suggestion is the same on stable, there's just an first). The issue is not specific to closures and , but that was the simplest example of a reasonable attribute-on-expression I thought of. label +A-diagnostics +requires-nightly <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim

<ins> error: unnecessary parentheses around assigned value --> $DIR/unused-parens-for-stmt-expr-attributes-issue-129833.rs:9:13 | LL |     let _ = (#[inline] #[allow(dead_code)] || println!("Hello!")); |             ^                                                   ^ | note: the lint level is defined here --> $DIR/unused-parens-for-stmt-expr-attributes-issue-129833.rs:6:9 | LL | #![deny(unused_parens)] |         ^^^^^^^^^^^^^ help: remove these parentheses | LL -     let _ = (#[inline] #[allow(dead_code)] || println!("Hello!")); LL +     let _ = #[inline] #[allow(dead_code)] || println!("Hello!"); | error: unnecessary parentheses around block return value --> $DIR/unused-parens-for-stmt-expr-attributes-issue-129833.rs:10:5 | LL |     (#[inline] #[allow(dead_code)] || println!("Hello!")) |     ^                                                   ^ | help: remove these parentheses | LL -     (#[inline] #[allow(dead_code)] || println!("Hello!")) LL +     #[inline] #[allow(dead_code)] || println!("Hello!") | error: aborting due to 2 previous errors </ins>


Question:
Ferrocene CI has detected that this test was broken by rust-lang/rust . Specifically, by the change in , shown below: Test output: Reverting that single line diff fixes the test for the QNX7.1 targets, e.g. and can the change be reverted or does QNX7.0 need to use , instead of , here? from looking at libc, it appears that both and are available on QNX7.0 so reverting the change should at least not cause compilation or linking errors. if the case is the latter, then we should use in addition to .
thanks for the report! I will need to re-test it for QNX 7.0, to see if it is a 7.0 requirement (i don't recall why this was required initially, but clearly I ran into some issues with it). I also plan to do a similar automation to ensure 7.0 builds run without problems on our hardware. Is there a list of tests you see failing on 7.1 that are OK to ignore? I see a list - is this the most relevant one? Thx!
we do not ignore any single unit test at the moment and we run library (e.g. libstd) tests as well as (cross) compilation tests using . we don't pass to but instead pass the list of test suites as arguments. we currently run these test suites:
WG-prioritization assigning priority (). label -I-prioritize +P-low
fixed in

run_path_with_cstr(original, &|original| { run_path_with_cstr(link, &|link| { cfg_if::cfg_if! { <del> if #[cfg(any(target_os = "vxworks", target_os = "redox", target_os = "android", target_os = "espidf", target_os = "horizon", target_os = "vita", target_os = "nto"))] { </del> <ins> if #[cfg(any(target_os = "vxworks", target_os = "redox", target_os = "android", target_os = "espidf", target_os = "horizon", target_os = "vita", target_env = "nto70"))] { </ins> // VxWorks, Redox and ESP-IDF lack `linkat`, so use `link` instead. POSIX leaves // it implementation-defined whether `link` follows symlinks, so rely on the // `symlink_hard_link` test in library/std/src/fs/tests.rs to check the behavior.


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --After adding to , I get the ICE. The resulting : The full project: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --
Looks like another label: +T-types +WG-trait-system-refactor +regression-from-stable-to-nightly
Stable passes, beta passes. Nightly passes with either or Discovered with It does sporadically succeed, thus needing to clean and rerun the build to make sure. Either something is up with or it only barely exercises these conditions in the parallel frontend, even after cleaning and running the build 100 times. Meanwhile, fails something like ~50% of the time on my machine.
stable passes obviously, as -Zthreads this is a unstable nightly-only flag?
Hm, not actually obvious given that works, though I suppose that does mean it isn't a regression per se. :^)
oh I thought you knew by now that this is the forbidden env flag that should only ever be used for bootstrapping and nothing else and we should not even tell users about it. If you set the flag, your "stable" will also eat nightly-only features, but why would that make a "to-stable" regression if you explicitly tell the compiler "please act like you are NOT a stable release"? I don't think it make sense to backport fixes for untable nightly features into stable lol
who mentioned backports?
The label is used to gather regressions between release channels, which are then discussed whether they are backport-worthy or not. Is that not how the label is used?
I don't really think regression-from-stable-to-nightly nor regression-from-stable-to-stable are used for that at all? Probably regression-from-stable-to-beta is?

} } <ins> fn evaluation_is_concurrent(&self) -> bool { self.sess.threads() > 1 } </ins> fn expand_abstract_consts<T: TypeFoldable<TyCtxt<'tcx>>>(self, t: T) -> T { self.expand_abstract_consts(t) }


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --After adding to , I get the ICE. The resulting : The full project: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --
Looks like another label: +T-types +WG-trait-system-refactor +regression-from-stable-to-nightly
Stable passes, beta passes. Nightly passes with either or Discovered with It does sporadically succeed, thus needing to clean and rerun the build to make sure. Either something is up with or it only barely exercises these conditions in the parallel frontend, even after cleaning and running the build 100 times. Meanwhile, fails something like ~50% of the time on my machine.
stable passes obviously, as -Zthreads this is a unstable nightly-only flag?
Hm, not actually obvious given that works, though I suppose that does mean it isn't a regression per se. :^)
oh I thought you knew by now that this is the forbidden env flag that should only ever be used for bootstrapping and nothing else and we should not even tell users about it. If you set the flag, your "stable" will also eat nightly-only features, but why would that make a "to-stable" regression if you explicitly tell the compiler "please act like you are NOT a stable release"? I don't think it make sense to backport fixes for untable nightly features into stable lol
who mentioned backports?
The label is used to gather regressions between release channels, which are then discussed whether they are backport-worthy or not. Is that not how the label is used?
I don't really think regression-from-stable-to-nightly nor regression-from-stable-to-stable are used for that at all? Probably regression-from-stable-to-beta is?

f: impl FnOnce(&mut search_graph::GlobalCache<Self>) -> R, ) -> R; <ins> fn evaluation_is_concurrent(&self) -> bool; </ins> fn expand_abstract_consts<T: TypeFoldable<Self>>(self, t: T) -> T; type GenericsOf: GenericsOf<Self>;


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --After adding to , I get the ICE. The resulting : The full project: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --
Looks like another label: +T-types +WG-trait-system-refactor +regression-from-stable-to-nightly
Stable passes, beta passes. Nightly passes with either or Discovered with It does sporadically succeed, thus needing to clean and rerun the build to make sure. Either something is up with or it only barely exercises these conditions in the parallel frontend, even after cleaning and running the build 100 times. Meanwhile, fails something like ~50% of the time on my machine.
stable passes obviously, as -Zthreads this is a unstable nightly-only flag?
Hm, not actually obvious given that works, though I suppose that does mean it isn't a regression per se. :^)
oh I thought you knew by now that this is the forbidden env flag that should only ever be used for bootstrapping and nothing else and we should not even tell users about it. If you set the flag, your "stable" will also eat nightly-only features, but why would that make a "to-stable" regression if you explicitly tell the compiler "please act like you are NOT a stable release"? I don't think it make sense to backport fixes for untable nightly features into stable lol
who mentioned backports?
The label is used to gather regressions between release channels, which are then discussed whether they are backport-worthy or not. Is that not how the label is used?
I don't really think regression-from-stable-to-nightly nor regression-from-stable-to-stable are used for that at all? Probably regression-from-stable-to-beta is?

) -> R { I::with_global_cache(self, mode, f) } <ins> fn evaluation_is_concurrent(&self) -> bool { self.evaluation_is_concurrent() } </ins> }


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --After adding to , I get the ICE. The resulting : The full project: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --
Looks like another label: +T-types +WG-trait-system-refactor +regression-from-stable-to-nightly
Stable passes, beta passes. Nightly passes with either or Discovered with It does sporadically succeed, thus needing to clean and rerun the build to make sure. Either something is up with or it only barely exercises these conditions in the parallel frontend, even after cleaning and running the build 100 times. Meanwhile, fails something like ~50% of the time on my machine.
stable passes obviously, as -Zthreads this is a unstable nightly-only flag?
Hm, not actually obvious given that works, though I suppose that does mean it isn't a regression per se. :^)
oh I thought you knew by now that this is the forbidden env flag that should only ever be used for bootstrapping and nothing else and we should not even tell users about it. If you set the flag, your "stable" will also eat nightly-only features, but why would that make a "to-stable" regression if you explicitly tell the compiler "please act like you are NOT a stable release"? I don't think it make sense to backport fixes for untable nightly features into stable lol
who mentioned backports?
The label is used to gather regressions between release channels, which are then discussed whether they are backport-worthy or not. Is that not how the label is used?
I don't really think regression-from-stable-to-nightly nor regression-from-stable-to-stable are used for that at all? Probably regression-from-stable-to-beta is?

cx: X, input: X::Input, <del> result: X::Result, </del> <ins> origin_result: X::Result, </ins> dep_node: X::DepNodeIndex, additional_depth: usize, encountered_overflow: bool, nested_goals: NestedGoals<X>, ) { <del> let result = cx.mk_tracked(result, dep_node); </del> <ins> let result = cx.mk_tracked(origin_result, dep_node); </ins> let entry = self.map.entry(input).or_default(); if encountered_overflow { let with_overflow = WithOverflow { nested_goals, result }; let prev = entry.with_overflow.insert(additional_depth, with_overflow); <del> assert!(prev.is_none()); </del> <ins> if let Some(prev) = &prev { assert!(cx.evaluation_is_concurrent()); assert_eq!(cx.get_tracked(&prev.result), origin_result); } </ins> } else { let prev = entry.success.replace(Success { additional_depth, nested_goals, result }); <del> assert!(prev.is_none()); </del> <ins> if let Some(prev) = &prev { assert!(cx.evaluation_is_concurrent()); assert_eq!(cx.get_tracked(&prev.result), origin_result); } </ins> } }


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --After adding to , I get the ICE. The resulting : The full project: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --
Looks like another label: +T-types +WG-trait-system-refactor +regression-from-stable-to-nightly
Stable passes, beta passes. Nightly passes with either or Discovered with It does sporadically succeed, thus needing to clean and rerun the build to make sure. Either something is up with or it only barely exercises these conditions in the parallel frontend, even after cleaning and running the build 100 times. Meanwhile, fails something like ~50% of the time on my machine.
stable passes obviously, as -Zthreads this is a unstable nightly-only flag?
Hm, not actually obvious given that works, though I suppose that does mean it isn't a regression per se. :^)
oh I thought you knew by now that this is the forbidden env flag that should only ever be used for bootstrapping and nothing else and we should not even tell users about it. If you set the flag, your "stable" will also eat nightly-only features, but why would that make a "to-stable" regression if you explicitly tell the compiler "please act like you are NOT a stable release"? I don't think it make sense to backport fixes for untable nightly features into stable lol
who mentioned backports?
The label is used to gather regressions between release channels, which are then discussed whether they are backport-worthy or not. Is that not how the label is used?
I don't really think regression-from-stable-to-nightly nor regression-from-stable-to-stable are used for that at all? Probably regression-from-stable-to-beta is?

mode: SolverMode, f: impl FnOnce(&mut GlobalCache<Self>) -> R, ) -> R; <ins> fn evaluation_is_concurrent(&self) -> bool; </ins> } pub trait Delegate {


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --After adding to , I get the ICE. The resulting : The full project: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --
Looks like another label: +T-types +WG-trait-system-refactor +regression-from-stable-to-nightly
Stable passes, beta passes. Nightly passes with either or Discovered with It does sporadically succeed, thus needing to clean and rerun the build to make sure. Either something is up with or it only barely exercises these conditions in the parallel frontend, even after cleaning and running the build 100 times. Meanwhile, fails something like ~50% of the time on my machine.
stable passes obviously, as -Zthreads this is a unstable nightly-only flag?
Hm, not actually obvious given that works, though I suppose that does mean it isn't a regression per se. :^)
oh I thought you knew by now that this is the forbidden env flag that should only ever be used for bootstrapping and nothing else and we should not even tell users about it. If you set the flag, your "stable" will also eat nightly-only features, but why would that make a "to-stable" regression if you explicitly tell the compiler "please act like you are NOT a stable release"? I don't think it make sense to backport fixes for untable nightly features into stable lol
who mentioned backports?
The label is used to gather regressions between release channels, which are then discussed whether they are backport-worthy or not. Is that not how the label is used?
I don't really think regression-from-stable-to-nightly nor regression-from-stable-to-stable are used for that at all? Probably regression-from-stable-to-beta is?

<ins> //@ compile-flags: -Zthreads=16 // original issue: https://github.com/rust-lang/rust/issues/129112 // Previously, the "next" solver asserted that each successful solution is only obtained once. // This test exhibits a repro that, with next-solver + -Zthreads, triggered that old assert. // In the presence of multithreaded solving, it's possible to concurrently evaluate things twice, // which leads to replacing already-solved solutions in the global solution cache! // We assume this is fine if we check to make sure they are solved the same way each time. // This test only nondeterministically fails but that's okay, as it will be rerun by CI many times, // so it should almost always fail before anything is merged. As other thread tests already exist, // we already face this difficulty, probably. If we need to fix this by reducing the error margin, // we should improve compiletest. #[derive(Clone, Eq)] //~ ERROR [E0277] pub struct Struct<T>(T); impl<T: Clone, U> PartialEq<U> for Struct<T> where U: Into<Struct<T>> + Clone { fn eq(&self, _other: &U) -> bool { todo!() } } fn main() {} </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --After adding to , I get the ICE. The resulting : The full project: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --
Looks like another label: +T-types +WG-trait-system-refactor +regression-from-stable-to-nightly
Stable passes, beta passes. Nightly passes with either or Discovered with It does sporadically succeed, thus needing to clean and rerun the build to make sure. Either something is up with or it only barely exercises these conditions in the parallel frontend, even after cleaning and running the build 100 times. Meanwhile, fails something like ~50% of the time on my machine.
stable passes obviously, as -Zthreads this is a unstable nightly-only flag?
Hm, not actually obvious given that works, though I suppose that does mean it isn't a regression per se. :^)
oh I thought you knew by now that this is the forbidden env flag that should only ever be used for bootstrapping and nothing else and we should not even tell users about it. If you set the flag, your "stable" will also eat nightly-only features, but why would that make a "to-stable" regression if you explicitly tell the compiler "please act like you are NOT a stable release"? I don't think it make sense to backport fixes for untable nightly features into stable lol
who mentioned backports?
The label is used to gather regressions between release channels, which are then discussed whether they are backport-worthy or not. Is that not how the label is used?
I don't really think regression-from-stable-to-nightly nor regression-from-stable-to-stable are used for that at all? Probably regression-from-stable-to-beta is?

<ins> error[E0277]: the trait bound `T: Clone` is not satisfied --> $DIR/global-cache-and-parallel-frontend.rs:15:17 | LL | #[derive(Clone, Eq)] |                 ^^ the trait `Clone` is not implemented for `T`, which is required by `Struct<T>: PartialEq` | note: required for `Struct<T>` to implement `PartialEq` --> $DIR/global-cache-and-parallel-frontend.rs:18:19 | LL | impl<T: Clone, U> PartialEq<U> for Struct<T> |         -----     ^^^^^^^^^^^^     ^^^^^^^^^ |         | |         unsatisfied trait bound introduced here note: required by a bound in `Eq` --> $SRC_DIR/core/src/cmp.rs:LL:COL = note: this error originates in the derive macro `Eq` (in Nightly builds, run with -Z macro-backtrace for more info) help: consider restricting type parameter `T` | LL | pub struct Struct<T: std::clone::Clone>(T); |                    +++++++++++++++++++ error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0277`. </ins>


Question: () Reproduces on the playground using . label +D-incorrect +F-gen_blocks +requires-nightly

} } <del> pub fn is_async(self) -> bool { matches!(self, CoroutineKind::Async { .. }) } pub fn is_gen(self) -> bool { matches!(self, CoroutineKind::Gen { .. }) </del> <ins> pub fn as_str(self) -> &'static str { match self { CoroutineKind::Async { .. } => "async", CoroutineKind::Gen { .. } => "gen", CoroutineKind::AsyncGen { .. } => "async gen", } </ins> } pub fn closure_id(self) -> NodeId {


Question: () Reproduces on the playground using . label +D-incorrect +F-gen_blocks +requires-nightly

ast_passes_bound_in_context = bounds on `type`s in {$ctx} have no effect <del> ast_passes_const_and_async = functions cannot be both `const` and `async` .const = `const` because of this .async = `async` because of this .label = {""} </del> ast_passes_const_and_c_variadic = functions cannot be both `const` and C-variadic .const = `const` because of this .variadic = C-variadic because of this <ins> ast_passes_const_and_coroutine = functions cannot be both `const` and `{$coroutine_kind}` .const = `const` because of this .coroutine = `{$coroutine_kind}` because of this .label = {""} </ins> ast_passes_const_bound_trait_object = const trait bounds are not allowed in trait object types ast_passes_const_without_body =


Question: () Reproduces on the playground using . label +D-incorrect +F-gen_blocks +requires-nightly

// Functions cannot both be `const async` or `const gen` if let Some(&FnHeader { <del> constness: Const::Yes(cspan), </del> <ins> constness: Const::Yes(const_span), </ins> coroutine_kind: Some(coroutine_kind), .. }) = fk.header() { <del> let aspan = match coroutine_kind { CoroutineKind::Async { span: aspan, .. } | CoroutineKind::Gen { span: aspan, .. } | CoroutineKind::AsyncGen { span: aspan, .. } => aspan, }; // FIXME(gen_blocks): Report a different error for `const gen` self.dcx().emit_err(errors::ConstAndAsync { spans: vec![cspan, aspan], cspan, aspan, </del> <ins> self.dcx().emit_err(errors::ConstAndCoroutine { spans: vec![coroutine_kind.span(), const_span], const_span, coroutine_span: coroutine_kind.span(), coroutine_kind: coroutine_kind.as_str(), </ins> span, }); }


Question: () Reproduces on the playground using . label +D-incorrect +F-gen_blocks +requires-nightly

} #[derive(Diagnostic)] <del> #[diag(ast_passes_const_and_async)] pub(crate) struct ConstAndAsync { </del> <ins> #[diag(ast_passes_const_and_coroutine)] pub(crate) struct ConstAndCoroutine { </ins> #[primary_span] pub spans: Vec<Span>, #[label(ast_passes_const)] <del> pub cspan: Span, #[label(ast_passes_async)] pub aspan: Span, </del> <ins> pub const_span: Span, #[label(ast_passes_coroutine)] pub coroutine_span: Span, </ins> #[label] pub span: Span, <ins> pub coroutine_kind: &'static str, </ins> } #[derive(Diagnostic)]


Question: () Reproduces on the playground using . label +D-incorrect +F-gen_blocks +requires-nightly

) => { eq_closure_binder(lb, rb) && lc == rc <del> && la.map_or(false, CoroutineKind::is_async) == ra.map_or(false, CoroutineKind::is_async) </del> <ins> && eq_coroutine_kind(*la, *ra) </ins> && lm == rm && eq_fn_decl(lf, rf) && eq_expr(le, re)


Question: () Reproduces on the playground using . label +D-incorrect +F-gen_blocks +requires-nightly

} } <ins> fn eq_coroutine_kind(a: Option<CoroutineKind>, b: Option<CoroutineKind>) -> bool { match (a, b) { (Some(CoroutineKind::Async { .. }), Some(CoroutineKind::Async { .. })) | (Some(CoroutineKind::Gen { .. }), Some(CoroutineKind::Gen { .. })) | (Some(CoroutineKind::AsyncGen { .. }), Some(CoroutineKind::AsyncGen { .. })) | (None, None) => true, _ => false, } } </ins> pub fn eq_field(l: &ExprField, r: &ExprField) -> bool { l.is_placeholder == r.is_placeholder && eq_id(l.ident, r.ident)


Question: () Reproduces on the playground using . label +D-incorrect +F-gen_blocks +requires-nightly

<ins> //@ edition:2024 //@ compile-flags: -Zunstable-options #![feature(gen_blocks)] const gen fn a() {} //~^ ERROR functions cannot be both `const` and `gen` const async gen fn b() {} //~^ ERROR functions cannot be both `const` and `async gen` fn main() {} </ins>


Question: () Reproduces on the playground using . label +D-incorrect +F-gen_blocks +requires-nightly

<ins> error: functions cannot be both `const` and `gen` --> $DIR/const_gen_fn.rs:6:1 | LL | const gen fn a() {} | ^^^^^-^^^---------- | |     | | |     `gen` because of this | `const` because of this error: functions cannot be both `const` and `async gen` --> $DIR/const_gen_fn.rs:9:1 | LL | const async gen fn b() {} | ^^^^^-^^^^^^^^^---------- | |     | | |     `async gen` because of this | `const` because of this error: aborting due to 2 previous errors </ins>


Question:
The error message doesn't say that the problem is mismatching mutability.
Looks like this can be closed, this is now: Edit: though now the complaint might be that it doesn't single out 'other'
Flagging as needstest (just in case a test doesn't already exist)

<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. trait Foo { fn bar(&mut self, other: &mut Foo); } struct Baz; impl Foo for Baz { fn bar(&mut self, other: &Foo) {} //~^ ERROR method `bar` has an incompatible type for trait: values differ in mutability [E0053] } fn main() {} </ins>


Question:
The error message doesn't say that the problem is mismatching mutability.
Looks like this can be closed, this is now: Edit: though now the complaint might be that it doesn't single out 'other'
Flagging as needstest (just in case a test doesn't already exist)

<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![feature(overloaded_calls)] use std::{fmt, ops}; struct Shower<T> { x: T } impl<T: fmt::Show> ops::Fn<(), ()> for Shower<T> { fn call(&self, _args: ()) { //~^ ERROR `call` has an incompatible type for trait: expected "rust-call" fn but found "Rust" fn println!("{}", self.x); } } fn make_shower<T>(x: T) -> Shower<T> { Shower { x: x } } pub fn main() { let show3 = make_shower(3i); show3(); } </ins>


Question:
The error message doesn't say that the problem is mismatching mutability.
Looks like this can be closed, this is now: Edit: though now the complaint might be that it doesn't single out 'other'
Flagging as needstest (just in case a test doesn't already exist)

<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. enum Foo { A = 1i64, //~^ ERROR mismatched types: expected `int` but found `i64` B = 2u8 //~^ ERROR mismatched types: expected `int` but found `u8` } fn main() {} </ins>


Question:
The error message doesn't say that the problem is mismatching mutability.
Looks like this can be closed, this is now: Edit: though now the complaint might be that it doesn't single out 'other'
Flagging as needstest (just in case a test doesn't already exist)

<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { if true { return } match () { () => { static MAGIC: uint = 0; } } } </ins>


Question:
upstream/master:
Does that build include the fix in
Yes, include. 6:45 "Huon Wilson" notifications
Thanks for confirming. cc
Reproduced on revision . Note that I'm using win 8.1 with non-english locale which probably causes issues. Quick investigation: then convert the code into string. It seems that failed with .
So the issue is broken into two parts: 1. why rustdoc failed and called ? 2. why failed?

buf.len() as DWORD, ptr::null()); if res == 0 { <del> fail!("[{}] FormatMessage failure", errno()); </del> <ins> // Sometimes FormatMessageW can fail e.g. system doesn't like langId, let fm_err = errno(); return format!("OS Error {} (FormatMessageW() returned error {})", err, fm_err); </ins> } <del> str::from_utf16(str::truncate_utf16_at_nul(buf)) .expect("FormatMessageW returned invalid UTF-16") </del> <ins> let msg = str::from_utf16(str::truncate_utf16_at_nul(buf)); match msg { Some(msg) => format!("OS Error {}: {}", err, msg), None => format!("OS Error {} (FormatMessageW() returned invalid UTF-16)", err), } </ins> } }


Question:
The crater run for merged doctests () detected a large number of regressions due to tests examining the process arguments. (I don't have an exact number, but let's say ~50 projects.) Previously, there were no arguments, but now it gets arguments like which the user's CLI parsing code isn't expecting. For example, using something like  will now fail. It seems to be fairly common to have objects whose default constructor will parse the arguments from the command line. I'm not sure if or how we should resolve that. One idea is to use a different mechanism for passing in the test information (like via an environment variable).
I vaguely remember that using environment variables was discussed but can't find anything except mentioning it . Maybe it'd be a better approach indeed. Let me send a PR so we can make a crater run on it.

} else { cmd = Command::new(&output_file); if doctest.is_multiple_tests { <del> cmd.arg("*doctest-bin-path"); cmd.arg(&output_file); </del> <ins> cmd.env("RUSTDOC_DOCTEST_BIN_PATH", &output_file); </ins> } } if let Some(run_directory) = &rustdoc_options.test_run_directory {