Question:
<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed: expect 1 RPITITs in call to '', 'thread 'rustc' panicked at 'assertion failed: expect 1 RPITITs in call to '' File: --auto-reduced (treereduce-rust): original: Version information ` <!-- query stack: [collectreturnpositionimpltraitintraittys] comparing an impl and trait method signature, inferring any hidden types in the process [typeof] computing type of [checkmodimplwf] checking that impls are well-formed in top-level module [analysis] running analysis passes on this crate --
Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details

<ins> #![feature(generic_const_exprs)] //~^ WARN the feature `generic_const_exprs` is incomplete #![feature(non_lifetime_binders)] //~^ WARN the feature `non_lifetime_binders` is incomplete // Test for <https://github.com/rust-lang/rust/issues/115497>, // which originally relied on associated_type_bounds, but was // minimized away from that. trait TraitA { type AsA; } trait TraitB { type AsB; } trait TraitC {} fn foo<T>() where for<const N: u8 = { T::A }> T: TraitA<AsA = impl TraitB<AsB = impl TraitC>>, //~^ ERROR defaults for generic parameters are not allowed in `for<...>` binders //~| ERROR `impl Trait` is not allowed in bounds { } fn main() {} </ins>


Question:
<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed: expect 1 RPITITs in call to '', 'thread 'rustc' panicked at 'assertion failed: expect 1 RPITITs in call to '' File: --auto-reduced (treereduce-rust): original: Version information ` <!-- query stack: [collectreturnpositionimpltraitintraittys] comparing an impl and trait method signature, inferring any hidden types in the process [typeof] computing type of [checkmodimplwf] checking that impls are well-formed in top-level module [analysis] running analysis passes on this crate --
Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details

<ins> warning: the feature `generic_const_exprs` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/bad-suggestion-on-missing-assoc.rs:1:12 | LL | #![feature(generic_const_exprs)] |            ^^^^^^^^^^^^^^^^^^^ | = note: see issue #76560 <https://github.com/rust-lang/rust/issues/76560> for more information = note: `#[warn(incomplete_features)]` on by default warning: the feature `non_lifetime_binders` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/bad-suggestion-on-missing-assoc.rs:3:12 | LL | #![feature(non_lifetime_binders)] |            ^^^^^^^^^^^^^^^^^^^^ | = note: see issue #108185 <https://github.com/rust-lang/rust/issues/108185> for more information error: defaults for generic parameters are not allowed in `for<...>` binders --> $DIR/bad-suggestion-on-missing-assoc.rs:20:9 | LL |     for<const N: u8 = { T::A }> T: TraitA<AsA = impl TraitB<AsB = impl TraitC>>, |         ^^^^^^^^^^^^^^^^^^^^^^ error[E0562]: `impl Trait` is not allowed in bounds --> $DIR/bad-suggestion-on-missing-assoc.rs:20:49 | LL |     for<const N: u8 = { T::A }> T: TraitA<AsA = impl TraitB<AsB = impl TraitC>>, |                                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: `impl Trait` is only allowed in arguments and return types of functions and methods error: aborting due to 2 previous errors; 2 warnings emitted For more information about this error, try `rustc --explain E0562`. </ins>


Question:
No response No response No response
I thought the intent with was to use it in a passthrough style, so you can insert it into existing expressions ie. becomes . In which case, maybe the lint should be for not using the value resulting from evaluating .
Not sure about the majority of users but for me is a convenience over . I use it without using the return value almost all of the time.
Probably a common thing to do, sure, but if we're talking about adding a lint, why not nudge the user in the direction of the intended and documented usage? You could at least do both: "insert into an existing expression or pass it a borrow" etc.
The fix in will only report a hint when there is already a happened. For example this code: before this fix the error is: with the fix, since there is already a error, the lint will try to find out the original macro, and suggest a borrow: The suggestion is not 100% right, since if we change it to , we need one more extra fix now(the return type is not expecting a reference), but there is a different issue, at least we have already moved one step on. If the original code is: Then suggest a borrow is a great and correct hint.
Similar in the scenario of function argument: original error is: new errors from the fix:
Would not also be a good hint? The suggestion wouldn't compile anyway right? Because would need to change to take ? Without involved, the compiler does indeed suggest that: Once that's addressed (whichever way it's done), once again becomes transparent, and eg. or works. does not, however, and I see why a "consider borrowing" hint would be good there. However, if you make the change first and leave as-is, the resulting error does not include the suggestion to change , which is unhelpful. (I agree that the message is even less helpful though, I'm not disputing that.)
Yes, it's a good hint, but from the implementation view of a hint, it's much harder to analyze the following code from the error point and then construct a new expression. Even it seems an easy thing for humans. You are right, the suggestion is not 100% right, we may need an extra follow-up fix after applying the hint, which is also a common thing in rustc diagnostics.

#![allow(rustc::untranslatable_diagnostic)] use either::Either; <del> use hir::ClosureKind; </del> <ins> use hir::{ClosureKind, Path}; </ins> use rustc_data_structures::captures::Captures; use rustc_data_structures::fx::FxIndexSet; use rustc_errors::{codes::*, struct_span_code_err, Applicability, Diag, MultiSpan};


Question:
No response No response No response
I thought the intent with was to use it in a passthrough style, so you can insert it into existing expressions ie. becomes . In which case, maybe the lint should be for not using the value resulting from evaluating .
Not sure about the majority of users but for me is a convenience over . I use it without using the return value almost all of the time.
Probably a common thing to do, sure, but if we're talking about adding a lint, why not nudge the user in the direction of the intended and documented usage? You could at least do both: "insert into an existing expression or pass it a borrow" etc.
The fix in will only report a hint when there is already a happened. For example this code: before this fix the error is: with the fix, since there is already a error, the lint will try to find out the original macro, and suggest a borrow: The suggestion is not 100% right, since if we change it to , we need one more extra fix now(the return type is not expecting a reference), but there is a different issue, at least we have already moved one step on. If the original code is: Then suggest a borrow is a great and correct hint.
Similar in the scenario of function argument: original error is: new errors from the fix:
Would not also be a good hint? The suggestion wouldn't compile anyway right? Because would need to change to take ? Without involved, the compiler does indeed suggest that: Once that's addressed (whichever way it's done), once again becomes transparent, and eg. or works. does not, however, and I see why a "consider borrowing" hint would be good there. However, if you make the change first and leave as-is, the resulting error does not include the suggestion to change , which is unhelpful. (I agree that the message is even less helpful though, I'm not disputing that.)
Yes, it's a good hint, but from the implementation view of a hint, it's much harder to analyze the following code from the error point and then construct a new expression. Even it seems an easy thing for humans. You are right, the suggestion is not 100% right, we may need an extra follow-up fix after applying the hint, which is also a common thing in rustc diagnostics.

use rustc_middle::bug; use rustc_middle::hir::nested_filter::OnlyBodies; use rustc_middle::mir::tcx::PlaceTy; <ins> use rustc_middle::mir::VarDebugInfoContents; </ins> use rustc_middle::mir::{ self, AggregateKind, BindingForm, BorrowKind, CallSource, ClearCrossCrate, ConstraintCategory, FakeBorrowKind, FakeReadCause, LocalDecl, LocalInfo, LocalKind, Location, MutBorrowKind,


Question:
No response No response No response
I thought the intent with was to use it in a passthrough style, so you can insert it into existing expressions ie. becomes . In which case, maybe the lint should be for not using the value resulting from evaluating .
Not sure about the majority of users but for me is a convenience over . I use it without using the return value almost all of the time.
Probably a common thing to do, sure, but if we're talking about adding a lint, why not nudge the user in the direction of the intended and documented usage? You could at least do both: "insert into an existing expression or pass it a borrow" etc.
The fix in will only report a hint when there is already a happened. For example this code: before this fix the error is: with the fix, since there is already a error, the lint will try to find out the original macro, and suggest a borrow: The suggestion is not 100% right, since if we change it to , we need one more extra fix now(the return type is not expecting a reference), but there is a different issue, at least we have already moved one step on. If the original code is: Then suggest a borrow is a great and correct hint.
Similar in the scenario of function argument: original error is: new errors from the fix:
Would not also be a good hint? The suggestion wouldn't compile anyway right? Because would need to change to take ? Without involved, the compiler does indeed suggest that: Once that's addressed (whichever way it's done), once again becomes transparent, and eg. or works. does not, however, and I see why a "consider borrowing" hint would be good there. However, if you make the change first and leave as-is, the resulting error does not include the suggestion to change , which is unhelpful. (I agree that the message is even less helpful though, I'm not disputing that.)
Yes, it's a good hint, but from the implementation view of a hint, it's much harder to analyze the following code from the error point and then construct a new expression. Even it seems an easy thing for humans. You are right, the suggestion is not 100% right, we may need an extra follow-up fix after applying the hint, which is also a common thing in rustc diagnostics.

self.suggest_cloning(err, ty, expr, None, Some(move_spans)); } } <del> if let Some(pat) = finder.pat { </del> <ins> self.suggest_ref_for_dbg_args(expr, place, move_span, err); // it's useless to suggest inserting `ref` when the span don't comes from local code if let Some(pat) = finder.pat && !move_span.is_dummy() && !self.infcx.tcx.sess.source_map().is_imported(move_span) { </ins> *in_pattern = true; let mut sugg = vec![(pat.span.shrink_to_lo(), "ref ".to_string())]; if let Some(pat) = finder.parent_pat {


Question:
No response No response No response
I thought the intent with was to use it in a passthrough style, so you can insert it into existing expressions ie. becomes . In which case, maybe the lint should be for not using the value resulting from evaluating .
Not sure about the majority of users but for me is a convenience over . I use it without using the return value almost all of the time.
Probably a common thing to do, sure, but if we're talking about adding a lint, why not nudge the user in the direction of the intended and documented usage? You could at least do both: "insert into an existing expression or pass it a borrow" etc.
The fix in will only report a hint when there is already a happened. For example this code: before this fix the error is: with the fix, since there is already a error, the lint will try to find out the original macro, and suggest a borrow: The suggestion is not 100% right, since if we change it to , we need one more extra fix now(the return type is not expecting a reference), but there is a different issue, at least we have already moved one step on. If the original code is: Then suggest a borrow is a great and correct hint.
Similar in the scenario of function argument: original error is: new errors from the fix:
Would not also be a good hint? The suggestion wouldn't compile anyway right? Because would need to change to take ? Without involved, the compiler does indeed suggest that: Once that's addressed (whichever way it's done), once again becomes transparent, and eg. or works. does not, however, and I see why a "consider borrowing" hint would be good there. However, if you make the change first and leave as-is, the resulting error does not include the suggestion to change , which is unhelpful. (I agree that the message is even less helpful though, I'm not disputing that.)
Yes, it's a good hint, but from the implementation view of a hint, it's much harder to analyze the following code from the error point and then construct a new expression. Even it seems an easy thing for humans. You are right, the suggestion is not 100% right, we may need an extra follow-up fix after applying the hint, which is also a common thing in rustc diagnostics.

} } <ins> // for dbg!(x) which may take ownership, suggest dbg!(&x) instead // but here we actually do not check whether the macro name is `dbg!` // so that we may extend the scope a bit larger to cover more cases fn suggest_ref_for_dbg_args( &self, body: &hir::Expr<'_>, place: &Place<'tcx>, move_span: Span, err: &mut Diag<'infcx>, ) { let var_info = self.body.var_debug_info.iter().find(|info| match info.value { VarDebugInfoContents::Place(ref p) => p == place, _ => false, }); let arg_name = if let Some(var_info) = var_info { var_info.name } else { return; }; struct MatchArgFinder { expr_span: Span, match_arg_span: Option<Span>, arg_name: Symbol, } impl Visitor<'_> for MatchArgFinder { fn visit_expr(&mut self, e: &hir::Expr<'_>) { // dbg! is expanded into a match pattern, we need to find the right argument span if let hir::ExprKind::Match(expr, ..) = &e.kind && let hir::ExprKind::Path(hir::QPath::Resolved( _, path @ Path { segments: [seg], .. }, )) = &expr.kind && seg.ident.name == self.arg_name && self.expr_span.source_callsite().contains(expr.span) { self.match_arg_span = Some(path.span); } hir::intravisit::walk_expr(self, e); } } let mut finder = MatchArgFinder { expr_span: move_span, match_arg_span: None, arg_name }; finder.visit_expr(body); if let Some(macro_arg_span) = finder.match_arg_span { err.span_suggestion_verbose( macro_arg_span.shrink_to_lo(), "consider borrowing instead of transferring ownership", "&", Applicability::MachineApplicable, ); } } </ins> fn report_use_of_uninitialized( &self, mpi: MovePathIndex,


Question:
No response No response No response
I thought the intent with was to use it in a passthrough style, so you can insert it into existing expressions ie. becomes . In which case, maybe the lint should be for not using the value resulting from evaluating .
Not sure about the majority of users but for me is a convenience over . I use it without using the return value almost all of the time.
Probably a common thing to do, sure, but if we're talking about adding a lint, why not nudge the user in the direction of the intended and documented usage? You could at least do both: "insert into an existing expression or pass it a borrow" etc.
The fix in will only report a hint when there is already a happened. For example this code: before this fix the error is: with the fix, since there is already a error, the lint will try to find out the original macro, and suggest a borrow: The suggestion is not 100% right, since if we change it to , we need one more extra fix now(the return type is not expecting a reference), but there is a different issue, at least we have already moved one step on. If the original code is: Then suggest a borrow is a great and correct hint.
Similar in the scenario of function argument: original error is: new errors from the fix:
Would not also be a good hint? The suggestion wouldn't compile anyway right? Because would need to change to take ? Without involved, the compiler does indeed suggest that: Once that's addressed (whichever way it's done), once again becomes transparent, and eg. or works. does not, however, and I see why a "consider borrowing" hint would be good there. However, if you make the change first and leave as-is, the resulting error does not include the suggestion to change , which is unhelpful. (I agree that the message is even less helpful though, I'm not disputing that.)
Yes, it's a good hint, but from the implementation view of a hint, it's much harder to analyze the following code from the error point and then construct a new expression. Even it seems an easy thing for humans. You are right, the suggestion is not 100% right, we may need an extra follow-up fix after applying the hint, which is also a common thing in rustc diagnostics.

<ins> fn s() -> String { let a = String::new(); dbg!(a); return a; //~ ERROR use of moved value: } fn m() -> String { let a = String::new(); dbg!(1, 2, a, 1, 2); return a; //~ ERROR use of moved value: } fn t(a: String) -> String { let b: String = "".to_string(); dbg!(a, b); return b; //~ ERROR use of moved value: } fn x(a: String) -> String { let b: String = "".to_string(); dbg!(a, b); return a; //~ ERROR use of moved value: } macro_rules! my_dbg { () => { eprintln!("[{}:{}:{}]", file!(), line!(), column!()) }; ($val:expr $(,)?) => { match $val { tmp => { eprintln!("[{}:{}:{}] {} = {:#?}", file!(), line!(), column!(), stringify!($val), &tmp); tmp } } }; ($($val:expr),+ $(,)?) => { ($(my_dbg!($val)),+,) }; } fn test_my_dbg() -> String { let b: String = "".to_string(); my_dbg!(b, 1); return b; //~ ERROR use of moved value: } fn test_not_macro() -> String { let a = String::new(); let _b = match a { tmp => { eprintln!("dbg: {}", tmp); tmp } }; return a; //~ ERROR use of moved value: } fn get_expr(_s: String) {} fn test() { let a: String = "".to_string(); let _res = get_expr(dbg!(a)); let _l = a.len(); //~ ERROR borrow of moved value } fn main() {} </ins>


Question:
No response No response No response
I thought the intent with was to use it in a passthrough style, so you can insert it into existing expressions ie. becomes . In which case, maybe the lint should be for not using the value resulting from evaluating .
Not sure about the majority of users but for me is a convenience over . I use it without using the return value almost all of the time.
Probably a common thing to do, sure, but if we're talking about adding a lint, why not nudge the user in the direction of the intended and documented usage? You could at least do both: "insert into an existing expression or pass it a borrow" etc.
The fix in will only report a hint when there is already a happened. For example this code: before this fix the error is: with the fix, since there is already a error, the lint will try to find out the original macro, and suggest a borrow: The suggestion is not 100% right, since if we change it to , we need one more extra fix now(the return type is not expecting a reference), but there is a different issue, at least we have already moved one step on. If the original code is: Then suggest a borrow is a great and correct hint.
Similar in the scenario of function argument: original error is: new errors from the fix:
Would not also be a good hint? The suggestion wouldn't compile anyway right? Because would need to change to take ? Without involved, the compiler does indeed suggest that: Once that's addressed (whichever way it's done), once again becomes transparent, and eg. or works. does not, however, and I see why a "consider borrowing" hint would be good there. However, if you make the change first and leave as-is, the resulting error does not include the suggestion to change , which is unhelpful. (I agree that the message is even less helpful though, I'm not disputing that.)
Yes, it's a good hint, but from the implementation view of a hint, it's much harder to analyze the following code from the error point and then construct a new expression. Even it seems an easy thing for humans. You are right, the suggestion is not 100% right, we may need an extra follow-up fix after applying the hint, which is also a common thing in rustc diagnostics.

<ins> error[E0382]: use of moved value: `a` --> $DIR/dbg-issue-120327.rs:4:12 | LL |     let a = String::new(); |         - move occurs because `a` has type `String`, which does not implement the `Copy` trait LL |     dbg!(a); |     ------- value moved here LL |     return a; |            ^ value used here after move | help: consider borrowing instead of transferring ownership | LL |     dbg!(&a); |          + error[E0382]: use of moved value: `a` --> $DIR/dbg-issue-120327.rs:10:12 | LL |     let a = String::new(); |         - move occurs because `a` has type `String`, which does not implement the `Copy` trait LL |     dbg!(1, 2, a, 1, 2); |     ------------------- value moved here LL |     return a; |            ^ value used here after move | help: consider borrowing instead of transferring ownership | LL |     dbg!(1, 2, &a, 1, 2); |                + error[E0382]: use of moved value: `b` --> $DIR/dbg-issue-120327.rs:16:12 | LL |     let b: String = "".to_string(); |         - move occurs because `b` has type `String`, which does not implement the `Copy` trait LL |     dbg!(a, b); |     ---------- value moved here LL |     return b; |            ^ value used here after move | help: consider borrowing instead of transferring ownership | LL |     dbg!(a, &b); |             + error[E0382]: use of moved value: `a` --> $DIR/dbg-issue-120327.rs:22:12 | LL | fn x(a: String) -> String { |      - move occurs because `a` has type `String`, which does not implement the `Copy` trait LL |     let b: String = "".to_string(); LL |     dbg!(a, b); |     ---------- value moved here LL |     return a; |            ^ value used here after move | help: consider borrowing instead of transferring ownership | LL |     dbg!(&a, b); |          + error[E0382]: use of moved value: `b` --> $DIR/dbg-issue-120327.rs:46:12 | LL |             tmp => { |             --- value moved here ... LL |     let b: String = "".to_string(); |         - move occurs because `b` has type `String`, which does not implement the `Copy` trait LL |     my_dbg!(b, 1); LL |     return b; |            ^ value used here after move | help: consider borrowing instead of transferring ownership | LL |     my_dbg!(&b, 1); |             + help: borrow this binding in the pattern to avoid moving the value | LL |             ref tmp => { |             +++ error[E0382]: use of moved value: `a` --> $DIR/dbg-issue-120327.rs:57:12 | LL |     let a = String::new(); |         - move occurs because `a` has type `String`, which does not implement the `Copy` trait LL |     let _b = match a { LL |         tmp => { |         --- value moved here ... LL |     return a; |            ^ value used here after move | help: borrow this binding in the pattern to avoid moving the value | LL |         ref tmp => { |         +++ error[E0382]: borrow of moved value: `a` --> $DIR/dbg-issue-120327.rs:65:14 | LL |     let a: String = "".to_string(); |         - move occurs because `a` has type `String`, which does not implement the `Copy` trait LL |     let _res = get_expr(dbg!(a)); |                         ------- value moved here LL |     let _l = a.len(); |              ^ value borrowed here after move | help: consider borrowing instead of transferring ownership | LL |     let _res = get_expr(dbg!(&a)); |                              + error: aborting due to 7 previous errors For more information about this error, try `rustc --explain E0382`. </ins>


Question:
No response No response No response
I thought the intent with was to use it in a passthrough style, so you can insert it into existing expressions ie. becomes . In which case, maybe the lint should be for not using the value resulting from evaluating .
Not sure about the majority of users but for me is a convenience over . I use it without using the return value almost all of the time.
Probably a common thing to do, sure, but if we're talking about adding a lint, why not nudge the user in the direction of the intended and documented usage? You could at least do both: "insert into an existing expression or pass it a borrow" etc.
The fix in will only report a hint when there is already a happened. For example this code: before this fix the error is: with the fix, since there is already a error, the lint will try to find out the original macro, and suggest a borrow: The suggestion is not 100% right, since if we change it to , we need one more extra fix now(the return type is not expecting a reference), but there is a different issue, at least we have already moved one step on. If the original code is: Then suggest a borrow is a great and correct hint.
Similar in the scenario of function argument: original error is: new errors from the fix:
Would not also be a good hint? The suggestion wouldn't compile anyway right? Because would need to change to take ? Without involved, the compiler does indeed suggest that: Once that's addressed (whichever way it's done), once again becomes transparent, and eg. or works. does not, however, and I see why a "consider borrowing" hint would be good there. However, if you make the change first and leave as-is, the resulting error does not include the suggestion to change , which is unhelpful. (I agree that the message is even less helpful though, I'm not disputing that.)
Yes, it's a good hint, but from the implementation view of a hint, it's much harder to analyze the following code from the error point and then construct a new expression. Even it seems an easy thing for humans. You are right, the suggestion is not 100% right, we may need an extra follow-up fix after applying the hint, which is also a common thing in rustc diagnostics.

|             ^^^^^^^ value used here after move | = note: this error originates in the macro `dbg` (in Nightly builds, run with -Z macro-backtrace for more info) <ins> help: consider borrowing instead of transferring ownership | LL |     let _ = dbg!(&a); |                  + </ins> error: aborting due to 1 previous error


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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<summary<strongBacktrace</strong</summary<p</p</details
seem like options that when paired together would cause issues... At first glance, I'm actually not sure why this is filed as a bug.
I agree. Nobody should be testing , I don't know why those passes are even in the codebase. But this is a bug. I've found this in real code with a much smaller set of flags: And this bisects to Bisected by hand, there's no nightly with that PR yet. Don't know where Matthias got that toolchain.
Afaict likes to do ICE testing against master
We just hit this on Fuchsia as well. I think we should revert the PR until we fix this issue and reland it.
Another one with
Also here's a list of files from the rustc repo that all seem to trigger the problem in one way or another
Looks like there is one more issue in GVN ():
There is no basis for the assumption that interpreter will never downcast to an uninhabited variant:
nice example! That assert was as an experiment to see if we ever hit that codepath, and it seems like the answer is yes. It should thus be removed, with a suitable const-eval test case.
I wonder if that code shouldn't have a read somewhere though... it is conceptually a match after all. Still, the assertion should go: That adds test, but not the others.
WG-prioritization assigning priority (). label -I-prioritize +P-medium

// This makes several assumptions about what layouts we will encounter; we match what // codegen does as good as we can (see `extract_field` in `rustc_codegen_ssa/src/mir/operand.rs`). let inner_val: Immediate<_> = match (**self, self.layout.abi) { <del> // if the entire value is uninit, then so is the field (can happen in ConstProp) </del> <ins> // If the entire value is uninit, then so is the field (can happen in ConstProp). </ins> (Immediate::Uninit, _) => Immediate::Uninit, <ins> // If the field is uninhabited, we can forget the data (can happen in ConstProp). // `enum S { A(!), B, C }` is an example of an enum with Scalar layout that // has an `Uninhabited` variant, which means this case is possible. _ if layout.abi.is_uninhabited() => Immediate::Uninit, </ins> // the field contains no information, can be left uninit // (Scalar/ScalarPair can contain even aligned ZST, not just 1-ZST) _ if layout.is_zst() => Immediate::Uninit,


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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<summary<strongBacktrace</strong</summary<p</p</details
seem like options that when paired together would cause issues... At first glance, I'm actually not sure why this is filed as a bug.
I agree. Nobody should be testing , I don't know why those passes are even in the codebase. But this is a bug. I've found this in real code with a much smaller set of flags: And this bisects to Bisected by hand, there's no nightly with that PR yet. Don't know where Matthias got that toolchain.
Afaict likes to do ICE testing against master
We just hit this on Fuchsia as well. I think we should revert the PR until we fix this issue and reland it.
Another one with
Also here's a list of files from the rustc repo that all seem to trigger the problem in one way or another
Looks like there is one more issue in GVN ():
There is no basis for the assumption that interpreter will never downcast to an uninhabited variant:
nice example! That assert was as an experiment to see if we ever hit that codepath, and it seems like the answer is yes. It should thus be removed, with a suitable const-eval test case.
I wonder if that code shouldn't have a read somewhere though... it is conceptually a match after all. Still, the assertion should go: That adds test, but not the others.
WG-prioritization assigning priority (). label -I-prioritize +P-medium

// see https://github.com/rust-lang/rust/issues/93688#issuecomment-1032929496.) // So we just "offset" by 0. let layout = base.layout().for_variant(self, variant); <del> // In the future we might want to allow this to permit code like this: // (this is a Rust/MIR pseudocode mix) // ``` // enum Option2 { //   Some(i32, !), //   None, // } // // fn panic() -> ! { panic!() } // // let x: Option2; // x.Some.0 = 42; // x.Some.1 = panic(); // SetDiscriminant(x, Some); // ``` // However, for now we don't generate such MIR, and this check here *has* found real // bugs (see https://github.com/rust-lang/rust/issues/115145), so we will keep rejecting // it. assert!(!layout.abi.is_uninhabited()); </del> <ins> // This variant may in fact be uninhabited. // See <https://github.com/rust-lang/rust/issues/120337>. </ins> // This cannot be `transmute` as variants *can* have a smaller size than the entire enum. base.offset(Size::ZERO, layout, self)


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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<summary<strongBacktrace</strong</summary<p</p</details
seem like options that when paired together would cause issues... At first glance, I'm actually not sure why this is filed as a bug.
I agree. Nobody should be testing , I don't know why those passes are even in the codebase. But this is a bug. I've found this in real code with a much smaller set of flags: And this bisects to Bisected by hand, there's no nightly with that PR yet. Don't know where Matthias got that toolchain.
Afaict likes to do ICE testing against master
We just hit this on Fuchsia as well. I think we should revert the PR until we fix this issue and reland it.
Another one with
Also here's a list of files from the rustc repo that all seem to trigger the problem in one way or another
Looks like there is one more issue in GVN ():
There is no basis for the assumption that interpreter will never downcast to an uninhabited variant:
nice example! That assert was as an experiment to see if we ever hit that codepath, and it seems like the answer is yes. It should thus be removed, with a suitable const-eval test case.
I wonder if that code shouldn't have a read somewhere though... it is conceptually a match after all. Still, the assertion should go: That adds test, but not the others.
WG-prioritization assigning priority (). label -I-prioritize +P-medium

/// "Downcast" to a variant of an enum or a coroutine. /// /// The included Symbol is the name of the variant, used for printing MIR. <ins> /// /// This operation itself is never UB, all it does is change the type of the place. </ins> Downcast(Option<Symbol>, VariantIdx), /// Like an explicit cast from an opaque type to a concrete type, but without


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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<summary<strongBacktrace</strong</summary<p</p</details
seem like options that when paired together would cause issues... At first glance, I'm actually not sure why this is filed as a bug.
I agree. Nobody should be testing , I don't know why those passes are even in the codebase. But this is a bug. I've found this in real code with a much smaller set of flags: And this bisects to Bisected by hand, there's no nightly with that PR yet. Don't know where Matthias got that toolchain.
Afaict likes to do ICE testing against master
We just hit this on Fuchsia as well. I think we should revert the PR until we fix this issue and reland it.
Another one with
Also here's a list of files from the rustc repo that all seem to trigger the problem in one way or another
Looks like there is one more issue in GVN ():
There is no basis for the assumption that interpreter will never downcast to an uninhabited variant:
nice example! That assert was as an experiment to see if we ever hit that codepath, and it seems like the answer is yes. It should thus be removed, with a suitable const-eval test case.
I wonder if that code shouldn't have a read somewhere though... it is conceptually a match after all. Still, the assertion should go: That adds test, but not the others.
WG-prioritization assigning priority (). label -I-prioritize +P-medium

operand, &mut |elem, op| match elem { TrackElem::Field(idx) => self.ecx.project_field(op, idx.as_usize()).ok(), <del> TrackElem::Variant(idx) => { if op.layout.for_variant(&self.ecx, idx).abi.is_uninhabited() { return None; } self.ecx.project_downcast(op, idx).ok() } </del> <ins> TrackElem::Variant(idx) => self.ecx.project_downcast(op, idx).ok(), </ins> TrackElem::Discriminant => { let variant = self.ecx.read_discriminant(op).ok()?; let discr_value =


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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<summary<strongBacktrace</strong</summary<p</p</details
seem like options that when paired together would cause issues... At first glance, I'm actually not sure why this is filed as a bug.
I agree. Nobody should be testing , I don't know why those passes are even in the codebase. But this is a bug. I've found this in real code with a much smaller set of flags: And this bisects to Bisected by hand, there's no nightly with that PR yet. Don't know where Matthias got that toolchain.
Afaict likes to do ICE testing against master
We just hit this on Fuchsia as well. I think we should revert the PR until we fix this issue and reland it.
Another one with
Also here's a list of files from the rustc repo that all seem to trigger the problem in one way or another
Looks like there is one more issue in GVN ():
There is no basis for the assumption that interpreter will never downcast to an uninhabited variant:
nice example! That assert was as an experiment to see if we ever hit that codepath, and it seems like the answer is yes. It should thus be removed, with a suitable const-eval test case.
I wonder if that code shouldn't have a read somewhere though... it is conceptually a match after all. Still, the assertion should go: That adds test, but not the others.
WG-prioritization assigning priority (). label -I-prioritize +P-medium

<ins> // Validation stops the test before the ICE we used to hit //@compile-flags: -Zmiri-disable-validation #![feature(never_type)] #[derive(Copy, Clone)] pub enum E { A(!), } pub union U { u: (), e: E, } fn main() { let E::A(ref _a) = unsafe { &(&U { u: () }).e }; } </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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<summary<strongBacktrace</strong</summary<p</p</details
seem like options that when paired together would cause issues... At first glance, I'm actually not sure why this is filed as a bug.
I agree. Nobody should be testing , I don't know why those passes are even in the codebase. But this is a bug. I've found this in real code with a much smaller set of flags: And this bisects to Bisected by hand, there's no nightly with that PR yet. Don't know where Matthias got that toolchain.
Afaict likes to do ICE testing against master
We just hit this on Fuchsia as well. I think we should revert the PR until we fix this issue and reland it.
Another one with
Also here's a list of files from the rustc repo that all seem to trigger the problem in one way or another
Looks like there is one more issue in GVN ():
There is no basis for the assumption that interpreter will never downcast to an uninhabited variant:
nice example! That assert was as an experiment to see if we ever hit that codepath, and it seems like the answer is yes. It should thus be removed, with a suitable const-eval test case.
I wonder if that code shouldn't have a read somewhere though... it is conceptually a match after all. Still, the assertion should go: That adds test, but not the others.
WG-prioritization assigning priority (). label -I-prioritize +P-medium

<ins> - // MIR for `f` before GVN + // MIR for `f` after GVN fn f() -> u32 { let mut _0: u32; let _1: u32; let mut _2: E; let mut _3: &U; let _4: U; scope 1 { debug i => _1; } scope 2 { let mut _5: &U; } bb0: { StorageLive(_2); StorageLive(_3); _5 = const _; _3 = &(*_5); _2 = ((*_3).1: E); StorageLive(_1); -         _1 = ((_2 as A).1: u32); +         _1 = const 0_u32; StorageDead(_3); StorageDead(_2); -         _0 = _1; +         _0 = const 0_u32; StorageDead(_1); return; } } </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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<summary<strongBacktrace</strong</summary<p</p</details
seem like options that when paired together would cause issues... At first glance, I'm actually not sure why this is filed as a bug.
I agree. Nobody should be testing , I don't know why those passes are even in the codebase. But this is a bug. I've found this in real code with a much smaller set of flags: And this bisects to Bisected by hand, there's no nightly with that PR yet. Don't know where Matthias got that toolchain.
Afaict likes to do ICE testing against master
We just hit this on Fuchsia as well. I think we should revert the PR until we fix this issue and reland it.
Another one with
Also here's a list of files from the rustc repo that all seem to trigger the problem in one way or another
Looks like there is one more issue in GVN ():
There is no basis for the assumption that interpreter will never downcast to an uninhabited variant:
nice example! That assert was as an experiment to see if we ever hit that codepath, and it seems like the answer is yes. It should thus be removed, with a suitable const-eval test case.
I wonder if that code shouldn't have a read somewhere though... it is conceptually a match after all. Still, the assertion should go: That adds test, but not the others.
WG-prioritization assigning priority (). label -I-prioritize +P-medium

<ins> // unit-test: GVN // compile-flags: -O // EMIT_MIR_FOR_EACH_PANIC_STRATEGY // skip-filecheck #![feature(never_type)] #[derive(Copy, Clone)] pub enum E { A(!, u32), } pub union U { i: u32, e: E, } // EMIT_MIR gvn_uninhabited.f.GVN.diff pub const fn f() -> u32 { let E::A(_, i) = unsafe { (&U { i: 0 }).e }; i } fn main() {} </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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<summary<strongBacktrace</strong</summary<p</p</details
seem like options that when paired together would cause issues... At first glance, I'm actually not sure why this is filed as a bug.
I agree. Nobody should be testing , I don't know why those passes are even in the codebase. But this is a bug. I've found this in real code with a much smaller set of flags: And this bisects to Bisected by hand, there's no nightly with that PR yet. Don't know where Matthias got that toolchain.
Afaict likes to do ICE testing against master
We just hit this on Fuchsia as well. I think we should revert the PR until we fix this issue and reland it.
Another one with
Also here's a list of files from the rustc repo that all seem to trigger the problem in one way or another
Looks like there is one more issue in GVN ():
There is no basis for the assumption that interpreter will never downcast to an uninhabited variant:
nice example! That assert was as an experiment to see if we ever hit that codepath, and it seems like the answer is yes. It should thus be removed, with a suitable const-eval test case.
I wonder if that code shouldn't have a read somewhere though... it is conceptually a match after all. Still, the assertion should go: That adds test, but not the others.
WG-prioritization assigning priority (). label -I-prioritize +P-medium

<ins> // check-pass #![feature(never_type)] #[derive(Copy, Clone)] pub enum E { A(!), } pub union U { u: (), e: E, } pub const C: () = { let E::A(ref a) = unsafe { &(&U { u: () }).e}; }; fn main() {} </ins>


Question: The user wanted something with "linux", and there is a name-value cfg that has the value "linux", so they probably wanted that. No response

BuiltinLintDiagnostics::UnexpectedCfgName((name, name_span), value) => { let possibilities: Vec<Symbol> = sess.parse_sess.check_config.expecteds.keys().copied().collect(); <ins> let mut names_possibilities: Vec<_> = if value.is_none() { // We later sort and display all the possibilities, so the order here does not matter. #[allow(rustc::potential_query_instability)] sess.parse_sess .check_config .expecteds .iter() .filter_map(|(k, v)| match v { ExpectedValues::Some(v) if v.contains(&Some(name)) => Some(k), _ => None, }) .collect() } else { Vec::new() }; </ins> let is_from_cargo = std::env::var_os("CARGO").is_some(); let mut is_feature_cfg = name == sym::feature;


Question: The user wanted something with "linux", and there is a name-value cfg that has the value "linux", so they probably wanted that. No response

} is_feature_cfg |= best_match == sym::feature; <del> } else if !possibilities.is_empty() { let mut possibilities = possibilities.iter().map(Symbol::as_str).collect::<Vec<_>>(); possibilities.sort(); let possibilities = possibilities.join("`, `"); </del> <ins> } else { if !names_possibilities.is_empty() && names_possibilities.len() <= 3 { names_possibilities.sort(); for cfg_name in names_possibilities.iter() { db.span_suggestion( name_span, "found config with similar value", format!("{cfg_name} = "{name}""), Applicability::MaybeIncorrect, ); } } if !possibilities.is_empty() { let mut possibilities = possibilities.iter().map(Symbol::as_str).collect::<Vec<_>>(); possibilities.sort(); let possibilities = possibilities.join("`, `"); </ins> <del> // The list of expected names can be long (even by default) and // so the diagnostic produced can take a lot of space. To avoid // cloging the user output we only want to print that diagnostic // once. db.help_once(format!("expected names are: `{possibilities}`")); </del> <ins> // The list of expected names can be long (even by default) and // so the diagnostic produced can take a lot of space. To avoid // cloging the user output we only want to print that diagnostic // once. db.help_once(format!("expected names are: `{possibilities}`")); } </ins> } let inst = if let Some((value, _value_span)) = value {


Question: The user wanted something with "linux", and there is a name-value cfg that has the value "linux", so they probably wanted that. No response

<ins> // #120427 // This test checks we won't suggest more than 3 span suggestions for cfg names // // check-pass // compile-flags: -Z unstable-options // compile-flags: --check-cfg=cfg(foo,values("value")) --check-cfg=cfg(bar,values("value")) --check-cfg=cfg(bee,values("value")) --check-cfg=cfg(cow,values("value")) #[cfg(value)] //~^ WARNING unexpected `cfg` condition name: `value` fn x() {} fn main() {} </ins>


Question: The user wanted something with "linux", and there is a name-value cfg that has the value "linux", so they probably wanted that. No response

<ins> warning: unexpected `cfg` condition name: `value` --> $DIR/cfg-value-for-cfg-name-duplicate.rs:8:7 | LL | #[cfg(value)] |       ^^^^^ | = help: expected names are: `bar`, `bee`, `cow`, `debug_assertions`, `doc`, `doctest`, `foo`, `miri`, `overflow_checks`, `panic`, `proc_macro`, `relocation_model`, `sanitize`, `sanitizer_cfi_generalize_pointers`, `sanitizer_cfi_normalize_integers`, `target_abi`, `target_arch`, `target_endian`, `target_env`, `target_family`, `target_feature`, `target_has_atomic`, `target_has_atomic_equal_alignment`, `target_has_atomic_load_store`, `target_os`, `target_pointer_width`, `target_thread_local`, `target_vendor`, `test`, `unix`, `windows` = help: to expect this configuration use `--check-cfg=cfg(value)` = note: see <https://doc.rust-lang.org/nightly/unstable-book/compiler-flags/check-cfg.html> for more information about checking conditional configuration = note: `#[warn(unexpected_cfgs)]` on by default warning: 1 warning emitted </ins>


Question: The user wanted something with "linux", and there is a name-value cfg that has the value "linux", so they probably wanted that. No response

<ins> // #120427 // This test checks that when a single cfg has a value for user's specified name // // check-pass // compile-flags: -Z unstable-options // compile-flags: --check-cfg=cfg(foo,values("my_value")) --check-cfg=cfg(bar,values("my_value")) #[cfg(my_value)] //~^ WARNING unexpected `cfg` condition name: `my_value` fn x() {} fn main() {} </ins>


Question: The user wanted something with "linux", and there is a name-value cfg that has the value "linux", so they probably wanted that. No response

<ins> warning: unexpected `cfg` condition name: `my_value` --> $DIR/cfg-value-for-cfg-name-multiple.rs:8:7 | LL | #[cfg(my_value)] |       ^^^^^^^^ | = help: expected names are: `bar`, `debug_assertions`, `doc`, `doctest`, `foo`, `miri`, `overflow_checks`, `panic`, `proc_macro`, `relocation_model`, `sanitize`, `sanitizer_cfi_generalize_pointers`, `sanitizer_cfi_normalize_integers`, `target_abi`, `target_arch`, `target_endian`, `target_env`, `target_family`, `target_feature`, `target_has_atomic`, `target_has_atomic_equal_alignment`, `target_has_atomic_load_store`, `target_os`, `target_pointer_width`, `target_thread_local`, `target_vendor`, `test`, `unix`, `windows` = help: to expect this configuration use `--check-cfg=cfg(my_value)` = note: see <https://doc.rust-lang.org/nightly/unstable-book/compiler-flags/check-cfg.html> for more information about checking conditional configuration = note: `#[warn(unexpected_cfgs)]` on by default help: found config with similar value | LL | #[cfg(foo = "my_value")] |       ~~~~~~~~~~~~~~~~ help: found config with similar value | LL | #[cfg(bar = "my_value")] |       ~~~~~~~~~~~~~~~~ warning: 1 warning emitted </ins>


Question: The user wanted something with "linux", and there is a name-value cfg that has the value "linux", so they probably wanted that. No response

<ins> // #120427 // This test checks that when a single cfg has a value for user's specified name // suggest to use `#[cfg(target_os = "linux")]` instead of `#[cfg(linux)]` // // check-pass // compile-flags: -Z unstable-options // compile-flags: --check-cfg=cfg() #[cfg(linux)] //~^ WARNING unexpected `cfg` condition name: `linux` fn x() {} // will not suggest if the cfg has a value #[cfg(linux = "os-name")] //~^ WARNING unexpected `cfg` condition name: `linux` fn y() {} fn main() {} </ins>


Question: The user wanted something with "linux", and there is a name-value cfg that has the value "linux", so they probably wanted that. No response

<ins> warning: unexpected `cfg` condition name: `linux` --> $DIR/cfg-value-for-cfg-name.rs:9:7 | LL | #[cfg(linux)] |       ^^^^^ help: found config with similar value: `target_os = "linux"` | = help: expected names are: `debug_assertions`, `doc`, `doctest`, `miri`, `overflow_checks`, `panic`, `proc_macro`, `relocation_model`, `sanitize`, `sanitizer_cfi_generalize_pointers`, `sanitizer_cfi_normalize_integers`, `target_abi`, `target_arch`, `target_endian`, `target_env`, `target_family`, `target_feature`, `target_has_atomic`, `target_has_atomic_equal_alignment`, `target_has_atomic_load_store`, `target_os`, `target_pointer_width`, `target_thread_local`, `target_vendor`, `test`, `unix`, `windows` = help: to expect this configuration use `--check-cfg=cfg(linux)` = note: see <https://doc.rust-lang.org/nightly/unstable-book/compiler-flags/check-cfg.html> for more information about checking conditional configuration = note: `#[warn(unexpected_cfgs)]` on by default warning: unexpected `cfg` condition name: `linux` --> $DIR/cfg-value-for-cfg-name.rs:14:7 | LL | #[cfg(linux = "os-name")] |       ^^^^^^^^^^^^^^^^^ | = help: to expect this configuration use `--check-cfg=cfg(linux, values("os-name"))` = note: see <https://doc.rust-lang.org/nightly/unstable-book/compiler-flags/check-cfg.html> for more information about checking conditional configuration warning: 2 warnings emitted </ins>


Question:
I tried this code (as package ): Run the following, which will break at , step the next 4 lines () to define the variables, then print twice -- the first time will succeed, the second time will fail: I expected to see this happen: would work the same no matter how many times I called it, instead everything seems to be undefined after the first call. Below I show that seems to work (including multiple times), works (including multiple times), but after a single call to , neither of these works anymore: Oddly, if I break on filename / line number instead of function name, it seems to work as expected: I'm using from a git checkout from yesterday:
Realized was not a but an ; have changed to . Don't think it changes the rest, behavior still the same with .
Works just fine in gdb for me: Rust-lldb doesn't want to load for me at all, but plain lldb works fine too. For reference I'm using lldb version 14.0.6.
If only gdb worked on aarch64-darwin! But thanks for prompting me to try other OS -- I can confirm that I do not see the bug using rust-lldb on x86_64-linux, so this may be isolated to one of darwin / aarch64 / aarch64-darwin. (Still repros for me on aarch64-darwin with lldb 16.0.6.)

type summary add -F lldb_lookup.summary_lookup  -e -x -h "^(core::([a-z_]+::)+)RefMut<.+>$" --category Rust type summary add -F lldb_lookup.summary_lookup  -e -x -h "^(core::([a-z_]+::)+)RefCell<.+>$" --category Rust type summary add -F lldb_lookup.summary_lookup  -e -x -h "^(core::([a-z_]+::)+)NonZero<.+>$" --category Rust <ins> type summary add -F lldb_lookup.summary_lookup  -e -x -h "^core::num::([a-z_]+::)*NonZero.+$" --category Rust type summary add -F lldb_lookup.summary_lookup  -e -x -h "^(std::([a-z_]+::)+)PathBuf$" --category Rust type summary add -F lldb_lookup.summary_lookup  -e -x -h "^&(mut )?(std::([a-z_]+::)+)Path$" --category Rust </ins> type category enable Rust


Question:
I tried this code (as package ): Run the following, which will break at , step the next 4 lines () to define the variables, then print twice -- the first time will succeed, the second time will fail: I expected to see this happen: would work the same no matter how many times I called it, instead everything seems to be undefined after the first call. Below I show that seems to work (including multiple times), works (including multiple times), but after a single call to , neither of these works anymore: Oddly, if I break on filename / line number instead of function name, it seems to work as expected: I'm using from a git checkout from yesterday:
Realized was not a but an ; have changed to . Don't think it changes the rest, behavior still the same with .
Works just fine in gdb for me: Rust-lldb doesn't want to load for me at all, but plain lldb works fine too. For reference I'm using lldb version 14.0.6.
If only gdb worked on aarch64-darwin! But thanks for prompting me to try other OS -- I can confirm that I do not see the bug using rust-lldb on x86_64-linux, so this may be isolated to one of darwin / aarch64 / aarch64-darwin. (Still repros for me on aarch64-darwin with lldb 16.0.6.)

if rust_type == RustType.STD_NONZERO_NUMBER: return StdNonZeroNumberSummaryProvider(valobj, dict) <ins> if rust_type == RustType.STD_PATHBUF: return StdPathBufSummaryProvider(valobj, dict) if rust_type == RustType.STD_PATH: return StdPathSummaryProvider(valobj, dict) </ins> return ""


Question:
I tried this code (as package ): Run the following, which will break at , step the next 4 lines () to define the variables, then print twice -- the first time will succeed, the second time will fail: I expected to see this happen: would work the same no matter how many times I called it, instead everything seems to be undefined after the first call. Below I show that seems to work (including multiple times), works (including multiple times), but after a single call to , neither of these works anymore: Oddly, if I break on filename / line number instead of function name, it seems to work as expected: I'm using from a git checkout from yesterday:
Realized was not a but an ; have changed to . Don't think it changes the rest, behavior still the same with .
Works just fine in gdb for me: Rust-lldb doesn't want to load for me at all, but plain lldb works fine too. For reference I'm using lldb version 14.0.6.
If only gdb worked on aarch64-darwin! But thanks for prompting me to try other OS -- I can confirm that I do not see the bug using rust-lldb on x86_64-linux, so this may be isolated to one of darwin / aarch64 / aarch64-darwin. (Still repros for me on aarch64-darwin with lldb 16.0.6.)

return '"%s"' % data <ins> def StdPathBufSummaryProvider(valobj, dict): # type: (SBValue, dict) -> str # logger = Logger.Logger() # logger >> "[StdPathBufSummaryProvider] for " + str(valobj.GetName()) return StdOsStringSummaryProvider(valobj.GetChildMemberWithName("inner"), dict) def StdPathSummaryProvider(valobj, dict): # type: (SBValue, dict) -> str # logger = Logger.Logger() # logger >> "[StdPathSummaryProvider] for " + str(valobj.GetName()) length = valobj.GetChildMemberWithName("length").GetValueAsUnsigned() if length == 0: return '""' data_ptr = valobj.GetChildMemberWithName("data_ptr") start = data_ptr.GetValueAsUnsigned() error = SBError() process = data_ptr.GetProcess() data = process.ReadMemory(start, length, error) if PY3: try: data = data.decode(encoding='UTF-8') except UnicodeDecodeError: return '%r' % data return '"%s"' % data </ins> class StructSyntheticProvider: """Pretty-printer for structs and struct enum variants"""


Question:
I tried this code (as package ): Run the following, which will break at , step the next 4 lines () to define the variables, then print twice -- the first time will succeed, the second time will fail: I expected to see this happen: would work the same no matter how many times I called it, instead everything seems to be undefined after the first call. Below I show that seems to work (including multiple times), works (including multiple times), but after a single call to , neither of these works anymore: Oddly, if I break on filename / line number instead of function name, it seems to work as expected: I'm using from a git checkout from yesterday:
Realized was not a but an ; have changed to . Don't think it changes the rest, behavior still the same with .
Works just fine in gdb for me: Rust-lldb doesn't want to load for me at all, but plain lldb works fine too. For reference I'm using lldb version 14.0.6.
If only gdb worked on aarch64-darwin! But thanks for prompting me to try other OS -- I can confirm that I do not see the bug using rust-lldb on x86_64-linux, so this may be isolated to one of darwin / aarch64 / aarch64-darwin. (Still repros for me on aarch64-darwin with lldb 16.0.6.)

STD_REF_MUT = "StdRefMut" STD_REF_CELL = "StdRefCell" STD_NONZERO_NUMBER = "StdNonZeroNumber" <ins> STD_PATH = "StdPath" STD_PATHBUF = "StdPathBuf" </ins> STD_STRING_REGEX = re.compile(r"^(alloc::([a-z_]+::)+)String$")


Question:
I tried this code (as package ): Run the following, which will break at , step the next 4 lines () to define the variables, then print twice -- the first time will succeed, the second time will fail: I expected to see this happen: would work the same no matter how many times I called it, instead everything seems to be undefined after the first call. Below I show that seems to work (including multiple times), works (including multiple times), but after a single call to , neither of these works anymore: Oddly, if I break on filename / line number instead of function name, it seems to work as expected: I'm using from a git checkout from yesterday:
Realized was not a but an ; have changed to . Don't think it changes the rest, behavior still the same with .
Works just fine in gdb for me: Rust-lldb doesn't want to load for me at all, but plain lldb works fine too. For reference I'm using lldb version 14.0.6.
If only gdb worked on aarch64-darwin! But thanks for prompting me to try other OS -- I can confirm that I do not see the bug using rust-lldb on x86_64-linux, so this may be isolated to one of darwin / aarch64 / aarch64-darwin. (Still repros for me on aarch64-darwin with lldb 16.0.6.)

STD_REF_MUT_REGEX = re.compile(r"^(core::([a-z_]+::)+)RefMut<.+>$") STD_REF_CELL_REGEX = re.compile(r"^(core::([a-z_]+::)+)RefCell<.+>$") STD_NONZERO_NUMBER_REGEX = re.compile(r"^(core::([a-z_]+::)+)NonZero<.+>$") <ins> STD_PATHBUF_REGEX = re.compile(r"^(std::([a-z_]+::)+)PathBuf$") STD_PATH_REGEX =  re.compile(r"^&(mut )?(std::([a-z_]+::)+)Path$") </ins> TUPLE_ITEM_REGEX = re.compile(r"__d+$")


Question:
I tried this code (as package ): Run the following, which will break at , step the next 4 lines () to define the variables, then print twice -- the first time will succeed, the second time will fail: I expected to see this happen: would work the same no matter how many times I called it, instead everything seems to be undefined after the first call. Below I show that seems to work (including multiple times), works (including multiple times), but after a single call to , neither of these works anymore: Oddly, if I break on filename / line number instead of function name, it seems to work as expected: I'm using from a git checkout from yesterday:
Realized was not a but an ; have changed to . Don't think it changes the rest, behavior still the same with .
Works just fine in gdb for me: Rust-lldb doesn't want to load for me at all, but plain lldb works fine too. For reference I'm using lldb version 14.0.6.
If only gdb worked on aarch64-darwin! But thanks for prompting me to try other OS -- I can confirm that I do not see the bug using rust-lldb on x86_64-linux, so this may be isolated to one of darwin / aarch64 / aarch64-darwin. (Still repros for me on aarch64-darwin with lldb 16.0.6.)

RustType.STD_REF_CELL: STD_REF_CELL_REGEX, RustType.STD_CELL: STD_CELL_REGEX, RustType.STD_NONZERO_NUMBER: STD_NONZERO_NUMBER_REGEX, <ins> RustType.STD_PATHBUF: STD_PATHBUF_REGEX, RustType.STD_PATH: STD_PATH_REGEX, </ins> } def is_tuple_fields(fields):


Question:
I tried this code (as package ): Run the following, which will break at , step the next 4 lines () to define the variables, then print twice -- the first time will succeed, the second time will fail: I expected to see this happen: would work the same no matter how many times I called it, instead everything seems to be undefined after the first call. Below I show that seems to work (including multiple times), works (including multiple times), but after a single call to , neither of these works anymore: Oddly, if I break on filename / line number instead of function name, it seems to work as expected: I'm using from a git checkout from yesterday:
Realized was not a but an ; have changed to . Don't think it changes the rest, behavior still the same with .
Works just fine in gdb for me: Rust-lldb doesn't want to load for me at all, but plain lldb works fine too. For reference I'm using lldb version 14.0.6.
If only gdb worked on aarch64-darwin! But thanks for prompting me to try other OS -- I can confirm that I do not see the bug using rust-lldb on x86_64-linux, so this may be isolated to one of darwin / aarch64 / aarch64-darwin. (Still repros for me on aarch64-darwin with lldb 16.0.6.)

<ins> //@ ignore-gdb //@ compile-flags:-g // === LLDB TESTS ================================================================================= // lldb-command:run // lldb-command:print pathbuf // lldb-check:[...] "/some/path" { inner = "/some/path" { inner = { inner = size=10 { [0] = '/' [1] = 's' [2] = 'o' [3] = 'm' [4] = 'e' [5] = '/' [6] = 'p' [7] = 'a' [8] = 't' [9] = 'h' } } } } // lldb-command:po pathbuf // lldb-check:"/some/path" // lldb-command:print path // lldb-check:[...] "/some/path" { data_ptr = [...] length = 10 } // lldb-command:po path // lldb-check:"/some/path" use std::path::Path; fn main() { let path = Path::new("/some/path"); let pathbuf = path.to_path_buf(); zzz(); // #break } fn zzz() { () } </ins>


Question:
Crates with long type names result in a strange-looking error, see ! I've tested this on Chrome and Firefox, and by building the docs locally from I believe the text is rendering vertically due to long type names like which are auto-generated from OpenAPI. Link to original issue <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The issue is related to the rule which prevents breaking anywhere in the type name. Unfortunately using breaks . We even have a comment about the weird behaviour in the code, not sure how to fix this.
claim

padding: 2px 4px; box-shadow: 0 0 4px var(--main-background-color); } <ins> .item-table > li > .item-name { width: 33%; } .item-table > li > div { padding-bottom: 5px; word-break: break-all; } </ins> } @media print {


Question:
Crates with long type names result in a strange-looking error, see ! I've tested this on Chrome and Firefox, and by building the docs locally from I believe the text is rendering vertically due to long type names like which are auto-generated from OpenAPI. Link to original issue <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The issue is related to the rule which prevents breaking anywhere in the type name. Unfortunately using breaks . We even have a comment about the weird behaviour in the code, not sure how to fix this.
claim

pub type ReallyLongTypeNameLongLongLong = Option<unsafe extern "C" fn(a: *const u8, b: *const u8) -> *const u8>; <ins> /// Short doc. </ins> pub const ReallyLongTypeNameLongLongLongConstBecauseWhyNotAConstRightGigaGigaSupraLong: u32 = 0; /// This also has a really long doccomment. Lorem ipsum dolor sit amet,


Question:
Crates with long type names result in a strange-looking error, see ! I've tested this on Chrome and Firefox, and by building the docs locally from I believe the text is rendering vertically due to long type names like which are auto-generated from OpenAPI. Link to original issue <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The issue is related to the rule which prevents breaking anywhere in the type name. Unfortunately using breaks . We even have a comment about the weird behaviour in the code, not sure how to fix this.
claim

// In the table-ish view on the module index, the name should not be wrapped more than necessary. go-to: "file://" + |DOC_PATH| + "/lib2/too_long/index.html" <del> assert-property: (".item-table .struct", {"offsetWidth": "684"}) </del> <ins> // We'll ensure that items with short documentation have the same width. store-property: ("//*[@class='item-table']//*[@class='struct']/..", {"offsetWidth": offset_width}) assert: |offset_width| == "277" assert-property: ("//*[@class='item-table']//*[@class='constant']/..", {"offsetWidth": |offset_width|}) </ins> // We now make the same check on type declaration... go-to: "file://" + |DOC_PATH| + "/lib2/too_long/type.ReallyLongTypeNameLongLongLong.html"


Question:
<!-- ICE: Rustc '' 'thread 'rustc' panicked at ', 'thread 'rustc' panicked at ' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [livesymbolsandignoredderivedtraits] finding live symbols in crate [checkmod_deathness] checking deathness of variables in top-level module [analysis] running analysis passes on this crate --
Bisects to nightly-2023-06-02 commit[0] 2023-05-31: Auto merge of - oli-obk:valtrees2, r=lcnr commit[1] 2023-05-31: Auto merge of - petrochenkov:strictflavor, r=lqd,wesleywiser commit[2] 2023-06-01: Auto merge of - Urgau:upliftcastreftomut, r=b-naber commit[3] 2023-06-01: Auto merge of - oli-obk:constevalstep_limit, r=fee1-dead commit[4] 2023-06-01: Auto merge of - Dylan-DPC:rollup-93zj7jw, r=Dylan-DPC commit[5] 2023-06-01: Auto merge of - saethlin:enable-sroa, r=oli-obk,scottmcm commit[6] 2023-06-01: Auto merge of - cjgillot:separate-const-switch, r=oli-obk commit[7] 2023-06-01: Auto merge of - Kobzol:try-build-skip-docs, r=mark-simulacrum ERROR: no CI builds available between and within last 167 days
Minimized:
Very likely btw.

self.lookup_and_handle_method(expr.hir_id); } hir::ExprKind::Field(ref lhs, ..) => { <del> self.handle_field_access(lhs, expr.hir_id); </del> <ins> if self.typeck_results().opt_field_index(expr.hir_id).is_some() { self.handle_field_access(lhs, expr.hir_id); } else { self.tcx.dcx().span_delayed_bug(expr.span, "couldn't resolve index for field"); } </ins> } hir::ExprKind::Struct(qpath, fields, _) => { let res = self.typeck_results().qpath_res(qpath, expr.hir_id);


Question:
<!-- ICE: Rustc '' 'thread 'rustc' panicked at ', 'thread 'rustc' panicked at ' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [livesymbolsandignoredderivedtraits] finding live symbols in crate [checkmod_deathness] checking deathness of variables in top-level module [analysis] running analysis passes on this crate --
Bisects to nightly-2023-06-02 commit[0] 2023-05-31: Auto merge of - oli-obk:valtrees2, r=lcnr commit[1] 2023-05-31: Auto merge of - petrochenkov:strictflavor, r=lqd,wesleywiser commit[2] 2023-06-01: Auto merge of - Urgau:upliftcastreftomut, r=b-naber commit[3] 2023-06-01: Auto merge of - oli-obk:constevalstep_limit, r=fee1-dead commit[4] 2023-06-01: Auto merge of - Dylan-DPC:rollup-93zj7jw, r=Dylan-DPC commit[5] 2023-06-01: Auto merge of - saethlin:enable-sroa, r=oli-obk,scottmcm commit[6] 2023-06-01: Auto merge of - cjgillot:separate-const-switch, r=oli-obk commit[7] 2023-06-01: Auto merge of - Kobzol:try-build-skip-docs, r=mark-simulacrum ERROR: no CI builds available between and within last 167 days
Minimized:
Very likely btw.

<ins> // Regression test for issue #120615. fn main() { [(); loop {}].field; //~ ERROR constant evaluation is taking a long time } </ins>


Question:
<!-- ICE: Rustc '' 'thread 'rustc' panicked at ', 'thread 'rustc' panicked at ' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [livesymbolsandignoredderivedtraits] finding live symbols in crate [checkmod_deathness] checking deathness of variables in top-level module [analysis] running analysis passes on this crate --
Bisects to nightly-2023-06-02 commit[0] 2023-05-31: Auto merge of - oli-obk:valtrees2, r=lcnr commit[1] 2023-05-31: Auto merge of - petrochenkov:strictflavor, r=lqd,wesleywiser commit[2] 2023-06-01: Auto merge of - Urgau:upliftcastreftomut, r=b-naber commit[3] 2023-06-01: Auto merge of - oli-obk:constevalstep_limit, r=fee1-dead commit[4] 2023-06-01: Auto merge of - Dylan-DPC:rollup-93zj7jw, r=Dylan-DPC commit[5] 2023-06-01: Auto merge of - saethlin:enable-sroa, r=oli-obk,scottmcm commit[6] 2023-06-01: Auto merge of - cjgillot:separate-const-switch, r=oli-obk commit[7] 2023-06-01: Auto merge of - Kobzol:try-build-skip-docs, r=mark-simulacrum ERROR: no CI builds available between and within last 167 days
Minimized:
Very likely btw.

<ins> error: constant evaluation is taking a long time --> $DIR/field-access-after-const-eval-fail-in-ty.rs:4:10 | LL |     [(); loop {}].field; |          ^^^^^^^ | = note: this lint makes sure the compiler doesn't get stuck due to infinite loops in const eval. If your compilation actually takes a long time, you can safely allow the lint. help: the constant being evaluated --> $DIR/field-access-after-const-eval-fail-in-ty.rs:4:10 | LL |     [(); loop {}].field; |          ^^^^^^^ = note: `#[deny(long_running_const_eval)]` on by default error: aborting due to 1 previous error </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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<summary<strongBacktrace</strong</summary<p</p</details
Regression from
Fixed in

}); } <del> let path = if trees.is_empty() && !prefix.segments.is_empty() { </del> <ins> // Condition should match `build_reduced_graph_for_use_tree`. let path = if trees.is_empty() && !(prefix.segments.is_empty() || prefix.segments.len() == 1 && prefix.segments[0].ident.name == kw::PathRoot) { </ins> // For empty lists we need to lower the prefix so it is checked for things // like stability later. let res = self.lower_import_res(id, span);


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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<summary<strongBacktrace</strong</summary<p</p</details
Regression from
Fixed in

<ins> // check-pass // edition:2015 use {}; use {{}}; use ::{}; use {::{}}; fn main() {} </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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<summary<strongBacktrace</strong</summary<p</p</details
Regression from
Fixed in

<ins> // check-pass // edition:2018 use {}; use {{}}; use ::{}; use {::{}}; fn main() {} </ins>


Question:
<!-- ICE: Rustc '' 'error: internal compiler error: asm const cannot be resolved', 'error: internal compiler error: asm const cannot be resolved' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regression in nightly-2021-12-16 lol commit[0] 2021-12-14: Auto merge of - matthiaskrgr:rollup-hjjyhow, r=matthiaskrgr commit[1] 2021-12-14: Auto merge of - Amanieu:stableasm, r=joshtriplett commit[2] 2021-12-15: Auto merge of - matthiaskrgr:rollup-cw9qolb, r=matthiaskrgr commit[3] 2021-12-15: Auto merge of - matthiaskrgr:rollup-jszf9zp, r=matthiaskrgr commit[4] 2021-12-15: Auto merge of - yaahc:track-caller-result, r=cuviper commit[5] 2021-12-15: Auto merge of - matthiaskrgr:rollup-rhajuvw, r=matthiaskrgr commit[6] 2021-12-15: Auto merge of - matthiaskrgr:rollup-2g082jw, r=matthiaskrgr ERROR: no CI builds available between and within last 167 days ~/vcs/github/rustbisect via v1.78.0-nightly too I would guess ? cc
Doubt it, that's just when the stabilization happened, there's no meaningful changes there
Actually bisects to which support for in .
label +F-asm +A-inline-assembly +F-inline_const -needs-triage
cc
claim

use crate::common; use crate::traits::*; use rustc_hir as hir; <ins> use rustc_middle::mir::interpret::ErrorHandled; </ins> use rustc_middle::mir::mono::MonoItem; use rustc_middle::mir::mono::{Linkage, Visibility}; use rustc_middle::ty;


Question:
<!-- ICE: Rustc '' 'error: internal compiler error: asm const cannot be resolved', 'error: internal compiler error: asm const cannot be resolved' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regression in nightly-2021-12-16 lol commit[0] 2021-12-14: Auto merge of - matthiaskrgr:rollup-hjjyhow, r=matthiaskrgr commit[1] 2021-12-14: Auto merge of - Amanieu:stableasm, r=joshtriplett commit[2] 2021-12-15: Auto merge of - matthiaskrgr:rollup-cw9qolb, r=matthiaskrgr commit[3] 2021-12-15: Auto merge of - matthiaskrgr:rollup-jszf9zp, r=matthiaskrgr commit[4] 2021-12-15: Auto merge of - yaahc:track-caller-result, r=cuviper commit[5] 2021-12-15: Auto merge of - matthiaskrgr:rollup-rhajuvw, r=matthiaskrgr commit[6] 2021-12-15: Auto merge of - matthiaskrgr:rollup-2g082jw, r=matthiaskrgr ERROR: no CI builds available between and within last 167 days ~/vcs/github/rustbisect via v1.78.0-nightly too I would guess ? cc
Doubt it, that's just when the stabilization happened, there's no meaningful changes there
Actually bisects to which support for in .
label +F-asm +A-inline-assembly +F-inline_const -needs-triage
cc
claim

.iter() .map(|(op, op_sp)| match *op { hir::InlineAsmOperand::Const { ref anon_const } => { <del> let const_value = cx .tcx() .const_eval_poly(anon_const.def_id.to_def_id()) .unwrap_or_else(|_| { span_bug!(*op_sp, "asm const cannot be resolved") }); let ty = cx .tcx() .typeck_body(anon_const.body) .node_type(anon_const.hir_id); let string = common::asm_const_to_str( cx.tcx(), *op_sp, const_value, cx.layout_of(ty), ); GlobalAsmOperandRef::Const { string } </del> <ins> match cx.tcx().const_eval_poly(anon_const.def_id.to_def_id()) { Ok(const_value) => { let ty = cx .tcx() .typeck_body(anon_const.body) .node_type(anon_const.hir_id); let string = common::asm_const_to_str( cx.tcx(), *op_sp, const_value, cx.layout_of(ty), ); GlobalAsmOperandRef::Const { string } } Err(ErrorHandled::Reported { .. }) => { // An error has already been reported and // compilation is guaranteed to fail if execution // hits this path. So an empty string instead of // a stringified constant value will suffice. GlobalAsmOperandRef::Const { string: String::new() } } Err(ErrorHandled::TooGeneric(_)) => { span_bug!( *op_sp, "asm const cannot be resolved; too generic" ) } } </ins> } hir::InlineAsmOperand::SymFn { ref anon_const } => { let ty = cx


Question:
<!-- ICE: Rustc '' 'error: internal compiler error: asm const cannot be resolved', 'error: internal compiler error: asm const cannot be resolved' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regression in nightly-2021-12-16 lol commit[0] 2021-12-14: Auto merge of - matthiaskrgr:rollup-hjjyhow, r=matthiaskrgr commit[1] 2021-12-14: Auto merge of - Amanieu:stableasm, r=joshtriplett commit[2] 2021-12-15: Auto merge of - matthiaskrgr:rollup-cw9qolb, r=matthiaskrgr commit[3] 2021-12-15: Auto merge of - matthiaskrgr:rollup-jszf9zp, r=matthiaskrgr commit[4] 2021-12-15: Auto merge of - yaahc:track-caller-result, r=cuviper commit[5] 2021-12-15: Auto merge of - matthiaskrgr:rollup-rhajuvw, r=matthiaskrgr commit[6] 2021-12-15: Auto merge of - matthiaskrgr:rollup-2g082jw, r=matthiaskrgr ERROR: no CI builds available between and within last 167 days ~/vcs/github/rustbisect via v1.78.0-nightly too I would guess ? cc
Doubt it, that's just when the stabilization happened, there's no meaningful changes there
Actually bisects to which support for in .
label +F-asm +A-inline-assembly +F-inline_const -needs-triage
cc
claim

<ins> //@ build-fail //@ needs-asm-support #![feature(asm_const)] use std::arch::global_asm; fn main() {} global_asm!("/* {} */", const 1 << 500); //~ ERROR evaluation of constant value failed [E0080] global_asm!("/* {} */", const 1 / 0); //~ ERROR evaluation of constant value failed [E0080] </ins>


Question:
<!-- ICE: Rustc '' 'error: internal compiler error: asm const cannot be resolved', 'error: internal compiler error: asm const cannot be resolved' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regression in nightly-2021-12-16 lol commit[0] 2021-12-14: Auto merge of - matthiaskrgr:rollup-hjjyhow, r=matthiaskrgr commit[1] 2021-12-14: Auto merge of - Amanieu:stableasm, r=joshtriplett commit[2] 2021-12-15: Auto merge of - matthiaskrgr:rollup-cw9qolb, r=matthiaskrgr commit[3] 2021-12-15: Auto merge of - matthiaskrgr:rollup-jszf9zp, r=matthiaskrgr commit[4] 2021-12-15: Auto merge of - yaahc:track-caller-result, r=cuviper commit[5] 2021-12-15: Auto merge of - matthiaskrgr:rollup-rhajuvw, r=matthiaskrgr commit[6] 2021-12-15: Auto merge of - matthiaskrgr:rollup-2g082jw, r=matthiaskrgr ERROR: no CI builds available between and within last 167 days ~/vcs/github/rustbisect via v1.78.0-nightly too I would guess ? cc
Doubt it, that's just when the stabilization happened, there's no meaningful changes there
Actually bisects to which support for in .
label +F-asm +A-inline-assembly +F-inline_const -needs-triage
cc
claim

<ins> error[E0080]: evaluation of constant value failed --> $DIR/fail-const-eval-issue-121099.rs:9:31 | LL | global_asm!("/* {} */", const 1 << 500); |                               ^^^^^^^^ attempt to shift left by `500_i32`, which would overflow error[E0080]: evaluation of constant value failed --> $DIR/fail-const-eval-issue-121099.rs:11:31 | LL | global_asm!("/* {} */", const 1 / 0); |                               ^^^^^ attempt to divide `1_i32` by zero error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0080`. </ins>


Question:
<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed: value <= 0xFFFFFF00'', 'thread 'rustc' panicked at 'assertion failed: value <= 0xFFFFFF00'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [mirdropselaboratedandconst_checked] elaborating drops for [analysis] running analysis passes on this crate --
cc
I cannot reproduce this with a local stage 1 build nightly and beta show this tho...
maybe this is a rustc miscompile? cc
I can reproduce this on aarch64-apple-darwin, and on beta.
The calls to seem bogus because index is potentially out of range (the valid range is restricted further in comparison to u32):
WG-prioritization assigning priority (). label -I-prioritize +P-medium

} (PlaceElem::Index(idx), Value::Aggregate { fields, .. }) => { let idx = prop.get_const(idx.into())?.immediate()?; <del> let idx = prop.ecx.read_target_usize(idx).ok()?; fields.get(FieldIdx::from_u32(idx.try_into().ok()?)).unwrap_or(&Value::Uninit) </del> <ins> let idx = prop.ecx.read_target_usize(idx).ok()?.try_into().ok()?; if idx <= FieldIdx::MAX_AS_U32 { fields.get(FieldIdx::from_u32(idx)).unwrap_or(&Value::Uninit) } else { return None; } </ins> } ( PlaceElem::ConstantIndex { offset, min_length: _, from_end: false },


Question:
<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed: value <= 0xFFFFFF00'', 'thread 'rustc' panicked at 'assertion failed: value <= 0xFFFFFF00'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [mirdropselaboratedandconst_checked] elaborating drops for [analysis] running analysis passes on this crate --
cc
I cannot reproduce this with a local stage 1 build nightly and beta show this tho...
maybe this is a rustc miscompile? cc
I can reproduce this on aarch64-apple-darwin, and on beta.
The calls to seem bogus because index is potentially out of range (the valid range is restricted further in comparison to u32):
WG-prioritization assigning priority (). label -I-prioritize +P-medium

<del> //@ known-bug: #121126 fn main() { let _n = 1i64 >> [64][4_294_967_295]; } </del>


Question:
<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed: value <= 0xFFFFFF00'', 'thread 'rustc' panicked at 'assertion failed: value <= 0xFFFFFF00'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [mirdropselaboratedandconst_checked] elaborating drops for [analysis] running analysis passes on this crate --
cc
I cannot reproduce this with a local stage 1 build nightly and beta show this tho...
maybe this is a rustc miscompile? cc
I can reproduce this on aarch64-apple-darwin, and on beta.
The calls to seem bogus because index is potentially out of range (the valid range is restricted further in comparison to u32):
WG-prioritization assigning priority (). label -I-prioritize +P-medium

<ins> //@ build-fail fn main() { let _n = [64][200]; //~^ ERROR this operation will panic at runtime [unconditional_panic] // issue #121126, test index value between 0xFFFF_FF00 and u32::MAX let _n = [64][u32::MAX as usize - 1]; //~^ ERROR this operation will panic at runtime [unconditional_panic] } </ins>


Question:
<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed: value <= 0xFFFFFF00'', 'thread 'rustc' panicked at 'assertion failed: value <= 0xFFFFFF00'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [mirdropselaboratedandconst_checked] elaborating drops for [analysis] running analysis passes on this crate --
cc
I cannot reproduce this with a local stage 1 build nightly and beta show this tho...
maybe this is a rustc miscompile? cc
I can reproduce this on aarch64-apple-darwin, and on beta.
The calls to seem bogus because index is potentially out of range (the valid range is restricted further in comparison to u32):
WG-prioritization assigning priority (). label -I-prioritize +P-medium

<ins> error: this operation will panic at runtime --> $DIR/index-bounds.rs:4:14 | LL |     let _n = [64][200]; |              ^^^^^^^^^ index out of bounds: the length is 1 but the index is 200 | = note: `#[deny(unconditional_panic)]` on by default error: this operation will panic at runtime --> $DIR/index-bounds.rs:8:14 | LL |     let _n = [64][u32::MAX as usize - 1]; |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^ index out of bounds: the length is 1 but the index is 4294967294 error: aborting due to 2 previous errors </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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<summary<strongBacktrace</strong</summary<p</p</details
I suspect this is related to cc
tests/ui/suggestions/unnamable-
Very likely. I'll take a look soon.
For the record: it was that caused this.

fn parse_crate_mod(&mut self) -> Result<ast::Crate, ParserError> { let mut parser = AssertUnwindSafe(&mut self.parser); <del> match catch_unwind(move || parser.parse_crate_mod()) { Ok(Ok(k)) => Ok(k), Ok(Err(db)) => { </del> <ins> // rustfmt doesn't use `run_compiler` like other tools, so it must emit // any stashed diagnostics itself, otherwise the `DiagCtxt` will assert // when dropped. The final result here combines the parsing result and // the `emit_stashed_diagnostics` result. let parse_res = catch_unwind(move || parser.parse_crate_mod()); let stashed_res = self.parser.dcx().emit_stashed_diagnostics(); let err = Err(ParserError::ParsePanicError); match (parse_res, stashed_res) { (Ok(Ok(k)), None) => Ok(k), (Ok(Ok(_)), Some(_guar)) => err, (Ok(Err(db)), _) => { </ins> db.emit(); <del> Err(ParserError::ParseError) </del> <ins> err </ins> } <del> Err(_) => Err(ParserError::ParsePanicError), </del> <ins> (Err(_), _) => err, </ins> } } }


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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<summary<strongBacktrace</strong</summary<p</p</details
I suspect this is related to cc
tests/ui/suggestions/unnamable-
Very likely. I'll take a look soon.
For the record: it was that caused this.

let filename = "tests/parser/unclosed-delims/issue_4466.rs"; assert_parser_error(filename); } <ins> #[test] fn crate_parsing_stashed_diag() { // See also https://github.com/rust-lang/rust/issues/121450 let filename = "tests/parser/stashed-diag.rs"; assert_parser_error(filename); } </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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<summary<strongBacktrace</strong</summary<p</p</details
I suspect this is related to cc
tests/ui/suggestions/unnamable-
Very likely. I'll take a look soon.
For the record: it was that caused this.

<ins> #![u={static N;}] fn main() {} </ins>


Question:
When running , this file is opened for me . I thought I'd use that file in my note taking application, which I have set to a dark theme. However for in that documentation is set to have the and the background uses the default color. This leads to the text becoming hard to read. ! I would prefer the text color not to be explicitly set, or if you insist on the dark gray text, making sure that the background color is also set to something light.
Transferred to rust-lang/rust. The CSS for this lives at
It's not rustdoc so to speak. I'll fix the issue.

margin: 0 auto; padding: 0 15px; font-size: 18px; <del> color: #333; </del> <ins> color: #000; </ins> line-height: 1.428571429; -webkit-box-sizing: unset; -moz-box-sizing: unset; box-sizing: unset; <ins> background: #fff; </ins> } @media (min-width: 768px) { body {


Question:
When running , this file is opened for me . I thought I'd use that file in my note taking application, which I have set to a dark theme. However for in that documentation is set to have the and the background uses the default color. This leads to the text becoming hard to read. ! I would prefer the text color not to be explicitly set, or if you insist on the dark gray text, making sure that the background color is also set to something light.
Transferred to rust-lang/rust. The CSS for this lives at
It's not rustdoc so to speak. I'll fix the issue.

padding: 5px 10px; } h5, h6 { <del> color: black; </del> text-decoration: underline; }


Question:
I tried this code: I expected to see this happen: Both and can be inlined. Instead, this happened: <details<summarycargo asm</summary</detailsWhen using , it works well. Also, when I replace with , it works well. <details<summarycargo asm</summary</details:
I think this is an llvm issue related to inlining when the target features do not match exactly and when using inline assembly: is implemented using asm and has . This seems to prevent it getting inlined into functions with additional target features. When compiling for a specific target with all these features enabled it should get inlined, but this restriction makes it very difficult to implement runtime dispatch and get performant code. I'm currently facing the same issue, and plan to replace the asm implementation with one that uses the new rust intrinsic, but this only solves the problem for masked loads/stores. The problem also exists for the implementations of , for which there is not yet a rust intrinsic.

<del> Subproject commit 7973f3560287d750500718314a0fd4025bd8ac0e </del> <ins> Subproject commit 84f190a4abf58bbd5301c0fc831f7a96acea246f </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --from Rustc will crash "normally" (expected as the bug is not fixed) but when trying to print the query stack, rustc will eat up all available memory which is BAD. <!-- 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<summary<strongBacktrace</strong</summary<p</p</details
Its very likely hat this was caused by cc
This looks like again. It was fixed in , but the doesn't actually test what it's supposed to, because it doesn't check for the "end of query stack" line. (This also means that we currently have an UI that will fill up your entire RAM and then get killed.) The / calls are needed to fix this, not sure why they got removed.
WG-prioritization assigning priority (). label -I-prioritize +P-critical

use rustc_middle::query::on_disk_cache::AbsoluteBytePos; use rustc_middle::query::on_disk_cache::{CacheDecoder, CacheEncoder, EncodedDepNodeIndex}; use rustc_middle::query::Key; <ins> use rustc_middle::ty::print::with_reduced_queries; </ins> use rustc_middle::ty::tls::{self, ImplicitCtxt}; use rustc_middle::ty::{self, TyCtxt}; use rustc_query_system::dep_graph::{DepNodeParams, HasDepContext};


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --from Rustc will crash "normally" (expected as the bug is not fixed) but when trying to print the query stack, rustc will eat up all available memory which is BAD. <!-- 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<summary<strongBacktrace</strong</summary<p</p</details
Its very likely hat this was caused by cc
This looks like again. It was fixed in , but the doesn't actually test what it's supposed to, because it doesn't check for the "end of query stack" line. (This also means that we currently have an UI that will fill up your entire RAM and then get killed.) The / calls are needed to fix this, not sure why they got removed.
WG-prioritization assigning priority (). label -I-prioritize +P-critical

kind: DepKind, name: &'static str, ) -> QueryStackFrame { <ins> // If reduced queries are requested, we may be printing a query stack due // to a panic. Avoid using `default_span` and `def_kind` in that case. let reduce_queries = with_reduced_queries(); </ins> // Avoid calling queries while formatting the description let description = ty::print::with_no_queries!(do_describe(tcx, key)); let description = if tcx.sess.verbose_internals() {


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --from Rustc will crash "normally" (expected as the bug is not fixed) but when trying to print the query stack, rustc will eat up all available memory which is BAD. <!-- 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<summary<strongBacktrace</strong</summary<p</p</details
Its very likely hat this was caused by cc
This looks like again. It was fixed in , but the doesn't actually test what it's supposed to, because it doesn't check for the "end of query stack" line. (This also means that we currently have an UI that will fill up your entire RAM and then get killed.) The / calls are needed to fix this, not sure why they got removed.
WG-prioritization assigning priority (). label -I-prioritize +P-critical

} else { description }; <del> let span = if kind == dep_graph::dep_kinds::def_span { </del> <ins> let span = if kind == dep_graph::dep_kinds::def_span || reduce_queries { </ins> // The `def_span` query is used to calculate `default_span`, // so exit to avoid infinite recursion. None