Question:
Instead, this happened: Successful compilation Tested on the playground, all versions and editions. Stable channel: 1.64.0 Beta channel: 1.65.0-beta.3 (2022-10-10 ) Nightly channel: 1.66.0-nightly (2022-10-19 ) I'm labeling this as a regression as I believe it is severe enough of an unplanned change (at best an accidental stabilization?) that I should draw attention to it, even though I haven't found a way to cause miscompilation for example. I also have not tried to do so at all yet. label +T-compiler +A-lifetimes +regression-from-stable-to-stable <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2022-01-01 to nightly-2022-10-01 regressed nightly: nightly-2022-07-26 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
claim
Actually, this behavior is correct as : There is exactly one lifetime used in the parameters (), so assigning it to the output lifetime is as expected. release-assignment
That verbiage but it compiles on no stable version of rustc prior to 1.64, so I don't think it's actually relevant. (The reference is also explicitly non-normative.) mirrors in specifying input positions, not counts. Regardless of documentation, as something that has not compiled on Rust 1.0--1.63 but compiles today, this is clearly a change in language behavior without FCP which I believe to be unintentional. label +T-lang
Ok, so we will consider this for now a regression that should be backported to stable (we're ~2 weeks away from the new release). WG-prioritization assigning priority (). label -I-prioritize +P-critical
Filed
Nominating for lang team to figure out what we should do with this. Will also ping on zulip.
Discussed in lang, dropping nomination. Agreement that we want to revert the change in behavior and backport that to 1.65 (and 1.64, but that's not happening given short time window). Considering whether we want to make the behavior change can happen in a follow-up proposal.

LL | fn k<'a, T: WithLifetime<'a>>(_x: T::Output) -> &'a isize { |                                                  ++ <del> error: aborting due to 6 previous errors </del> <ins> error[E0106]: missing lifetime specifier --> $DIR/lifetime-elision-return-type-requires-explicit-lifetime.rs:45:37 | LL | fn l<'a>(_: &'a str, _: &'a str) -> &str { "" } |             -------     -------     ^ expected named lifetime parameter | = help: this function's return type contains a borrowed value with an elided lifetime, but the lifetime cannot be derived from the arguments help: consider using the `'a` lifetime | LL | fn l<'a>(_: &'a str, _: &'a str) -> &'a str { "" } |                                      ++ error: aborting due to 7 previous errors </ins> For more information about this error, try `rustc --explain E0106`.


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 program terminates. Instead, this happened: The program loops indefinitely. I encountered this while working on <!-- 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. --:
Hangs here: label I-hang
CC
Thanks for the report. Priority wise, this seems like it isn’t going to be super high priority to resolve, given that 1<<47 is 128TiB. 128TiB, unfortunately, is half of the maximum supported address space on many modern x8664 and aarch64 deployments, so it is conceivable that this could be actually hit. Still would be nice to actually fix it. As for the strategies to fix this, there are a couple of approaches to consider: could store the into a u128 (2 usize on any supported platform today.) This is not super future-proof, and unfortunately probably somewhat more costly in the non-const-evaluated case. could use instead of . When overflows on the last iteration, it will become the maximum value that fits in and the termination condition will be hit. Not super clear what codegen quality implications are for using saturatingmul; a widening/checked multiplication and additionally compare the high bits for in the terminating condition. This is an alteration of 1. I suspect this is going to produce the best code, but that remains to be seen.
Would it work to change the termination condition from to ? Where means it wrapped, so the logical value is out of the type's range, and thus bigger than .
Or weirder: store instead of , so the comparison can be done using and the squaring operation can be replaced with a doubling (bit shift).

// FIXME(#75598): Direct use of these intrinsics improves codegen significantly at opt-level <= // 1, where the method versions of these operations are not inlined. use intrinsics::{ <del> cttz_nonzero, exact_div, unchecked_rem, unchecked_shl, unchecked_shr, unchecked_sub, wrapping_add, wrapping_mul, wrapping_sub, </del> <ins> cttz_nonzero, exact_div, mul_with_overflow, unchecked_rem, unchecked_shl, unchecked_shr, unchecked_sub, wrapping_add, wrapping_mul, wrapping_sub, </ins> }; /// Calculate multiplicative modular inverse of `x` modulo `m`.


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 program terminates. Instead, this happened: The program loops indefinitely. I encountered this while working on <!-- 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. --:
Hangs here: label I-hang
CC
Thanks for the report. Priority wise, this seems like it isn’t going to be super high priority to resolve, given that 1<<47 is 128TiB. 128TiB, unfortunately, is half of the maximum supported address space on many modern x8664 and aarch64 deployments, so it is conceivable that this could be actually hit. Still would be nice to actually fix it. As for the strategies to fix this, there are a couple of approaches to consider: could store the into a u128 (2 usize on any supported platform today.) This is not super future-proof, and unfortunately probably somewhat more costly in the non-const-evaluated case. could use instead of . When overflows on the last iteration, it will become the maximum value that fits in and the termination condition will be hit. Not super clear what codegen quality implications are for using saturatingmul; a widening/checked multiplication and additionally compare the high bits for in the terminating condition. This is an alteration of 1. I suspect this is going to produce the best code, but that remains to be seen.
Would it work to change the termination condition from to ? Where means it wrapped, so the logical value is out of the type's range, and thus bigger than .
Or weirder: store instead of , so the comparison can be done using and the squaring operation can be replaced with a doubling (bit shift).

const INV_TABLE_MOD_16: [u8; 8] = [1, 11, 13, 7, 9, 3, 5, 15]; /// Modulo for which the `INV_TABLE_MOD_16` is intended. const INV_TABLE_MOD: usize = 16; <del> /// INV_TABLE_MOD² const INV_TABLE_MOD_SQUARED: usize = INV_TABLE_MOD * INV_TABLE_MOD; let table_inverse = INV_TABLE_MOD_16[(x & (INV_TABLE_MOD - 1)) >> 1] as usize; </del> // SAFETY: `m` is required to be a power-of-two, hence non-zero. let m_minus_one = unsafe { unchecked_sub(m, 1) }; <del> if m <= INV_TABLE_MOD { table_inverse & m_minus_one } else { // We iterate "up" using the following formula: // // $$ xy ≡ 1 (mod 2ⁿ) → xy (2 - xy) ≡ 1 (mod 2²ⁿ) $$ </del> <ins> let mut inverse = INV_TABLE_MOD_16[(x & (INV_TABLE_MOD - 1)) >> 1] as usize; let mut mod_gate = INV_TABLE_MOD; // We iterate "up" using the following formula: // // $$ xy ≡ 1 (mod 2ⁿ) → xy (2 - xy) ≡ 1 (mod 2²ⁿ) $$ // // This application needs to be applied at least until `2²ⁿ ≥ m`, at which point we can // finally reduce the computation to our desired `m` by taking `inverse mod m`. // // This computation is `O(log log m)`, which is to say, that on 64-bit machines this loop // will always finish in at most 4 iterations. loop { // y = y * (2 - xy) mod n </ins> // <del> // until 2²ⁿ ≥ m. Then we can reduce to our desired `m` by taking the result `mod m`. let mut inverse = table_inverse; let mut going_mod = INV_TABLE_MOD_SQUARED; loop { // y = y * (2 - xy) mod n // // Note, that we use wrapping operations here intentionally – the original formula // uses e.g., subtraction `mod n`. It is entirely fine to do them `mod // usize::MAX` instead, because we take the result `mod n` at the end // anyway. inverse = wrapping_mul(inverse, wrapping_sub(2usize, wrapping_mul(x, inverse))); if going_mod >= m { return inverse & m_minus_one; } going_mod = wrapping_mul(going_mod, going_mod); </del> <ins> // Note, that we use wrapping operations here intentionally – the original formula // uses e.g., subtraction `mod n`. It is entirely fine to do them `mod // usize::MAX` instead, because we take the result `mod n` at the end // anyway. if mod_gate >= m { break; } inverse = wrapping_mul(inverse, wrapping_sub(2usize, wrapping_mul(x, inverse))); let (new_gate, overflow) = mul_with_overflow(mod_gate, mod_gate); if overflow { break; </ins> } <ins> mod_gate = new_gate; </ins> } <ins> inverse & m_minus_one </ins> } let addr = p.addr();


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 program terminates. Instead, this happened: The program loops indefinitely. I encountered this while working on <!-- 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. --:
Hangs here: label I-hang
CC
Thanks for the report. Priority wise, this seems like it isn’t going to be super high priority to resolve, given that 1<<47 is 128TiB. 128TiB, unfortunately, is half of the maximum supported address space on many modern x8664 and aarch64 deployments, so it is conceivable that this could be actually hit. Still would be nice to actually fix it. As for the strategies to fix this, there are a couple of approaches to consider: could store the into a u128 (2 usize on any supported platform today.) This is not super future-proof, and unfortunately probably somewhat more costly in the non-const-evaluated case. could use instead of . When overflows on the last iteration, it will become the maximum value that fits in and the termination condition will be hit. Not super clear what codegen quality implications are for using saturatingmul; a widening/checked multiplication and additionally compare the high bits for in the terminating condition. This is an alteration of 1. I suspect this is going to produce the best code, but that remains to be seen.
Would it work to change the termination condition from to ? Where means it wrapped, so the logical value is out of the type's range, and thus bigger than .
Or weirder: store instead of , so the comparison can be done using and the squaring operation can be replaced with a doubling (bit shift).

} #[test] <ins> fn align_offset_issue_103361() { #[cfg(target_pointer_width = "64")] const SIZE: usize = 1 << 47; #[cfg(target_pointer_width = "32")] const SIZE: usize = 1 << 30; #[cfg(target_pointer_width = "16")] const SIZE: usize = 1 << 13; struct HugeSize([u8; SIZE - 1]); let _ = (SIZE as *const HugeSize).align_offset(SIZE); } #[test] </ins> fn offset_from() { let mut a = [0; 5]; let ptr1: *mut i32 = &mut a[1];


Question:
: Fails on nightly 1.66.0 but not on stable 1.64.0. <details<summary<strongBacktrace</strong</summary<p</p</detailsEdited: minified the code
Also ICEs on beta
stable error -beta ICE I tried moving things around so lifetime is on , but that's fine. This also requires the lifetime .
Going to preemptively assign P-medium, since this code isn't correct anyways. I think this has something to do with our error recovery here, since this valid code is fine, which only changes the trait:
I got a fix here.

add_constraints(&infcx, region_bound_pairs); <ins> infcx.process_registered_region_obligations( outlives_environment.region_bound_pairs(), param_env, ); </ins> let errors = infcx.resolve_regions(&outlives_environment); debug!(?errors, "errors");


Question:
: Fails on nightly 1.66.0 but not on stable 1.64.0. <details<summary<strongBacktrace</strong</summary<p</p</detailsEdited: minified the code
Also ICEs on beta
stable error -beta ICE I tried moving things around so lifetime is on , but that's fine. This also requires the lifetime .
Going to preemptively assign P-medium, since this code isn't correct anyways. I think this has something to do with our error recovery here, since this valid code is fine, which only changes the trait:
I got a fix here.

<ins> trait TraitA { type TypeA; } trait TraitD { type TypeD; } pub trait TraitB { type TypeB: TraitD; fn f(_: &<Self::TypeB as TraitD>::TypeD); } pub trait TraitC<E> { type TypeC<'a>: TraitB; fn g<'a>(_: &<<Self::TypeC<'a> as TraitB>::TypeB as TraitA>::TypeA); //~^ ERROR the trait bound `<<Self as TraitC<E>>::TypeC<'a> as TraitB>::TypeB: TraitA` is not satisfied } fn main() {} </ins>


Question:
: Fails on nightly 1.66.0 but not on stable 1.64.0. <details<summary<strongBacktrace</strong</summary<p</p</detailsEdited: minified the code
Also ICEs on beta
stable error -beta ICE I tried moving things around so lifetime is on , but that's fine. This also requires the lifetime .
Going to preemptively assign P-medium, since this code isn't correct anyways. I think this has something to do with our error recovery here, since this valid code is fine, which only changes the trait:
I got a fix here.

<ins> error[E0277]: the trait bound `<<Self as TraitC<E>>::TypeC<'a> as TraitB>::TypeB: TraitA` is not satisfied --> $DIR/issue-103573.rs:18:5 | LL |     fn g<'a>(_: &<<Self::TypeC<'a> as TraitB>::TypeB as TraitA>::TypeA); |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `TraitA` is not implemented for `<<Self as TraitC<E>>::TypeC<'a> as TraitB>::TypeB` | help: consider further restricting the associated type | LL |     fn g<'a>(_: &<<Self::TypeC<'a> as TraitB>::TypeB as TraitA>::TypeA) where <<Self as TraitC<E>>::TypeC<'a> as TraitB>::TypeB: TraitA; |                                                                         +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>


Question:
<details<summary<strongFull output including backtrace</strong</summary<p</p</detailsRegression from () <details<summaryBisection details</summarybisected with <a href=''cargo-bisect-rustc</av0.6.4 searched nightlies: from nightly-2022-10-06 to nightly-2022-10-28 regressed nightly: nightly-2022-10-09 searched commit range: regressed commit: Host triple: x8664-apple-darwin </details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
this function call crash for the assertion fail, from the log, is with count = 1, and is also 1 when crashing. Do you have any clue? is implemented at here, I'm still not quite familar with the query part:
It looks like the parens are parsed as generic parameters for a type that doesn't have generic parameters? The simple fix is just check .
I think a reasonable fix is modifying the API for , It reasonable to add assertion for , but it's better to return false for outside of expected range?
Have a test on C++'s , which also has this assertion: emm, it's better to keep it for .
claim
I'd be curious to know if we can maintain an invariant in the HIR that it does not contain generics that do not align with . That was what I assumed when writing that code, but that may be too optimistic.
I considered removing the assert too, but I think it's better to have it since it exposes invalid assumptions as in this case.
We should (replacing the assertion) -- that's probably fine as long as it's understood why the does not line up here, and it's understood why we can't fix it somewhere upstream (e.g. in parsing or lowering instead)
I have a general question for , why we just exit when we find a fatal error in parsing (which can not recover by simply autofix). I have a real Dev experience when working on , I was editing an file with 3k+ lines of code, and I forgetted remove an extra '{', then the compiler give about 20+ errors, the first two are from parsing: But there are many many other errors from later phases... I need to scroll up several pages to the beginning of error to find the rootcause.
If we can not get valid AST in parsing, later phases such as analysising will report out extra (mostly unhelpful) errors?
The assertion is inside of the data structure. I generally expect data structures to simply assert on pre-conditions. We could put a delay-bug before the call, but that also seems like overkill since that is already on the error-reporting path. I agree there are cases where rustc should quit sooner. But in general I think we have to err on the side of recover-and-continue if there is some possibility that more helpful errors may be emitted.
This can happen. The parser should be more realistic on what it recovers and avoid errors from later passes that do not make sense. A few years back we would stop as soon as any error occurred in a given pass and avoid trying any further evaluation, and that was also a usability issue, because people would get a false sense of "how much work is left to fix". We shouldn't have a blanket evaluation stop, but maybe be more aggressive about pruning the AST when multiple parse errors have occurred.
do you want to take over this issue? I currently don't have any clue about the rootcause. Or we give it an simple fix now.
I can take a look.

}); if check_params && let Some(args) = path.segments.last().unwrap().args { let params_in_repr = tcx.params_in_repr(def_id); <del> for (i, arg) in args.args.iter().enumerate() { </del> <ins> // the domain size check is needed because the HIR may not be well-formed at this point for (i, arg) in args.args.iter().enumerate().take(params_in_repr.domain_size()) { </ins> if let hir::GenericArg::Type(ty) = arg && params_in_repr.contains(i as u32) { find_item_ty_spans(tcx, ty, needle, spans, seen_representable); }


Question:
<details<summary<strongFull output including backtrace</strong</summary<p</p</detailsRegression from () <details<summaryBisection details</summarybisected with <a href=''cargo-bisect-rustc</av0.6.4 searched nightlies: from nightly-2022-10-06 to nightly-2022-10-28 regressed nightly: nightly-2022-10-09 searched commit range: regressed commit: Host triple: x8664-apple-darwin </details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
this function call crash for the assertion fail, from the log, is with count = 1, and is also 1 when crashing. Do you have any clue? is implemented at here, I'm still not quite familar with the query part:
It looks like the parens are parsed as generic parameters for a type that doesn't have generic parameters? The simple fix is just check .
I think a reasonable fix is modifying the API for , It reasonable to add assertion for , but it's better to return false for outside of expected range?
Have a test on C++'s , which also has this assertion: emm, it's better to keep it for .
claim
I'd be curious to know if we can maintain an invariant in the HIR that it does not contain generics that do not align with . That was what I assumed when writing that code, but that may be too optimistic.
I considered removing the assert too, but I think it's better to have it since it exposes invalid assumptions as in this case.
We should (replacing the assertion) -- that's probably fine as long as it's understood why the does not line up here, and it's understood why we can't fix it somewhere upstream (e.g. in parsing or lowering instead)
I have a general question for , why we just exit when we find a fatal error in parsing (which can not recover by simply autofix). I have a real Dev experience when working on , I was editing an file with 3k+ lines of code, and I forgetted remove an extra '{', then the compiler give about 20+ errors, the first two are from parsing: But there are many many other errors from later phases... I need to scroll up several pages to the beginning of error to find the rootcause.
If we can not get valid AST in parsing, later phases such as analysising will report out extra (mostly unhelpful) errors?
The assertion is inside of the data structure. I generally expect data structures to simply assert on pre-conditions. We could put a delay-bug before the call, but that also seems like overkill since that is already on the error-reporting path. I agree there are cases where rustc should quit sooner. But in general I think we have to err on the side of recover-and-continue if there is some possibility that more helpful errors may be emitted.
This can happen. The parser should be more realistic on what it recovers and avoid errors from later passes that do not make sense. A few years back we would stop as soon as any error occurred in a given pass and avoid trying any further evaluation, and that was also a usability issue, because people would get a false sense of "how much work is left to fix". We shouldn't have a blanket evaluation stop, but maybe be more aggressive about pruning the AST when multiple parse errors have occurred.
do you want to take over this issue? I currently don't have any clue about the rootcause. Or we give it an simple fix now.
I can take a look.

<ins> #![crate_type = "lib"] struct Apple((Apple, Option(Banana ? Citron))); //~^ ERROR invalid `?` in type //~| ERROR expected one of `)` or `,`, found `Citron` //~| ERROR cannot find type `Citron` in this scope [E0412] //~| ERROR parenthesized type parameters may only be used with a `Fn` trait [E0214] //~| ERROR recursive type `Apple` has infinite size [E0072] </ins>


Question:
<details<summary<strongFull output including backtrace</strong</summary<p</p</detailsRegression from () <details<summaryBisection details</summarybisected with <a href=''cargo-bisect-rustc</av0.6.4 searched nightlies: from nightly-2022-10-06 to nightly-2022-10-28 regressed nightly: nightly-2022-10-09 searched commit range: regressed commit: Host triple: x8664-apple-darwin </details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
this function call crash for the assertion fail, from the log, is with count = 1, and is also 1 when crashing. Do you have any clue? is implemented at here, I'm still not quite familar with the query part:
It looks like the parens are parsed as generic parameters for a type that doesn't have generic parameters? The simple fix is just check .
I think a reasonable fix is modifying the API for , It reasonable to add assertion for , but it's better to return false for outside of expected range?
Have a test on C++'s , which also has this assertion: emm, it's better to keep it for .
claim
I'd be curious to know if we can maintain an invariant in the HIR that it does not contain generics that do not align with . That was what I assumed when writing that code, but that may be too optimistic.
I considered removing the assert too, but I think it's better to have it since it exposes invalid assumptions as in this case.
We should (replacing the assertion) -- that's probably fine as long as it's understood why the does not line up here, and it's understood why we can't fix it somewhere upstream (e.g. in parsing or lowering instead)
I have a general question for , why we just exit when we find a fatal error in parsing (which can not recover by simply autofix). I have a real Dev experience when working on , I was editing an file with 3k+ lines of code, and I forgetted remove an extra '{', then the compiler give about 20+ errors, the first two are from parsing: But there are many many other errors from later phases... I need to scroll up several pages to the beginning of error to find the rootcause.
If we can not get valid AST in parsing, later phases such as analysising will report out extra (mostly unhelpful) errors?
The assertion is inside of the data structure. I generally expect data structures to simply assert on pre-conditions. We could put a delay-bug before the call, but that also seems like overkill since that is already on the error-reporting path. I agree there are cases where rustc should quit sooner. But in general I think we have to err on the side of recover-and-continue if there is some possibility that more helpful errors may be emitted.
This can happen. The parser should be more realistic on what it recovers and avoid errors from later passes that do not make sense. A few years back we would stop as soon as any error occurred in a given pass and avoid trying any further evaluation, and that was also a usability issue, because people would get a false sense of "how much work is left to fix". We shouldn't have a blanket evaluation stop, but maybe be more aggressive about pruning the AST when multiple parse errors have occurred.
do you want to take over this issue? I currently don't have any clue about the rootcause. Or we give it an simple fix now.
I can take a look.

<ins> error: invalid `?` in type --> $DIR/issue-103748-ICE-wrong-braces.rs:3:36 | LL | struct Apple((Apple, Option(Banana ? Citron))); |                                    ^ `?` is only allowed on expressions, not types | help: if you meant to express that the type might not contain a value, use the `Option` wrapper type | LL | struct Apple((Apple, Option(Option<Banana > Citron))); |                             +++++++       ~ error: expected one of `)` or `,`, found `Citron` --> $DIR/issue-103748-ICE-wrong-braces.rs:3:38 | LL | struct Apple((Apple, Option(Banana ? Citron))); |                                     -^^^^^^ expected one of `)` or `,` |                                     | |                                     help: missing `,` error[E0412]: cannot find type `Citron` in this scope --> $DIR/issue-103748-ICE-wrong-braces.rs:3:38 | LL | struct Apple((Apple, Option(Banana ? Citron))); |                                      ^^^^^^ not found in this scope error[E0214]: parenthesized type parameters may only be used with a `Fn` trait --> $DIR/issue-103748-ICE-wrong-braces.rs:3:22 | LL | struct Apple((Apple, Option(Banana ? Citron))); |                      ^^^^^^^^^^^^^^^^^^^^^^^ only `Fn` traits may use parentheses | help: use angle brackets instead | LL | struct Apple((Apple, Option<Banana ? Citron>)); |                            ~               ~ error[E0072]: recursive type `Apple` has infinite size --> $DIR/issue-103748-ICE-wrong-braces.rs:3:1 | LL | struct Apple((Apple, Option(Banana ? Citron))); | ^^^^^^^^^^^^  ----- recursive without indirection | help: insert some indirection (e.g., a `Box`, `Rc`, or `&`) to break the cycle | LL | struct Apple((Box<Apple>, Option(Banana ? Citron))); |               ++++     + error: aborting due to 5 previous errors Some errors have detailed explanations: E0072, E0214, E0412. For more information about an error, try `rustc --explain E0072`. </ins>


Question:
Our CI system building artifact for aarch64 with the release of Rust 1.65 I tried to reduce the bug a bit: dependencies Build with (same with ) Since Rust 1.65, we get this error: Can still be reproduced in nightly
I wasn't able to reproduce this (on either stable or nightly).
You're right, trying in a fresh project i couldn't reproduce. I realized the original also contained a that was also necessary I edited the original description to add Thanks for looking into this.
Also, contrary to what i wrote initially, the bug appeared first in 1.65 (and not 1.64)
Thanks, I can reproduce the issue now. Reduced test case:
Upstream issue:
The upstream issue appears to be fixed. What needs to be done now to apply this fix?
I can still reproduce this on 1.68.0-nightly ( 2022-12-15).
Can confirm that the issue still exists.
New upstream issue:

[submodule "src/llvm-project"] path = src/llvm-project url = https://github.com/rust-lang/llvm-project.git <del> branch = rustc/15.0-2022-08-09 </del> <ins> branch = rustc/15.0-2022-12-07 </ins> [submodule "src/doc/embedded-book"] path = src/doc/embedded-book url = https://github.com/rust-embedded/book.git


Question:
Our CI system building artifact for aarch64 with the release of Rust 1.65 I tried to reduce the bug a bit: dependencies Build with (same with ) Since Rust 1.65, we get this error: Can still be reproduced in nightly
I wasn't able to reproduce this (on either stable or nightly).
You're right, trying in a fresh project i couldn't reproduce. I realized the original also contained a that was also necessary I edited the original description to add Thanks for looking into this.
Also, contrary to what i wrote initially, the bug appeared first in 1.65 (and not 1.64)
Thanks, I can reproduce the issue now. Reduced test case:
Upstream issue:
The upstream issue appears to be fixed. What needs to be done now to apply this fix?
I can still reproduce this on 1.68.0-nightly ( 2022-12-15).
Can confirm that the issue still exists.
New upstream issue:

<del> Subproject commit a1232c451fc27173f8718e05d174b2503ca0b607 </del> <ins> Subproject commit 3dfd4d93fa013e1c0578d3ceac5c8f4ebba4b6ec </ins>


Question:
Our CI system building artifact for aarch64 with the release of Rust 1.65 I tried to reduce the bug a bit: dependencies Build with (same with ) Since Rust 1.65, we get this error: Can still be reproduced in nightly
I wasn't able to reproduce this (on either stable or nightly).
You're right, trying in a fresh project i couldn't reproduce. I realized the original also contained a that was also necessary I edited the original description to add Thanks for looking into this.
Also, contrary to what i wrote initially, the bug appeared first in 1.65 (and not 1.64)
Thanks, I can reproduce the issue now. Reduced test case:
Upstream issue:
The upstream issue appears to be fixed. What needs to be done now to apply this fix?
I can still reproduce this on 1.68.0-nightly ( 2022-12-15).
Can confirm that the issue still exists.
New upstream issue:

<del> Subproject commit 3dfd4d93fa013e1c0578d3ceac5c8f4ebba4b6ec </del> <ins> Subproject commit 9ad24035fea8d309753f5e39e6eb53d1d0eb39ce </ins>


Question:
<details<summary<bbacktrace</b</summary</details<details<summary<bfull stderr (two panics / backtraces)</b</summary</details: label requires-nightly A-associated-items F-inherentassociatedtypes
Context: The recent PR implemented the resolution of inherent associated types but it appears that parameter substitution was overlooked.

assert!(self_ty.is_some()); } } else { <del> assert!(self_ty.is_none() && parent_substs.is_empty()); </del> <ins> assert!(self_ty.is_none()); </ins> } let arg_count = Self::check_generic_arg_count(


Question:
<details<summary<bbacktrace</b</summary</details<details<summary<bfull stderr (two panics / backtraces)</b</summary</details: label requires-nightly A-associated-items F-inherentassociatedtypes
Context: The recent PR implemented the resolution of inherent associated types but it appears that parameter substitution was overlooked.

// Check if we have an enum variant. let mut variant_resolution = None; <del> if let ty::Adt(adt_def, _) = qself_ty.kind() { </del> <ins> if let ty::Adt(adt_def, adt_substs) = qself_ty.kind() { </ins> if adt_def.is_enum() { let variant_def = adt_def .variants()


Question:
<details<summary<bbacktrace</b</summary</details<details<summary<bfull stderr (two panics / backtraces)</b</summary</details: label requires-nightly A-associated-items F-inherentassociatedtypes
Context: The recent PR implemented the resolution of inherent associated types but it appears that parameter substitution was overlooked.

let Some(assoc_ty_did) = self.lookup_assoc_ty(assoc_ident, hir_ref_id, span, impl_) else { continue; }; <del> // FIXME(inherent_associated_types): This does not substitute parameters. let ty = tcx.type_of(assoc_ty_did); </del> <ins> let item_substs = self.create_substs_for_associated_item( span, assoc_ty_did, assoc_segment, adt_substs, ); let ty = tcx.bound_type_of(assoc_ty_did).subst(tcx, item_substs); </ins> return Ok((ty, DefKind::AssocTy, assoc_ty_did)); } }


Question:
<details<summary<bbacktrace</b</summary</details<details<summary<bfull stderr (two panics / backtraces)</b</summary</details: label requires-nightly A-associated-items F-inherentassociatedtypes
Context: The recent PR implemented the resolution of inherent associated types but it appears that parameter substitution was overlooked.

<ins> // check-pass #![feature(inherent_associated_types)] #![allow(incomplete_features)] struct S<T>(T); impl<T> S<T> { type P = T; } fn main() { type A = S<()>::P; let _: A = (); } </ins>


Question:
In the following code, I can successfully refer to the private inherent associated type : I expected to see an error denying the access. If the associated item was a constant, this would indeed be the case: : label T-compiler requires-nightly A-associated-items A-visibility F-inherentassociatedtypes <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

} // see if we can satisfy using an inherent associated type <del> for impl_ in tcx.inherent_impls(adt_def.did()) { let assoc_ty = tcx.associated_items(impl_).find_by_name_and_kind( tcx, assoc_ident, ty::AssocKind::Type, *impl_, ); if let Some(assoc_ty) = assoc_ty { let ty = tcx.type_of(assoc_ty.def_id); return Ok((ty, DefKind::AssocTy, assoc_ty.def_id)); } </del> <ins> for &impl_ in tcx.inherent_impls(adt_def.did()) { let Some(assoc_ty_did) = self.lookup_assoc_ty(assoc_ident, hir_ref_id, span, impl_) else { continue; }; // FIXME(inherent_associated_types): This does not substitute parameters. let ty = tcx.type_of(assoc_ty_did); return Ok((ty, DefKind::AssocTy, assoc_ty_did)); </ins> } }


Question:
In the following code, I can successfully refer to the private inherent associated type : I expected to see an error denying the access. If the associated item was a constant, this would indeed be the case: : label T-compiler requires-nightly A-associated-items A-visibility F-inherentassociatedtypes <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

}; let trait_did = bound.def_id(); <del> let (assoc_ident, def_scope) = tcx.adjust_ident_and_get_scope(assoc_ident, trait_did, hir_ref_id); // We have already adjusted the item name above, so compare with `ident.normalize_to_macros_2_0()` instead // of calling `filter_by_name_and_kind`. let item = tcx.associated_items(trait_did).in_definition_order().find(|i| { i.kind.namespace() == Namespace::TypeNS && i.ident(tcx).normalize_to_macros_2_0() == assoc_ident }); // Assume that if it's not matched, there must be a const defined with the same name // but it was used in a type position. let Some(item) = item else { </del> <ins> let Some(assoc_ty_did) = self.lookup_assoc_ty(assoc_ident, hir_ref_id, span, trait_did) else { // Assume that if it's not matched, there must be a const defined with the same name // but it was used in a type position. </ins> let msg = format!("found associated const `{assoc_ident}` when type was expected"); let guar = tcx.sess.struct_span_err(span, &msg).emit(); return Err(guar); }; <del> let ty = self.projected_ty_from_poly_trait_ref(span, item.def_id, assoc_segment, bound); </del> <ins> let ty = self.projected_ty_from_poly_trait_ref(span, assoc_ty_did, assoc_segment, bound); </ins> let ty = self.normalize_ty(span, ty); <del> let kind = DefKind::AssocTy; if !item.visibility(tcx).is_accessible_from(def_scope, tcx) { let kind = kind.descr(item.def_id); let msg = format!("{} `{}` is private", kind, assoc_ident); tcx.sess .struct_span_err(span, &msg) .span_label(span, &format!("private {}", kind)) .emit(); } tcx.check_stability(item.def_id, Some(hir_ref_id), span, None); </del> if let Some(variant_def_id) = variant_resolution { tcx.struct_span_lint_hir( AMBIGUOUS_ASSOCIATED_ITEMS,


Question:
In the following code, I can successfully refer to the private inherent associated type : I expected to see an error denying the access. If the associated item was a constant, this would indeed be the case: : label T-compiler requires-nightly A-associated-items A-visibility F-inherentassociatedtypes <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

}; could_refer_to(DefKind::Variant, variant_def_id, ""); <del> could_refer_to(kind, item.def_id, " also"); </del> <ins> could_refer_to(DefKind::AssocTy, assoc_ty_did, " also"); </ins> lint.span_suggestion( span,


Question:
In the following code, I can successfully refer to the private inherent associated type : I expected to see an error denying the access. If the associated item was a constant, this would indeed be the case: : label T-compiler requires-nightly A-associated-items A-visibility F-inherentassociatedtypes <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

}, ); } <del> Ok((ty, kind, item.def_id)) </del> <ins> Ok((ty, DefKind::AssocTy, assoc_ty_did)) } fn lookup_assoc_ty( &self, ident: Ident, block: hir::HirId, span: Span, scope: DefId, ) -> Option<DefId> { let tcx = self.tcx(); let (ident, def_scope) = tcx.adjust_ident_and_get_scope(ident, scope, block); // We have already adjusted the item name above, so compare with `ident.normalize_to_macros_2_0()` instead // of calling `find_by_name_and_kind`. let item = tcx.associated_items(scope).in_definition_order().find(|i| { i.kind.namespace() == Namespace::TypeNS && i.ident(tcx).normalize_to_macros_2_0() == ident })?; let kind = DefKind::AssocTy; if !item.visibility(tcx).is_accessible_from(def_scope, tcx) { let kind = kind.descr(item.def_id); let msg = format!("{kind} `{ident}` is private"); let def_span = self.tcx().def_span(item.def_id); tcx.sess .struct_span_err_with_code(span, &msg, rustc_errors::error_code!(E0624)) .span_label(span, &format!("private {kind}")) .span_label(def_span, &format!("{kind} defined here")) .emit(); } tcx.check_stability(item.def_id, Some(block), span, None); Some(item.def_id) </ins> } fn qpath_to_ty(


Question:
In the following code, I can successfully refer to the private inherent associated type : I expected to see an error denying the access. If the associated item was a constant, this would indeed be the case: : label T-compiler requires-nightly A-associated-items A-visibility F-inherentassociatedtypes <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

<ins> #![feature(inherent_associated_types)] #![allow(incomplete_features)] mod m { pub struct T; impl T { type P = (); } } type U = m::T::P; //~ ERROR associated type `P` is private mod n { pub mod n { pub struct T; impl T { pub(super) type P = bool; } } type U = n::T::P; } type V = n::n::T::P; //~ ERROR associated type `P` is private fn main() {} </ins>


Question:
In the following code, I can successfully refer to the private inherent associated type : I expected to see an error denying the access. If the associated item was a constant, this would indeed be the case: : label T-compiler requires-nightly A-associated-items A-visibility F-inherentassociatedtypes <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

<ins> error[E0624]: associated type `P` is private --> $DIR/assoc-inherent-private.rs:10:10 | LL |         type P = (); |         ------ associated type defined here ... LL | type U = m::T::P; |          ^^^^^^^ private associated type error[E0624]: associated type `P` is private --> $DIR/assoc-inherent-private.rs:21:10 | LL |             pub(super) type P = bool; |             ----------------- associated type defined here ... LL | type V = n::n::T::P; |          ^^^^^^^^^^ private associated type error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0624`. </ins>


Question:
In the following code, I can successfully refer to the private inherent associated type : I expected to see an error denying the access. If the associated item was a constant, this would indeed be the case: : label T-compiler requires-nightly A-associated-items A-visibility F-inherentassociatedtypes <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

<ins> // aux-crate:aux=assoc-inherent-unstable.rs // edition: 2021 type Data = aux::Owner::Data; //~ ERROR use of unstable library feature 'data' fn main() {} </ins>


Question:
In the following code, I can successfully refer to the private inherent associated type : I expected to see an error denying the access. If the associated item was a constant, this would indeed be the case: : label T-compiler requires-nightly A-associated-items A-visibility F-inherentassociatedtypes <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

<ins> error[E0658]: use of unstable library feature 'data' --> $DIR/assoc-inherent-unstable.rs:4:13 | LL | type Data = aux::Owner::Data; |             ^^^^^^^^^^^^^^^^ | = help: add `#![feature(data)]` to the crate attributes to enable error: aborting due to previous error For more information about this error, try `rustc --explain E0658`. </ins>


Question:
In the following code, I can successfully refer to the private inherent associated type : I expected to see an error denying the access. If the associated item was a constant, this would indeed be the case: : label T-compiler requires-nightly A-associated-items A-visibility F-inherentassociatedtypes <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

<ins> #![feature(staged_api)] #![feature(inherent_associated_types)] #![stable(feature = "main", since = "1.0.0")] #[stable(feature = "main", since = "1.0.0")] pub struct Owner; impl Owner { #[unstable(feature = "data", issue = "none")] pub type Data = (); } </ins>


Question:
In the following code, I can successfully refer to the private inherent associated type : I expected to see an error denying the access. If the associated item was a constant, this would indeed be the case: : label T-compiler requires-nightly A-associated-items A-visibility F-inherentassociatedtypes <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

LL |     let _: S::C; |            ^^^^ help: use fully-qualified syntax: `<S as Trait>::C` <del> error: associated type `A` is private </del> <ins> error[E0624]: associated type `A` is private </ins> --> $DIR/item-privacy.rs:119:12 | <ins> LL |         type A = u8; |         ------ associated type defined here ... </ins> LL |     let _: T::A; |            ^^^^ private associated type


Question:
I was chatting with today, who mentioned it'd be helpful to mention the newly stabilized APIs from the docs. The benefit of using is that even if the type widens, the result doesn't change. It'd be nice if someone could contribute docs mentioning from . This probably just needs to be a one-liner. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

/// /// assert_eq!(n.leading_zeros(), 0); /// ``` <ins> #[doc = concat!("[`ilog2`]: ", stringify!($SelfT), "::ilog2")] </ins> #[stable(feature = "rust1", since = "1.0.0")] #[rustc_const_stable(feature = "const_int_methods", since = "1.32.0")] #[must_use = "this returns the result of the operation,


Question:
I was chatting with today, who mentioned it'd be helpful to mention the newly stabilized APIs from the docs. The benefit of using is that even if the type widens, the result doesn't change. It'd be nice if someone could contribute docs mentioning from . This probably just needs to be a one-liner. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

/// Returns the number of leading zeros in the binary representation of `self`. /// <ins> /// Depending on what you're doing with the value, you might also be interested in the /// [`ilog2`] function which returns a consistent number, even if the type widens. /// </ins> /// # Examples /// /// Basic usage:


Question:
I was chatting with today, who mentioned it'd be helpful to mention the newly stabilized APIs from the docs. The benefit of using is that even if the type widens, the result doesn't change. It'd be nice if someone could contribute docs mentioning from . This probably just needs to be a one-liner. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

/// /// assert_eq!(n.leading_zeros(), 2); /// ``` <ins> #[doc = concat!("[`ilog2`]: ", stringify!($SelfT), "::ilog2")] </ins> #[stable(feature = "rust1", since = "1.0.0")] #[rustc_const_stable(feature = "const_math", since = "1.32.0")] #[must_use = "this returns the result of the operation,


Question:
I tried this code: I expected to see this happen: Successful compilation (because this would succeed for the target ) Instead, this happened: <!-- 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The relevant code is It should probably be applied to riscv32 too
Doesn't seem like anyone else has picked this up yet, if it's as simple a fix as it seems I would be happy to make the PR.
claim
The mismatch still occurs if extra features are specified by (e.g., ).
Sorry about the delayed response. I just tested it, but I'm not seeing the error. Could you test again as well? I was running the following command: Here is the version I'm on:
Hm, I actually encountered the issue in a more complicated setup () with bare-metal targets and assumed from the symptom that it was caused by a similar underlying problem. I'll look into it again and open a separate issue after getting a better idea.

}; e_flags } <del> Architecture::Riscv64 if sess.target.options.features.contains("+d") => { // copied from `riscv64-linux-gnu-gcc foo.c -c`, note though // that the `+d` target feature represents whether the double // float abi is enabled. let e_flags = elf::EF_RISCV_RVC | elf::EF_RISCV_FLOAT_ABI_DOUBLE; </del> <ins> Architecture::Riscv32 | Architecture::Riscv64 => { // Source: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/079772828bd10933d34121117a222b4cc0ee2200/riscv-elf.adoc let mut e_flags: u32 = 0x0; let features = &sess.target.options.features; // Check if compressed is enabled if features.contains("+c") { e_flags |= elf::EF_RISCV_RVC; } // Select the appropriate floating-point ABI if features.contains("+d") { e_flags |= elf::EF_RISCV_FLOAT_ABI_DOUBLE; } else if features.contains("+f") { e_flags |= elf::EF_RISCV_FLOAT_ABI_SINGLE; } else { e_flags |= elf::EF_RISCV_FLOAT_ABI_SOFT; } </ins> e_flags } _ => 0,


Question:
I tried this code (reduced from a much larger test): () I expected to see this happen: runs with 0 exit code and no output Instead, this happened: This code works on stable and beta, and as recently as . This reproduces with the 2022-11-16 nightly on the playground. this was introduced by . modify labels: +regression-from-stable-to-nightly -regression-untriaged <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
That looks like a real miscompilation :( cc
WG-prioritization assigning priority (). label -I-prioritize +P-high
I've found the problem; it is indeed an issue with my code in . I'll have a PR with a fix some time today.
Since there is some work in progress to fix this: assign

// In the algorithm above, we can change // cast(relative_tag) + niche_variants.start() // into <del> // cast(tag) + (niche_variants.start() - niche_start) </del> <ins> // cast(tag + (niche_variants.start() - niche_start)) </ins> // if either the casted type is no larger than the original // type, or if the niche values are contiguous (in either the // signed or unsigned sense). <del> let can_incr_after_cast = cast_smaller || niches_ule || niches_sle; </del> <ins> let can_incr = cast_smaller || niches_ule || niches_sle; </ins> let data_for_boundary_niche = || -> Option<(IntPredicate, u128)> { <del> if !can_incr_after_cast { </del> <ins> if !can_incr { </ins> None } else if niche_start == low_unsigned { Some((IntPredicate::IntULE, niche_end))


Question:
I tried this code (reduced from a much larger test): () I expected to see this happen: runs with 0 exit code and no output Instead, this happened: This code works on stable and beta, and as recently as . This reproduces with the 2022-11-16 nightly on the playground. this was introduced by . modify labels: +regression-from-stable-to-nightly -regression-untriaged <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
That looks like a real miscompilation :( cc
WG-prioritization assigning priority (). label -I-prioritize +P-high
I've found the problem; it is indeed an issue with my code in . I'll have a PR with a fix some time today.
Since there is some work in progress to fix this: assign

// The algorithm is now this: // is_niche = tag <= niche_end // discr = if is_niche { <del> //     cast(tag) + (niche_variants.start() - niche_start) </del> <ins> //     cast(tag + (niche_variants.start() - niche_start)) </ins> // } else { //     untagged_variant // } // (the first line may instead be tag >= niche_start, // and may be a signed or unsigned comparison) <ins> // The arithmetic must be done before the cast, so we can // have the correct wrapping behavior. See issue #104519 for // the consequences of getting this wrong. </ins> let is_niche = bx.icmp(predicate, tag, bx.cx().const_uint_big(tag_llty, constant)); <ins> let delta = (niche_variants.start().as_u32() as u128).wrapping_sub(niche_start); let incr_tag = if delta == 0 { tag } else { bx.add(tag, bx.cx().const_uint_big(tag_llty, delta)) }; </ins> let cast_tag = if cast_smaller { <del> bx.intcast(tag, cast_to, false) </del> <ins> bx.intcast(incr_tag, cast_to, false) </ins> } else if niches_ule { <del> bx.zext(tag, cast_to) </del> <ins> bx.zext(incr_tag, cast_to) </ins> } else { <del> bx.sext(tag, cast_to) </del> <ins> bx.sext(incr_tag, cast_to) </ins> }; <del> let delta = (niche_variants.start().as_u32() as u128).wrapping_sub(niche_start); (is_niche, cast_tag, delta) </del> <ins> (is_niche, cast_tag, 0) </ins> } else { // The special cases don't apply, so we'll have to go with // the general algorithm.


Question:
I tried this code (reduced from a much larger test): () I expected to see this happen: runs with 0 exit code and no output Instead, this happened: This code works on stable and beta, and as recently as . This reproduces with the 2022-11-16 nightly on the playground. this was introduced by . modify labels: +regression-from-stable-to-nightly -regression-untriaged <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
That looks like a real miscompilation :( cc
WG-prioritization assigning priority (). label -I-prioritize +P-high
I've found the problem; it is indeed an issue with my code in . I'll have a PR with a fix some time today.
Since there is some work in progress to fix this: assign

// CHECK: define i8 @match1{{.*}} // CHECK-NEXT: start: <del> // CHECK-NEXT: %1 = icmp ugt i8 %0, 1 // CHECK-NEXT: %2 = zext i8 %0 to i64 // CHECK-NEXT: %3 = add nsw i64 %2, -1 // CHECK-NEXT: %_2 = select i1 %1, i64 %3, i64 0 // CHECK-NEXT: switch i64 %_2, label {{.*}} [ </del> <ins> // CHECK-NEXT: %1 = {{.*}}call i8 @llvm.usub.sat.i8(i8 %0, i8 1) // CHECK-NEXT: switch i8 %1, label {{.*}} [ </ins> #[no_mangle] pub fn match1(e: Enum1) -> u8 { use Enum1::*;


Question:
I tried this code (reduced from a much larger test): () I expected to see this happen: runs with 0 exit code and no output Instead, this happened: This code works on stable and beta, and as recently as . This reproduces with the 2022-11-16 nightly on the playground. this was introduced by . modify labels: +regression-from-stable-to-nightly -regression-untriaged <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
That looks like a real miscompilation :( cc
WG-prioritization assigning priority (). label -I-prioritize +P-high
I've found the problem; it is indeed an issue with my code in . I'll have a PR with a fix some time today.
Since there is some work in progress to fix this: assign

<ins> // run-pass #![allow(dead_code)] enum OpenResult { Ok(()), Err(()), TransportErr(TransportErr), } #[repr(i32)] enum TransportErr { UnknownMethod = -2, } #[inline(never)] fn some_match(result: OpenResult) -> u8 { match result { OpenResult::Ok(()) => 0, _ => 1, } } fn main() { let result = OpenResult::Ok(()); assert_eq!(some_match(result), 0); let result = OpenResult::Ok(()); match result { OpenResult::Ok(()) => (), _ => unreachable!("message a"), } match result { OpenResult::Ok(()) => (), _ => unreachable!("message b"), } } </ins>


Question:
Miri reports UB in the new test: On first sight, the error seems legitimate. That test got in Cc
Probably what happens is that in Miri, will always move the data to a new location, and then the way the test checks whether that happened causes UB. You should not call unless you are already 100% sure that both pointer point to the same allocation -- and in this case, you cannot be sure of that, since allocators do not promise that keeps the same allocation. In fact, it might be the case that even if keeps the data in-place, the allocation has a new provenance -- it is considered a new allocation at the same location, but all old pointers are invalid now and must be 'refreshed'. So this code probably has UB even if keeps the allocation in-place. I recall this was discussed somewhere at some point, and I think the C standard contains wording along these lines, but I forgot the details... Cc The fix is easy -- just do and later compare that with . The test will still fail in Miri though, and in other allocators that do not shrink in-place.
Yeah, the C standard is quite explicit about this, so for now we should follow suit. Opened
Might it be a good idea to the pointer comparison itself, so that Miri can check the actual implementation, even if it can't check the final assertion. I did suspect that other platforms might not have this behaviour - seems to show this. It might be best to feature gate the test and opt to only platforms with allocators that work like this.
Yes, but to be clear there are two bugs here: the test can fail in some platforms, such as Miri, when realloc doesn't shrink in-place the test has UB on all platforms because the two pointers are into different allocations (realloc conceptually creates a new allocation, even if it remains in-place), but is explicitly documented to only work on pointers within the same allocation
Is the comparison still UB? I'm currently working on a patch that Uses the cast for comparison Turns off this feature for non-GNU targets (since that's the only one I know for sure has the shrink-in-place behaviour) Disables the test on non GNU, and the comparison itself on Miri With that in mnd though, I'm wondering if this opt should just be removed entirely. The perf wins I got in testing were pretty small for the amount of maintenance headache this seems likely to cause
returns regular integers, you can compare them in whatever way you want.

} } <del> /// Create an `Rc<[T]>` by reusing the underlying memory /// of a `Vec<T>`. This will return the vector if the existing allocation /// is not large enough. #[cfg(not(no_global_oom_handling))] fn try_from_vec_in_place(mut v: Vec<T>) -> Result<Rc<[T]>, Vec<T>> { let layout_elements = Layout::array::<T>(v.len()).unwrap(); let layout_allocation = Layout::array::<T>(v.capacity()).unwrap(); let layout_rcbox = rcbox_layout_for_value_layout(layout_elements); let mut ptr = NonNull::new(v.as_mut_ptr()).expect("`Vec<T>` stores `NonNull<T>`"); if layout_rcbox.size() > layout_allocation.size() || layout_rcbox.align() > layout_allocation.align() { // Can't fit - calling `grow` would involve `realloc` // (which copies the elements), followed by copying again. return Err(v); } if layout_rcbox.size() < layout_allocation.size() || layout_rcbox.align() < layout_allocation.align() { // We need to shrink the allocation so that it fits // https://doc.rust-lang.org/nightly/std/alloc/trait.Allocator.html#memory-fitting // SAFETY: // - Vec allocates by requesting `Layout::array::<T>(capacity)`, so this capacity matches // - `layout_rcbox` is smaller // If this fails, the ownership has not been transferred if let Ok(p) = unsafe { Global.shrink(ptr.cast(), layout_allocation, layout_rcbox) } { ptr = p.cast(); } else { return Err(v); } } // Make sure the vec's memory isn't deallocated now let v = mem::ManuallyDrop::new(v); let ptr: *mut RcBox<[T]> = ptr::slice_from_raw_parts_mut(ptr.as_ptr(), v.len()) as _; unsafe { ptr::copy(ptr.cast::<T>(), &mut (*ptr).value as *mut [T] as *mut T, v.len()); ptr::write(&mut (*ptr).strong, Cell::new(1)); ptr::write(&mut (*ptr).weak, Cell::new(1)); Ok(Self::from_ptr(ptr)) } } </del> /// Constructs an `Rc<[T]>` from an iterator known to be of a certain size. /// /// Behavior is undefined should the size be wrong.


Question:
Miri reports UB in the new test: On first sight, the error seems legitimate. That test got in Cc
Probably what happens is that in Miri, will always move the data to a new location, and then the way the test checks whether that happened causes UB. You should not call unless you are already 100% sure that both pointer point to the same allocation -- and in this case, you cannot be sure of that, since allocators do not promise that keeps the same allocation. In fact, it might be the case that even if keeps the data in-place, the allocation has a new provenance -- it is considered a new allocation at the same location, but all old pointers are invalid now and must be 'refreshed'. So this code probably has UB even if keeps the allocation in-place. I recall this was discussed somewhere at some point, and I think the C standard contains wording along these lines, but I forgot the details... Cc The fix is easy -- just do and later compare that with . The test will still fail in Miri though, and in other allocators that do not shrink in-place.
Yeah, the C standard is quite explicit about this, so for now we should follow suit. Opened
Might it be a good idea to the pointer comparison itself, so that Miri can check the actual implementation, even if it can't check the final assertion. I did suspect that other platforms might not have this behaviour - seems to show this. It might be best to feature gate the test and opt to only platforms with allocators that work like this.
Yes, but to be clear there are two bugs here: the test can fail in some platforms, such as Miri, when realloc doesn't shrink in-place the test has UB on all platforms because the two pointers are into different allocations (realloc conceptually creates a new allocation, even if it remains in-place), but is explicitly documented to only work on pointers within the same allocation
Is the comparison still UB? I'm currently working on a patch that Uses the cast for comparison Turns off this feature for non-GNU targets (since that's the only one I know for sure has the shrink-in-place behaviour) Disables the test on non GNU, and the comparison itself on Miri With that in mnd though, I'm wondering if this opt should just be removed entirely. The perf wins I got in testing were pretty small for the amount of maintenance headache this seems likely to cause
returns regular integers, you can compare them in whatever way you want.

/// assert_eq!(vec![1, 2, 3], *shared); /// ``` #[inline] <del> fn from(v: Vec<T>) -> Rc<[T]> { match Rc::try_from_vec_in_place(v) { Ok(rc) => rc, Err(mut v) => { unsafe { let rc = Rc::copy_from_slice(&v); // Allow the Vec to free its memory, but not destroy its contents v.set_len(0); rc } } </del> <ins> fn from(mut v: Vec<T>) -> Rc<[T]> { unsafe { let rc = Rc::copy_from_slice(&v); // Allow the Vec to free its memory, but not destroy its contents v.set_len(0); rc </ins> } } }


Question:
Miri reports UB in the new test: On first sight, the error seems legitimate. That test got in Cc
Probably what happens is that in Miri, will always move the data to a new location, and then the way the test checks whether that happened causes UB. You should not call unless you are already 100% sure that both pointer point to the same allocation -- and in this case, you cannot be sure of that, since allocators do not promise that keeps the same allocation. In fact, it might be the case that even if keeps the data in-place, the allocation has a new provenance -- it is considered a new allocation at the same location, but all old pointers are invalid now and must be 'refreshed'. So this code probably has UB even if keeps the allocation in-place. I recall this was discussed somewhere at some point, and I think the C standard contains wording along these lines, but I forgot the details... Cc The fix is easy -- just do and later compare that with . The test will still fail in Miri though, and in other allocators that do not shrink in-place.
Yeah, the C standard is quite explicit about this, so for now we should follow suit. Opened
Might it be a good idea to the pointer comparison itself, so that Miri can check the actual implementation, even if it can't check the final assertion. I did suspect that other platforms might not have this behaviour - seems to show this. It might be best to feature gate the test and opt to only platforms with allocators that work like this.
Yes, but to be clear there are two bugs here: the test can fail in some platforms, such as Miri, when realloc doesn't shrink in-place the test has UB on all platforms because the two pointers are into different allocations (realloc conceptually creates a new allocation, even if it remains in-place), but is explicitly documented to only work on pointers within the same allocation
Is the comparison still UB? I'm currently working on a patch that Uses the cast for comparison Turns off this feature for non-GNU targets (since that's the only one I know for sure has the shrink-in-place behaviour) Disables the test on non GNU, and the comparison itself on Miri With that in mnd though, I'm wondering if this opt should just be removed entirely. The perf wins I got in testing were pretty small for the amount of maintenance headache this seems likely to cause
returns regular integers, you can compare them in whatever way you want.

} } <del> /// Create an `Arc<[T]>` by reusing the underlying memory /// of a `Vec<T>`. This will return the vector if the existing allocation /// is not large enough. #[cfg(not(no_global_oom_handling))] fn try_from_vec_in_place(mut v: Vec<T>) -> Result<Arc<[T]>, Vec<T>> { let layout_elements = Layout::array::<T>(v.len()).unwrap(); let layout_allocation = Layout::array::<T>(v.capacity()).unwrap(); let layout_arcinner = arcinner_layout_for_value_layout(layout_elements); let mut ptr = NonNull::new(v.as_mut_ptr()).expect("`Vec<T>` stores `NonNull<T>`"); if layout_arcinner.size() > layout_allocation.size() || layout_arcinner.align() > layout_allocation.align() { // Can't fit - calling `grow` would involve `realloc` // (which copies the elements), followed by copying again. return Err(v); } if layout_arcinner.size() < layout_allocation.size() || layout_arcinner.align() < layout_allocation.align() { // We need to shrink the allocation so that it fits // https://doc.rust-lang.org/nightly/std/alloc/trait.Allocator.html#memory-fitting // SAFETY: // - Vec allocates by requesting `Layout::array::<T>(capacity)`, so this capacity matches // - `layout_arcinner` is smaller // If this fails, the ownership has not been transferred if let Ok(p) = unsafe { Global.shrink(ptr.cast(), layout_allocation, layout_arcinner) } { ptr = p.cast(); } else { return Err(v); } } // Make sure the vec's memory isn't deallocated now let v = mem::ManuallyDrop::new(v); let ptr: *mut ArcInner<[T]> = ptr::slice_from_raw_parts_mut(ptr.as_ptr(), v.len()) as _; unsafe { ptr::copy(ptr.cast::<T>(), &mut (*ptr).data as *mut [T] as *mut T, v.len()); ptr::write(&mut (*ptr).strong, atomic::AtomicUsize::new(1)); ptr::write(&mut (*ptr).weak, atomic::AtomicUsize::new(1)); Ok(Self::from_ptr(ptr)) } } </del> /// Constructs an `Arc<[T]>` from an iterator known to be of a certain size. /// /// Behavior is undefined should the size be wrong.


Question:
Miri reports UB in the new test: On first sight, the error seems legitimate. That test got in Cc
Probably what happens is that in Miri, will always move the data to a new location, and then the way the test checks whether that happened causes UB. You should not call unless you are already 100% sure that both pointer point to the same allocation -- and in this case, you cannot be sure of that, since allocators do not promise that keeps the same allocation. In fact, it might be the case that even if keeps the data in-place, the allocation has a new provenance -- it is considered a new allocation at the same location, but all old pointers are invalid now and must be 'refreshed'. So this code probably has UB even if keeps the allocation in-place. I recall this was discussed somewhere at some point, and I think the C standard contains wording along these lines, but I forgot the details... Cc The fix is easy -- just do and later compare that with . The test will still fail in Miri though, and in other allocators that do not shrink in-place.
Yeah, the C standard is quite explicit about this, so for now we should follow suit. Opened
Might it be a good idea to the pointer comparison itself, so that Miri can check the actual implementation, even if it can't check the final assertion. I did suspect that other platforms might not have this behaviour - seems to show this. It might be best to feature gate the test and opt to only platforms with allocators that work like this.
Yes, but to be clear there are two bugs here: the test can fail in some platforms, such as Miri, when realloc doesn't shrink in-place the test has UB on all platforms because the two pointers are into different allocations (realloc conceptually creates a new allocation, even if it remains in-place), but is explicitly documented to only work on pointers within the same allocation
Is the comparison still UB? I'm currently working on a patch that Uses the cast for comparison Turns off this feature for non-GNU targets (since that's the only one I know for sure has the shrink-in-place behaviour) Disables the test on non GNU, and the comparison itself on Miri With that in mnd though, I'm wondering if this opt should just be removed entirely. The perf wins I got in testing were pretty small for the amount of maintenance headache this seems likely to cause
returns regular integers, you can compare them in whatever way you want.

/// assert_eq!(&[1, 2, 3], &shared[..]); /// ``` #[inline] <del> fn from(v: Vec<T>) -> Arc<[T]> { match Arc::try_from_vec_in_place(v) { Ok(rc) => rc, Err(mut v) => { unsafe { let rc = Arc::copy_from_slice(&v); // Allow the Vec to free its memory, but not destroy its contents v.set_len(0); rc } } </del> <ins> fn from(mut v: Vec<T>) -> Arc<[T]> { unsafe { let rc = Arc::copy_from_slice(&v); // Allow the Vec to free its memory, but not destroy its contents v.set_len(0); rc </ins> } } }


Question:
Miri reports UB in the new test: On first sight, the error seems legitimate. That test got in Cc
Probably what happens is that in Miri, will always move the data to a new location, and then the way the test checks whether that happened causes UB. You should not call unless you are already 100% sure that both pointer point to the same allocation -- and in this case, you cannot be sure of that, since allocators do not promise that keeps the same allocation. In fact, it might be the case that even if keeps the data in-place, the allocation has a new provenance -- it is considered a new allocation at the same location, but all old pointers are invalid now and must be 'refreshed'. So this code probably has UB even if keeps the allocation in-place. I recall this was discussed somewhere at some point, and I think the C standard contains wording along these lines, but I forgot the details... Cc The fix is easy -- just do and later compare that with . The test will still fail in Miri though, and in other allocators that do not shrink in-place.
Yeah, the C standard is quite explicit about this, so for now we should follow suit. Opened
Might it be a good idea to the pointer comparison itself, so that Miri can check the actual implementation, even if it can't check the final assertion. I did suspect that other platforms might not have this behaviour - seems to show this. It might be best to feature gate the test and opt to only platforms with allocators that work like this.
Yes, but to be clear there are two bugs here: the test can fail in some platforms, such as Miri, when realloc doesn't shrink in-place the test has UB on all platforms because the two pointers are into different allocations (realloc conceptually creates a new allocation, even if it remains in-place), but is explicitly documented to only work on pointers within the same allocation
Is the comparison still UB? I'm currently working on a patch that Uses the cast for comparison Turns off this feature for non-GNU targets (since that's the only one I know for sure has the shrink-in-place behaviour) Disables the test on non GNU, and the comparison itself on Miri With that in mnd though, I'm wondering if this opt should just be removed entirely. The perf wins I got in testing were pretty small for the amount of maintenance headache this seems likely to cause
returns regular integers, you can compare them in whatever way you want.

// `val` dropped here while still borrowed // borrow might be used here, when `val` is dropped and runs the `Drop` code for type `std::sync::Weak` } <del> #[test] fn arc_from_vec_opt() { let mut v = Vec::with_capacity(64); v.push(0usize); let addr = v.as_ptr().cast::<u8>(); let arc: Arc<[_]> = v.into(); unsafe { assert_eq!( arc.as_ptr().cast::<u8>().offset_from(addr), (std::mem::size_of::<usize>() * 2) as isize, "Vector allocation not reused" ); } } </del>


Question:
Miri reports UB in the new test: On first sight, the error seems legitimate. That test got in Cc
Probably what happens is that in Miri, will always move the data to a new location, and then the way the test checks whether that happened causes UB. You should not call unless you are already 100% sure that both pointer point to the same allocation -- and in this case, you cannot be sure of that, since allocators do not promise that keeps the same allocation. In fact, it might be the case that even if keeps the data in-place, the allocation has a new provenance -- it is considered a new allocation at the same location, but all old pointers are invalid now and must be 'refreshed'. So this code probably has UB even if keeps the allocation in-place. I recall this was discussed somewhere at some point, and I think the C standard contains wording along these lines, but I forgot the details... Cc The fix is easy -- just do and later compare that with . The test will still fail in Miri though, and in other allocators that do not shrink in-place.
Yeah, the C standard is quite explicit about this, so for now we should follow suit. Opened
Might it be a good idea to the pointer comparison itself, so that Miri can check the actual implementation, even if it can't check the final assertion. I did suspect that other platforms might not have this behaviour - seems to show this. It might be best to feature gate the test and opt to only platforms with allocators that work like this.
Yes, but to be clear there are two bugs here: the test can fail in some platforms, such as Miri, when realloc doesn't shrink in-place the test has UB on all platforms because the two pointers are into different allocations (realloc conceptually creates a new allocation, even if it remains in-place), but is explicitly documented to only work on pointers within the same allocation
Is the comparison still UB? I'm currently working on a patch that Uses the cast for comparison Turns off this feature for non-GNU targets (since that's the only one I know for sure has the shrink-in-place behaviour) Disables the test on non GNU, and the comparison itself on Miri With that in mnd though, I'm wondering if this opt should just be removed entirely. The perf wins I got in testing were pretty small for the amount of maintenance headache this seems likely to cause
returns regular integers, you can compare them in whatever way you want.

// `val` dropped here while still borrowed // borrow might be used here, when `val` is dropped and runs the `Drop` code for type `std::rc::Weak` } <del> #[test] fn rc_from_vec_opt() { let mut v = Vec::with_capacity(64); v.push(0usize); let addr = v.as_ptr().cast::<u8>(); let rc: Rc<[_]> = v.into(); unsafe { assert_eq!( rc.as_ptr().cast::<u8>().offset_from(addr), (std::mem::size_of::<usize>() * 2) as isize, "Vector allocation not reused" ); } } </del>


Question: Found with a From : From : Deep recursion involving ? Regression in nightly-2022-10-07, apparently in rollup . I suspect (

} ty::FnPtr(sig) => (sig, None), _ => { <ins> for arg in arg_exprs { self.check_expr(arg); } </ins> if let hir::ExprKind::Path(hir::QPath::Resolved(_, path)) = &callee_expr.kind && let [segment] = path.segments && let Some(mut diag) = self


Question: Found with a From : From : Deep recursion involving ? Regression in nightly-2022-10-07, apparently in rollup . I suspect (

expected: Expectation<'tcx>, ) -> Option<Ty<'tcx>> { if let [callee_expr, rest @ ..] = arg_exprs { <del> let callee_ty = self.check_expr(callee_expr); </del> <ins> let callee_ty = self.typeck_results.borrow().expr_ty_adjusted_opt(callee_expr)?; </ins> // First, do a probe with `IsSuggestion(true)` to avoid emitting // any strange errors. If it's successful, then we'll do a true // method lookup.


Question: Found with a From : From : Deep recursion involving ? Regression in nightly-2022-10-07, apparently in rollup . I suspect (

<ins> fn main() -> Result<(), ()> { a(b(c(d(e( //~^ ERROR cannot find function `a` in this scope //~| ERROR cannot find function `b` in this scope //~| ERROR cannot find function `c` in this scope //~| ERROR cannot find function `d` in this scope //~| ERROR cannot find function `e` in this scope z???????????????????????????????????????????????????????????????????????????????????????? ????????????????????????????????????????????????????????????????????????????????????????? ?????????????????????????????????????????????????????????????????? //~^^^ ERROR cannot find value `z` in this scope ))))) } </ins>


Question: Found with a From : From : Deep recursion involving ? Regression in nightly-2022-10-07, apparently in rollup . I suspect (

<ins> error[E0425]: cannot find value `z` in this scope --> $DIR/fn-to-method-deeply-nested.rs:8:9 | LL |         z???????????????????????????????????????????????????????????????????????????????????????? |         ^ not found in this scope error[E0425]: cannot find function `e` in this scope --> $DIR/fn-to-method-deeply-nested.rs:2:13 | LL |     a(b(c(d(e( |             ^ not found in this scope error[E0425]: cannot find function `d` in this scope --> $DIR/fn-to-method-deeply-nested.rs:2:11 | LL |     a(b(c(d(e( |           ^ not found in this scope error[E0425]: cannot find function `c` in this scope --> $DIR/fn-to-method-deeply-nested.rs:2:9 | LL |     a(b(c(d(e( |         ^ not found in this scope error[E0425]: cannot find function `b` in this scope --> $DIR/fn-to-method-deeply-nested.rs:2:7 | LL |     a(b(c(d(e( |       ^ not found in this scope error[E0425]: cannot find function `a` in this scope --> $DIR/fn-to-method-deeply-nested.rs:2:5 | LL |     a(b(c(d(e( |     ^ not found in this scope error: aborting due to 6 previous errors For more information about this error, try `rustc --explain E0425`. </ins>


Question: Found with a From : From : Deep recursion involving ? Regression in nightly-2022-10-07, apparently in rollup . I suspect (

<ins> fn main() { a((), 1i32 == 2u32); //~^ ERROR cannot find function `a` in this scope //~| ERROR mismatched types } </ins>


Question: Found with a From : From : Deep recursion involving ? Regression in nightly-2022-10-07, apparently in rollup . I suspect (

<ins> error[E0308]: mismatched types --> $DIR/check-args-on-fn-err-2.rs:2:19 | LL |     a((), 1i32 == 2u32); |           ----    ^^^^ expected `i32`, found `u32` |           | |           expected because this is `i32` | help: change the type of the numeric literal from `u32` to `i32` | LL |     a((), 1i32 == 2i32); |                    ~~~ error[E0425]: cannot find function `a` in this scope --> $DIR/check-args-on-fn-err-2.rs:2:5 | LL |     a((), 1i32 == 2u32); |     ^ not found in this scope error: aborting due to 2 previous errors Some errors have detailed explanations: E0308, E0425. For more information about an error, try `rustc --explain E0308`. </ins>


Question: Found with a From : From : Deep recursion involving ? Regression in nightly-2022-10-07, apparently in rollup . I suspect (

<ins> fn main() { unknown(1, |glyf| { //~^ ERROR: cannot find function `unknown` in this scope let actual = glyf; }); } </ins>


Question: Found with a From : From : Deep recursion involving ? Regression in nightly-2022-10-07, apparently in rollup . I suspect (

<ins> error[E0425]: cannot find function `unknown` in this scope --> $DIR/check-args-on-fn-err.rs:2:5 | LL |     unknown(1, |glyf| { |     ^^^^^^^ not found in this scope error: aborting due to previous error For more information about this error, try `rustc --explain E0425`. </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: text //! #..#.####.#....#.....##.. //! #..#.#....#....#....#..#. //! ####.###..#....#....#..#. //! #..#.#....#....#....#..#. //! #..#.#....#....#....#..#. //! #..#.####.####.####..##.. //! I expected to see this happen: When I run , I expect to see ASCII art in the output that matches the above example. Instead, this happened: In the output, this actually appears: It appears that if a line starts with at least three s, one gets "swallowed" somehow. <!-- 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. . --<details<summaryBacktrace</summary<p</p</details
It's because of how are handled for rust code blocks. I'll send a PR but we need to ensure that people are not relying on to hide a line for non-rust code blocks.
This is actually a regression. I haven't bisected, but it occurred sometime between 1.50.0 and 1.63.0 based on a quick test. In 1.50.0, the following code block markdown /// # Header /// rendered as , but in 1.63.0 it renders as a blank code block.
Thanks for the information !
The regression is in nightly-2021-07-15 Commits in range: commit[0] 2021-07-13UTC: Auto merge of - camsteffen:hash-lint-resolved, r=oli-obk commit[1] 2021-07-13UTC: Auto merge of - cjgillot:expnhash, r=petrochenkov commit[2] 2021-07-14UTC: Auto merge of - Mark-Simulacrum:edition-no-clone, r=petrochenkov commit[3] 2021-07-14UTC: Auto merge of - tlyu:option-result-overviews, r=joshtriplett commit[4] 2021-07-14UTC: Auto merge of - JohnTitor:rollup-8ltidsq, r=JohnTitor commit[5] 2021-07-14UTC: Auto merge of - michaelwoerister:const-in-debuginfo-type-names-fix, r=oli-obk,wesleywiser commit[6] 2021-07-14UTC: Auto merge of - GuillaumeGomez:rollup-pfz9jbk, r=GuillaumeGomez commit[7] 2021-07-14UTC: Auto merge of - cuviper:fuse-less-specialized, r=joshtriplett Maybe this happened in (merged by ) (cc

_ => {} } } <del> let lines = origtext.lines().filter_map(|l| map_line(l).for_html()); let text = lines.intersperse("n".into()).collect::<String>(); </del> let parse_result = match kind { CodeBlockKind::Fenced(ref lang) => {


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: text //! #..#.####.#....#.....##.. //! #..#.#....#....#....#..#. //! ####.###..#....#....#..#. //! #..#.#....#....#....#..#. //! #..#.#....#....#....#..#. //! #..#.####.####.####..##.. //! I expected to see this happen: When I run , I expect to see ASCII art in the output that matches the above example. Instead, this happened: In the output, this actually appears: It appears that if a line starts with at least three s, one gets "swallowed" somehow. <!-- 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. . --<details<summaryBacktrace</summary<p</p</details
It's because of how are handled for rust code blocks. I'll send a PR but we need to ensure that people are not relying on to hide a line for non-rust code blocks.
This is actually a regression. I haven't bisected, but it occurred sometime between 1.50.0 and 1.63.0 based on a quick test. In 1.50.0, the following code block markdown /// # Header /// rendered as , but in 1.63.0 it renders as a blank code block.
Thanks for the information !
The regression is in nightly-2021-07-15 Commits in range: commit[0] 2021-07-13UTC: Auto merge of - camsteffen:hash-lint-resolved, r=oli-obk commit[1] 2021-07-13UTC: Auto merge of - cjgillot:expnhash, r=petrochenkov commit[2] 2021-07-14UTC: Auto merge of - Mark-Simulacrum:edition-no-clone, r=petrochenkov commit[3] 2021-07-14UTC: Auto merge of - tlyu:option-result-overviews, r=joshtriplett commit[4] 2021-07-14UTC: Auto merge of - JohnTitor:rollup-8ltidsq, r=JohnTitor commit[5] 2021-07-14UTC: Auto merge of - michaelwoerister:const-in-debuginfo-type-names-fix, r=oli-obk,wesleywiser commit[6] 2021-07-14UTC: Auto merge of - GuillaumeGomez:rollup-pfz9jbk, r=GuillaumeGomez commit[7] 2021-07-14UTC: Auto merge of - cuviper:fuse-less-specialized, r=joshtriplett Maybe this happened in (merged by ) (cc

{}

", lang,  Escape(&text),   Escape(&origtext),  ) .into(), ));


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: text //! #..#.####.#....#.....##.. //! #..#.#....#....#....#..#. //! ####.###..#....#....#..#. //! #..#.#....#....#....#..#. //! #..#.#....#....#....#..#. //! #..#.####.####.####..##.. //! I expected to see this happen: When I run , I expect to see ASCII art in the output that matches the above example. Instead, this happened: In the output, this actually appears: It appears that if a line starts with at least three s, one gets "swallowed" somehow. <!-- 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. . --<details<summaryBacktrace</summary<p</p</details
It's because of how are handled for rust code blocks. I'll send a PR but we need to ensure that people are not relying on to hide a line for non-rust code blocks.
This is actually a regression. I haven't bisected, but it occurred sometime between 1.50.0 and 1.63.0 based on a quick test. In 1.50.0, the following code block markdown /// # Header /// rendered as , but in 1.63.0 it renders as a blank code block.
Thanks for the information !
The regression is in nightly-2021-07-15 Commits in range: commit[0] 2021-07-13UTC: Auto merge of - camsteffen:hash-lint-resolved, r=oli-obk commit[1] 2021-07-13UTC: Auto merge of - cjgillot:expnhash, r=petrochenkov commit[2] 2021-07-14UTC: Auto merge of - Mark-Simulacrum:edition-no-clone, r=petrochenkov commit[3] 2021-07-14UTC: Auto merge of - tlyu:option-result-overviews, r=joshtriplett commit[4] 2021-07-14UTC: Auto merge of - JohnTitor:rollup-8ltidsq, r=JohnTitor commit[5] 2021-07-14UTC: Auto merge of - michaelwoerister:const-in-debuginfo-type-names-fix, r=oli-obk,wesleywiser commit[6] 2021-07-14UTC: Auto merge of - GuillaumeGomez:rollup-pfz9jbk, r=GuillaumeGomez commit[7] 2021-07-14UTC: Auto merge of - cuviper:fuse-less-specialized, r=joshtriplett Maybe this happened in (merged by ) (cc

CodeBlockKind::Indented => Default::default(), }; <ins> let lines = origtext.lines().filter_map(|l| map_line(l).for_html()); let text = lines.intersperse("n".into()).collect::<String>(); </ins> compile_fail = parse_result.compile_fail; should_panic = parse_result.should_panic; ignore = parse_result.ignore;


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: text //! #..#.####.#....#.....##.. //! #..#.#....#....#....#..#. //! ####.###..#....#....#..#. //! #..#.#....#....#....#..#. //! #..#.#....#....#....#..#. //! #..#.####.####.####..##.. //! I expected to see this happen: When I run , I expect to see ASCII art in the output that matches the above example. Instead, this happened: In the output, this actually appears: It appears that if a line starts with at least three s, one gets "swallowed" somehow. <!-- 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. . --<details<summaryBacktrace</summary<p</p</details
It's because of how are handled for rust code blocks. I'll send a PR but we need to ensure that people are not relying on to hide a line for non-rust code blocks.
This is actually a regression. I haven't bisected, but it occurred sometime between 1.50.0 and 1.63.0 based on a quick test. In 1.50.0, the following code block markdown /// # Header /// rendered as , but in 1.63.0 it renders as a blank code block.
Thanks for the information !
The regression is in nightly-2021-07-15 Commits in range: commit[0] 2021-07-13UTC: Auto merge of - camsteffen:hash-lint-resolved, r=oli-obk commit[1] 2021-07-13UTC: Auto merge of - cjgillot:expnhash, r=petrochenkov commit[2] 2021-07-14UTC: Auto merge of - Mark-Simulacrum:edition-no-clone, r=petrochenkov commit[3] 2021-07-14UTC: Auto merge of - tlyu:option-result-overviews, r=joshtriplett commit[4] 2021-07-14UTC: Auto merge of - JohnTitor:rollup-8ltidsq, r=JohnTitor commit[5] 2021-07-14UTC: Auto merge of - michaelwoerister:const-in-debuginfo-type-names-fix, r=oli-obk,wesleywiser commit[6] 2021-07-14UTC: Auto merge of - GuillaumeGomez:rollup-pfz9jbk, r=GuillaumeGomez commit[7] 2021-07-14UTC: Auto merge of - cuviper:fuse-less-specialized, r=joshtriplett Maybe this happened in (merged by ) (cc

t("```rustn```n```rustn```", &[1, 3]); t("```rustn```n ```rustn```", &[1, 3]); }  #[test] fn test_ascii_with_prepending_hashtag() { fn t(input: &str, expect: &str) { let mut map = IdMap::new(); let output = Markdown { content: input, links: &[], ids: &mut map, error_codes: ErrorCodes::Yes, edition: DEFAULT_EDITION, playground: &None, heading_offset: HeadingOffset::H2, } .into_string(); assert_eq!(output, expect, "original: {}", input); } t( r#"```ascii #..#.####.#....#.....##.. #..#.#....#....#....#..#. ####.###..#....#....#..#. #..#.#....#....#....#..#. #..#.#....#....#....#..#. #..#.####.####.####..##.. ```"#, "

 #..#.####.#....#.....##.. #..#.#....#....#....#..#. ####.###..#....#....#..#. #..#.#....#....#....#..#. #..#.#....#....#....#..#. #..#.####.####.####..##..

", ); }


Question:
Found with a error]: auto traits cannot have associated items thread 'rustc' panicked at 'internal error: entered unreachable code', <details<summaryFull output including backtrace</summary</detailsRegression in nightly-2022-11-05, somewhere in rollup , likely (CC 2022-12-14 label +F-autotraits <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Fixed the ICE, the error message now is: I think the second error message should not come out, considering the is an auto trait.

let entry = spanned_predicates.entry(spans); entry.or_insert_with(|| (path, tr_self_ty, Vec::new())).2.push(p); } <ins> Some(Node::Item(hir::Item { kind: hir::ItemKind::Trait(rustc_ast::ast::IsAuto::Yes, ..), span: item_span, .. })) => { tcx.sess.delay_span_bug( *item_span, "auto trait is invoked with no method error, but no error reported?", ); } </ins> Some(_) => unreachable!(), None => (), }


Question:
Found with a error]: auto traits cannot have associated items thread 'rustc' panicked at 'internal error: entered unreachable code', <details<summaryFull output including backtrace</summary</detailsRegression in nightly-2022-11-05, somewhere in rollup , likely (CC 2022-12-14 label +F-autotraits <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Fixed the ICE, the error message now is: I think the second error message should not come out, considering the is an auto trait.

<ins> #![feature(auto_traits)] auto trait Foo { fn g(&self); //~ ERROR auto traits cannot have associated items } trait Bar { fn f(&self) { self.g(); //~ ERROR the method `g` exists for reference `&Self`, but its trait bounds were not satisfied } } fn main() {} </ins>


Question:
Found with a error]: auto traits cannot have associated items thread 'rustc' panicked at 'internal error: entered unreachable code', <details<summaryFull output including backtrace</summary</detailsRegression in nightly-2022-11-05, somewhere in rollup , likely (CC 2022-12-14 label +F-autotraits <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Fixed the ICE, the error message now is: I think the second error message should not come out, considering the is an auto trait.

<ins> error[E0380]: auto traits cannot have associated items --> $DIR/issue-105732.rs:4:8 | LL | auto trait Foo { |            --- auto trait cannot have associated items LL |     fn g(&self); |     ---^-------- help: remove these associated items error[E0599]: the method `g` exists for reference `&Self`, but its trait bounds were not satisfied --> $DIR/issue-105732.rs:9:14 | LL |         self.g(); |              ^ | = note: the following trait bounds were not satisfied: `Self: Foo` which is required by `&Self: Foo` `&Self: Foo` = help: items from traits can only be used if the type parameter is bounded by the trait help: the following trait defines an item `g`, perhaps you need to add a supertrait for it: | LL | trait Bar: Foo { |          +++++ error: aborting due to 2 previous errors Some errors have detailed explanations: E0380, E0599. For more information about an error, try `rustc --explain E0380`. </ins>


Question:
Compiling the  from failed on nightly due to lifetime error while it works on stable. The code in question looks like this and is in taken from On nightly, this failed with: :
modify labels: +regression-from-stable-to-beta
labels +E-needs-bisection
searched nightlies: from nightly-2022-12-06 to nightly-2022-12-10 regressed nightly: nightly-2022-12-10 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details labels -E-needs-bisection
searched nightlies: from nightly-2022-12-09 to nightly-2022-12-27 regressed nightly: nightly-2022-12-10 searched commit range: regressed commit: () <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Sorry, false positive in bisect labels -E-needs-bisection Also raced, sorry :(
You can manually bisect the PRs in that rollup, contains the list of each of their artifacts. I'd start by looking at though.
Yep, it's cc
Possible other examples from beta crater: https://crater- https://crater- https://crater-
Any update on this? I've tested the code on: and it still failed.
AFAICS your bug report has been acknowledged and has an assignee, looks like it's a regression in the beta channel (). The new stable will be out in a few weeks, might be fixed by then.
Thanks, so looks like it's going to take quite some time. I might go ahead and release without waiting for this one.
WG-prioritization assigning priority (). label -I-prioritize +P-high +T-compiler

GenericParamKind, HirId, Node, }; use rustc_hir as hir; <ins> use rustc_hir::def::DefKind; </ins> use rustc_hir::def_id::DefId; use rustc_middle::ty::{self, TyCtxt}; use rustc_session::lint;


Question:
Compiling the  from failed on nightly due to lifetime error while it works on stable. The code in question looks like this and is in taken from On nightly, this failed with: :
modify labels: +regression-from-stable-to-beta
labels +E-needs-bisection
searched nightlies: from nightly-2022-12-06 to nightly-2022-12-10 regressed nightly: nightly-2022-12-10 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details labels -E-needs-bisection
searched nightlies: from nightly-2022-12-09 to nightly-2022-12-27 regressed nightly: nightly-2022-12-10 searched commit range: regressed commit: () <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Sorry, false positive in bisect labels -E-needs-bisection Also raced, sorry :(
You can manually bisect the PRs in that rollup, contains the list of each of their artifacts. I'd start by looking at though.
Yep, it's cc
Possible other examples from beta crater: https://crater- https://crater- https://crater-
Any update on this? I've tested the code on: and it still failed.
AFAICS your bug report has been acknowledged and has an assignee, looks like it's a regression in the beta channel (). The new stable will be out in a few weeks, might be fixed by then.
Thanks, so looks like it's going to take quite some time. I might go ahead and release without waiting for this one.
WG-prioritization assigning priority (). label -I-prioritize +P-high +T-compiler

Some(tcx.typeck_root_def_id(def_id)) } Node::Item(item) => match item.kind { <del> ItemKind::OpaqueTy(hir::OpaqueTy { .. }) => { </del> <ins> ItemKind::OpaqueTy(hir::OpaqueTy { origin: hir::OpaqueTyOrigin::FnReturn(fn_def_id) | hir::OpaqueTyOrigin::AsyncFn(fn_def_id), in_trait, .. }) => { if in_trait { assert!(matches!(tcx.def_kind(fn_def_id), DefKind::AssocFn)) } else { assert!(matches!(tcx.def_kind(fn_def_id), DefKind::AssocFn | DefKind::Fn)) } Some(fn_def_id.to_def_id()) } ItemKind::OpaqueTy(hir::OpaqueTy { origin: hir::OpaqueTyOrigin::TyAlias, .. }) => { </ins> let parent_id = tcx.hir().get_parent_item(hir_id); assert_ne!(parent_id, hir::CRATE_OWNER_ID); debug!("generics_of: parent of opaque ty {:?} is {:?}", def_id, parent_id);


Question:
Compiling the  from failed on nightly due to lifetime error while it works on stable. The code in question looks like this and is in taken from On nightly, this failed with: :
modify labels: +regression-from-stable-to-beta
labels +E-needs-bisection
searched nightlies: from nightly-2022-12-06 to nightly-2022-12-10 regressed nightly: nightly-2022-12-10 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details labels -E-needs-bisection
searched nightlies: from nightly-2022-12-09 to nightly-2022-12-27 regressed nightly: nightly-2022-12-10 searched commit range: regressed commit: () <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Sorry, false positive in bisect labels -E-needs-bisection Also raced, sorry :(
You can manually bisect the PRs in that rollup, contains the list of each of their artifacts. I'd start by looking at though.
Yep, it's cc
Possible other examples from beta crater: https://crater- https://crater- https://crater-
Any update on this? I've tested the code on: and it still failed.
AFAICS your bug report has been acknowledged and has an assignee, looks like it's a regression in the beta channel (). The new stable will be out in a few weeks, might be fixed by then.
Thanks, so looks like it's going to take quite some time. I might go ahead and release without waiting for this one.
WG-prioritization assigning priority (). label -I-prioritize +P-high +T-compiler

<del> // check-pass </del> // edition: 2021 <ins> // known-bug: #105197 // failure-status:101 // dont-check-compiler-stderr </ins> #![feature(async_fn_in_trait)] #![feature(return_position_impl_trait_in_trait)]