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

Some(key.default_span(tcx)) }; let def_id = key.key_as_def_id(); <del> let def_kind = if kind == dep_graph::dep_kinds::def_kind { </del> <ins> let def_kind = if kind == dep_graph::dep_kinds::def_kind || reduce_queries { </ins> // Try to avoid infinite recursion. None } else {


Question:
The documentation for these methods state respectively: However these clearly return pointers rather than references. Later on they state the following restrictions, which make sense for references but it isn't clear to me that this restriction is necessary for pointers. At the very least the change needs to be made there too.
These are nightly-only traits that aren't particularly on-track for stabilization anytime soon, but yes, changing them to be correct on those counts would be fine.
Indeed, while it's nightly only I wasn't actually going to call it from nightly, but was looking because of it's use in other stable functions, e.g. . Would make a patch, but I wasn't sure whether to leave the undefined behavior line in or whether it should be removed.
It's still UB, yeah! This is partly because it still has to fulfill the safety conditions of . Obviously, that isn't a full justification: there is the question of adding until the pointer is offset to the "last element", which would not trigger "language UB" via that implementation detail... But the library defines it as UB, which means the implementation may include code that would cause an optimizer to see that it is "impossible" for the defined-UB result to happen. And the question of whether the "surface functions" have this obligation was settled in so yes, the same conclusion applies.

#[unstable(feature = "slice_index_methods", issue = "none")] fn get_mut(self, slice: &mut T) -> Option<&mut Self::Output>; <del> /// Returns a shared reference to the output at this location, without </del> <ins> /// Returns a pointer to the output at this location, without </ins> /// performing any bounds checking. /// Calling this method with an out-of-bounds index or a dangling `slice` pointer <del> /// is *[undefined behavior]* even if the resulting reference is not used. </del> <ins> /// is *[undefined behavior]* even if the resulting pointer is not used. </ins> /// /// [undefined behavior]: https://doc.rust-lang.org/reference/behavior-considered-undefined.html #[unstable(feature = "slice_index_methods", issue = "none")] unsafe fn get_unchecked(self, slice: *const T) -> *const Self::Output; <del> /// Returns a mutable reference to the output at this location, without </del> <ins> /// Returns a mutable pointer to the output at this location, without </ins> /// performing any bounds checking. /// Calling this method with an out-of-bounds index or a dangling `slice` pointer <del> /// is *[undefined behavior]* even if the resulting reference is not used. </del> <ins> /// is *[undefined behavior]* even if the resulting pointer is not used. </ins> /// /// [undefined behavior]: https://doc.rust-lang.org/reference/behavior-considered-undefined.html #[unstable(feature = "slice_index_methods", issue = "none")]


Question:
The following are some unexpected behaviors I see with the formatting strings in the attribute. I'm not sure that the attribute should actually be using std's format parsing, but if it is, the following seem like issues with the current implementation. Anything after the is ignored, and not included in the message output. Expectation: There should be a warning that the string is malformed. or These generate an error. However, my understanding of the attribute is that it tries to only generate warnings for things it doesn't understand. I would expect this to also generate a warning. This does not generate a warning or error. I would expect it to generate a warning that anything after the is ignored. This includes width, precision, debug formatting, etc. The error message generated with this is the type followed by a . I would expect this to generate a warning that the format arguments are not valid (similar to how works). : cc
I filled to hopefully address this.
Good catch! This should probably support a strict subset of formatting (only named arguments and no format options), and warn whenever the string is either not valid for or not in the supported subset. When it shows a warning, not sure what the behavior of the string should be -- maybe just take it as a literal without any interpolation?

trait_selection_closure_kind_requirement = the requirement to implement `{$trait_prefix}{$expected}` derives from here <ins> trait_selection_disallowed_positional_argument = positional format arguments are not allowed here .help = only named format arguments with the name of one of the generic types are allowed in this context </ins> trait_selection_dump_vtable_entries = vtable entries for `{$trait_ref}`: {$entries} trait_selection_empty_on_clause_in_rustc_on_unimplemented = empty `on`-clause in `#[rustc_on_unimplemented]`


Question:
The following are some unexpected behaviors I see with the formatting strings in the attribute. I'm not sure that the attribute should actually be using std's format parsing, but if it is, the following seem like issues with the current implementation. Anything after the is ignored, and not included in the message output. Expectation: There should be a warning that the string is malformed. or These generate an error. However, my understanding of the attribute is that it tries to only generate warnings for things it doesn't understand. I would expect this to also generate a warning. This does not generate a warning or error. I would expect it to generate a warning that anything after the is ignored. This includes width, precision, debug formatting, etc. The error message generated with this is the type followed by a . I would expect this to generate a warning that the format arguments are not valid (similar to how works). : cc
I filled to hopefully address this.
Good catch! This should probably support a strict subset of formatting (only named arguments and no format options), and warn whenever the string is either not valid for or not in the supported subset. When it shows a warning, not sure what the behavior of the string should be -- maybe just take it as a literal without any interpolation?

trait_selection_inherent_projection_normalization_overflow = overflow evaluating associated type `{$ty}` <ins> trait_selection_invalid_format_specifier = invalid format specifier .help = no format specifier are supported in this position </ins> trait_selection_invalid_on_clause_in_rustc_on_unimplemented = invalid `on`-clause in `#[rustc_on_unimplemented]` .label = invalid on-clause here


Question:
The following are some unexpected behaviors I see with the formatting strings in the attribute. I'm not sure that the attribute should actually be using std's format parsing, but if it is, the following seem like issues with the current implementation. Anything after the is ignored, and not included in the message output. Expectation: There should be a warning that the string is malformed. or These generate an error. However, my understanding of the attribute is that it tries to only generate warnings for things it doesn't understand. I would expect this to also generate a warning. This does not generate a warning or error. I would expect it to generate a warning that anything after the is ignored. This includes width, precision, debug formatting, etc. The error message generated with this is the type followed by a . I would expect this to generate a warning that the format arguments are not valid (similar to how works). : cc
I filled to hopefully address this.
Good catch! This should probably support a strict subset of formatting (only named arguments and no format options), and warn whenever the string is either not valid for or not in the supported subset. When it shows a warning, not sure what the behavior of the string should be -- maybe just take it as a literal without any interpolation?

trait_selection_unknown_format_parameter_for_on_unimplemented_attr = there is no parameter `{$argument_name}` on trait `{$trait_name}` .help = expect either a generic argument name or {"`{Self}`"} as format argument <ins> trait_selection_wrapped_parser_error = {$description} .label = {$label} </ins>


Question:
The following are some unexpected behaviors I see with the formatting strings in the attribute. I'm not sure that the attribute should actually be using std's format parsing, but if it is, the following seem like issues with the current implementation. Anything after the is ignored, and not included in the message output. Expectation: There should be a warning that the string is malformed. or These generate an error. However, my understanding of the attribute is that it tries to only generate warnings for things it doesn't understand. I would expect this to also generate a warning. This does not generate a warning or error. I would expect it to generate a warning that anything after the is ignored. This includes width, precision, debug formatting, etc. The error message generated with this is the type followed by a . I would expect this to generate a warning that the format arguments are not valid (similar to how works). : cc
I filled to hopefully address this.
Good catch! This should probably support a strict subset of formatting (only named arguments and no format options), and warn whenever the string is either not valid for or not in the supported subset. When it shows a warning, not sure what the behavior of the string should be -- maybe just take it as a literal without any interpolation?

trait_name: Symbol, } <ins> #[derive(LintDiagnostic)] #[diag(trait_selection_disallowed_positional_argument)] #[help] pub struct DisallowedPositionalArgument; #[derive(LintDiagnostic)] #[diag(trait_selection_invalid_format_specifier)] #[help] pub struct InvalidFormatSpecifier; #[derive(LintDiagnostic)] #[diag(trait_selection_wrapped_parser_error)] pub struct WrappedParserError { description: String, label: String, } </ins> impl<'tcx> OnUnimplementedDirective { fn parse( tcx: TyCtxt<'tcx>,


Question:
The following are some unexpected behaviors I see with the formatting strings in the attribute. I'm not sure that the attribute should actually be using std's format parsing, but if it is, the following seem like issues with the current implementation. Anything after the is ignored, and not included in the message output. Expectation: There should be a warning that the string is malformed. or These generate an error. However, my understanding of the attribute is that it tries to only generate warnings for things it doesn't understand. I would expect this to also generate a warning. This does not generate a warning or error. I would expect it to generate a warning that anything after the is ignored. This includes width, precision, debug formatting, etc. The error message generated with this is the type followed by a . I would expect this to generate a warning that the format arguments are not valid (similar to how works). : cc
I filled to hopefully address this.
Good catch! This should probably support a strict subset of formatting (only named arguments and no format options), and warn whenever the string is either not valid for or not in the supported subset. When it shows a warning, not sure what the behavior of the string should be -- maybe just take it as a literal without any interpolation?

let trait_name = tcx.item_name(trait_def_id); let generics = tcx.generics_of(item_def_id); let s = self.symbol.as_str(); <del> let parser = Parser::new(s, None, None, false, ParseMode::Format); </del> <ins> let mut parser = Parser::new(s, None, None, false, ParseMode::Format); </ins> let mut result = Ok(()); <del> for token in parser { </del> <ins> for token in &mut parser { </ins> match token { Piece::String(_) => (), // Normal string, no need to check it <del> Piece::NextArgument(a) => match a.position { Position::ArgumentNamed(s) => { match Symbol::intern(s) { // `{ThisTraitsName}` is allowed s if s == trait_name && !self.is_diagnostic_namespace_variant => (), s if ALLOWED_FORMAT_SYMBOLS.contains(&s) && !self.is_diagnostic_namespace_variant => { () } // So is `{A}` if A is a type parameter s if generics.params.iter().any(|param| param.name == s) => (), s => { if self.is_diagnostic_namespace_variant { tcx.emit_node_span_lint( UNKNOWN_OR_MALFORMED_DIAGNOSTIC_ATTRIBUTES, tcx.local_def_id_to_hir_id(item_def_id.expect_local()), self.span, UnknownFormatParameterForOnUnimplementedAttr { argument_name: s, trait_name, }, ); } else { result = Err(struct_span_code_err!( tcx.dcx(), self.span, E0230, "there is no parameter `{}` on {}", s, if trait_def_id == item_def_id { format!("trait `{trait_name}`") } else { "impl".to_string() } ) .emit()); </del> <ins> Piece::NextArgument(a) => { let format_spec = a.format; if self.is_diagnostic_namespace_variant && (format_spec.ty_span.is_some() || format_spec.width_span.is_some() || format_spec.precision_span.is_some() || format_spec.fill_span.is_some()) { tcx.emit_node_span_lint( UNKNOWN_OR_MALFORMED_DIAGNOSTIC_ATTRIBUTES, tcx.local_def_id_to_hir_id(item_def_id.expect_local()), self.span, InvalidFormatSpecifier, ); } match a.position { Position::ArgumentNamed(s) => { match Symbol::intern(s) { // `{ThisTraitsName}` is allowed s if s == trait_name && !self.is_diagnostic_namespace_variant => (), s if ALLOWED_FORMAT_SYMBOLS.contains(&s) && !self.is_diagnostic_namespace_variant => { () } // So is `{A}` if A is a type parameter s if generics.params.iter().any(|param| param.name == s) => (), s => { if self.is_diagnostic_namespace_variant { tcx.emit_node_span_lint( UNKNOWN_OR_MALFORMED_DIAGNOSTIC_ATTRIBUTES, tcx.local_def_id_to_hir_id(item_def_id.expect_local()), self.span, UnknownFormatParameterForOnUnimplementedAttr { argument_name: s, trait_name, }, ); } else { result = Err(struct_span_code_err!( tcx.dcx(), self.span, E0230, "there is no parameter `{}` on {}", s, if trait_def_id == item_def_id { format!("trait `{trait_name}`") } else { "impl".to_string() } ) .emit()); } </ins> } } } <ins> // `{:1}` and `{}` are not to be used Position::ArgumentIs(..) | Position::ArgumentImplicitlyIs(_) => { if self.is_diagnostic_namespace_variant { tcx.emit_node_span_lint( UNKNOWN_OR_MALFORMED_DIAGNOSTIC_ATTRIBUTES, tcx.local_def_id_to_hir_id(item_def_id.expect_local()), self.span, DisallowedPositionalArgument, ); } else { let reported = struct_span_code_err!( tcx.dcx(), self.span, E0231, "only named generic parameters are allowed" ) .emit(); result = Err(reported); } } </ins> } <del> // `{:1}` and `{}` are not to be used Position::ArgumentIs(..) | Position::ArgumentImplicitlyIs(_) => { let reported = struct_span_code_err!( tcx.dcx(), self.span, E0231, "only named generic parameters are allowed" ) .emit(); result = Err(reported); } }, </del> <ins> } } } // we cannot return errors from processing the format string as hard error here // as the diagnostic namespace gurantees that malformed input cannot cause an error // // if we encounter any error while processing we nevertheless want to show it as warning // so that users are aware that something is not correct for e in parser.errors { if self.is_diagnostic_namespace_variant { tcx.emit_node_span_lint( UNKNOWN_OR_MALFORMED_DIAGNOSTIC_ATTRIBUTES, tcx.local_def_id_to_hir_id(item_def_id.expect_local()), self.span, WrappedParserError { description: e.description, label: e.label }, ); } else { let reported = struct_span_code_err!(tcx.dcx(), self.span, E0231, "{}", e.description,).emit(); result = Err(reported); </ins> } }


Question:
The following are some unexpected behaviors I see with the formatting strings in the attribute. I'm not sure that the attribute should actually be using std's format parsing, but if it is, the following seem like issues with the current implementation. Anything after the is ignored, and not included in the message output. Expectation: There should be a warning that the string is malformed. or These generate an error. However, my understanding of the attribute is that it tries to only generate warnings for things it doesn't understand. I would expect this to also generate a warning. This does not generate a warning or error. I would expect it to generate a warning that anything after the is ignored. This includes width, precision, debug formatting, etc. The error message generated with this is the type followed by a . I would expect this to generate a warning that the format arguments are not valid (similar to how works). : cc
I filled to hopefully address this.
Good catch! This should probably support a strict subset of formatting (only named arguments and no format options), and warn whenever the string is either not valid for or not in the supported subset. When it shows a warning, not sure what the behavior of the string should be -- maybe just take it as a literal without any interpolation?

let empty_string = String::new(); let s = self.symbol.as_str(); <del> let parser = Parser::new(s, None, None, false, ParseMode::Format); </del> <ins> let mut parser = Parser::new(s, None, None, false, ParseMode::Format); </ins> let item_context = (options.get(&sym::ItemContext)).unwrap_or(&empty_string); <del> parser </del> <ins> let constructed_message = (&mut parser) </ins> .map(|p| match p { Piece::String(s) => s.to_owned(), Piece::NextArgument(a) => match a.position {


Question:
The following are some unexpected behaviors I see with the formatting strings in the attribute. I'm not sure that the attribute should actually be using std's format parsing, but if it is, the following seem like issues with the current implementation. Anything after the is ignored, and not included in the message output. Expectation: There should be a warning that the string is malformed. or These generate an error. However, my understanding of the attribute is that it tries to only generate warnings for things it doesn't understand. I would expect this to also generate a warning. This does not generate a warning or error. I would expect it to generate a warning that anything after the is ignored. This includes width, precision, debug formatting, etc. The error message generated with this is the type followed by a . I would expect this to generate a warning that the format arguments are not valid (similar to how works). : cc
I filled to hopefully address this.
Good catch! This should probably support a strict subset of formatting (only named arguments and no format options), and warn whenever the string is either not valid for or not in the supported subset. When it shows a warning, not sure what the behavior of the string should be -- maybe just take it as a literal without any interpolation?

} } } <ins> Position::ArgumentImplicitlyIs(_) if self.is_diagnostic_namespace_variant => { String::from("{}") } Position::ArgumentIs(idx) if self.is_diagnostic_namespace_variant => { format!("{{{idx}}}") } </ins> _ => bug!("broken on_unimplemented {:?} - bad format arg", self.symbol), }, }) <del> .collect() </del> <ins> .collect(); // we cannot return errors from processing the format string as hard error here // as the diagnostic namespace gurantees that malformed input cannot cause an error // // if we encounter any error while processing the format string // we don't want to show the potentially half assembled formated string, // therefore we fall back to just showing the input string in this case // // The actual parser errors are emitted earlier // as lint warnings in OnUnimplementedFormatString::verify if self.is_diagnostic_namespace_variant && !parser.errors.is_empty() { String::from(s) } else { constructed_message } </ins> } }


Question:
The following are some unexpected behaviors I see with the formatting strings in the attribute. I'm not sure that the attribute should actually be using std's format parsing, but if it is, the following seem like issues with the current implementation. Anything after the is ignored, and not included in the message output. Expectation: There should be a warning that the string is malformed. or These generate an error. However, my understanding of the attribute is that it tries to only generate warnings for things it doesn't understand. I would expect this to also generate a warning. This does not generate a warning or error. I would expect it to generate a warning that anything after the is ignored. This includes width, precision, debug formatting, etc. The error message generated with this is the type followed by a . I would expect this to generate a warning that the format arguments are not valid (similar to how works). : cc
I filled to hopefully address this.
Good catch! This should probably support a strict subset of formatting (only named arguments and no format options), and warn whenever the string is either not valid for or not in the supported subset. When it shows a warning, not sure what the behavior of the string should be -- maybe just take it as a literal without any interpolation?

<ins> #[diagnostic::on_unimplemented(message = "{{Test } thing")] //~^WARN unmatched `}` found //~|WARN unmatched `}` found trait ImportantTrait1 {} #[diagnostic::on_unimplemented(message = "Test {}")] //~^WARN positional format arguments are not allowed here //~|WARN positional format arguments are not allowed here trait ImportantTrait2 {} #[diagnostic::on_unimplemented(message = "Test {1:}")] //~^WARN positional format arguments are not allowed here //~|WARN positional format arguments are not allowed here trait ImportantTrait3 {} #[diagnostic::on_unimplemented(message = "Test {Self:123}")] //~^WARN invalid format specifier //~|WARN invalid format specifier trait ImportantTrait4 {} #[diagnostic::on_unimplemented(message = "Test {Self:!}")] //~^WARN expected `'}'`, found `'!'` //~|WARN expected `'}'`, found `'!'` //~|WARN unmatched `}` found //~|WARN unmatched `}` found trait ImportantTrait5 {} fn check_1(_: impl ImportantTrait1) {} fn check_2(_: impl ImportantTrait2) {} fn check_3(_: impl ImportantTrait3) {} fn check_4(_: impl ImportantTrait4) {} fn check_5(_: impl ImportantTrait5) {} fn main() { check_1(()); //~^ERROR {{Test } thing check_2(()); //~^ERROR Test {} check_3(()); //~^ERROR Test {1} check_4(()); //~^ERROR Test () check_5(()); //~^ERROR Test {Self:!} } </ins>


Question:
The following are some unexpected behaviors I see with the formatting strings in the attribute. I'm not sure that the attribute should actually be using std's format parsing, but if it is, the following seem like issues with the current implementation. Anything after the is ignored, and not included in the message output. Expectation: There should be a warning that the string is malformed. or These generate an error. However, my understanding of the attribute is that it tries to only generate warnings for things it doesn't understand. I would expect this to also generate a warning. This does not generate a warning or error. I would expect it to generate a warning that anything after the is ignored. This includes width, precision, debug formatting, etc. The error message generated with this is the type followed by a . I would expect this to generate a warning that the format arguments are not valid (similar to how works). : cc
I filled to hopefully address this.
Good catch! This should probably support a strict subset of formatting (only named arguments and no format options), and warn whenever the string is either not valid for or not in the supported subset. When it shows a warning, not sure what the behavior of the string should be -- maybe just take it as a literal without any interpolation?

<ins> warning: unmatched `}` found --> $DIR/broken_format.rs:1:32 | LL | #[diagnostic::on_unimplemented(message = "{{Test } thing")] |                                ^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: `#[warn(unknown_or_malformed_diagnostic_attributes)]` on by default warning: positional format arguments are not allowed here --> $DIR/broken_format.rs:6:32 | LL | #[diagnostic::on_unimplemented(message = "Test {}")] |                                ^^^^^^^^^^^^^^^^^^^ | = help: only named format arguments with the name of one of the generic types are allowed in this context warning: positional format arguments are not allowed here --> $DIR/broken_format.rs:11:32 | LL | #[diagnostic::on_unimplemented(message = "Test {1:}")] |                                ^^^^^^^^^^^^^^^^^^^^^ | = help: only named format arguments with the name of one of the generic types are allowed in this context warning: invalid format specifier --> $DIR/broken_format.rs:16:32 | LL | #[diagnostic::on_unimplemented(message = "Test {Self:123}")] |                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: no format specifier are supported in this position warning: expected `'}'`, found `'!'` --> $DIR/broken_format.rs:21:32 | LL | #[diagnostic::on_unimplemented(message = "Test {Self:!}")] |                                ^^^^^^^^^^^^^^^^^^^^^^^^^ warning: unmatched `}` found --> $DIR/broken_format.rs:21:32 | LL | #[diagnostic::on_unimplemented(message = "Test {Self:!}")] |                                ^^^^^^^^^^^^^^^^^^^^^^^^^ warning: unmatched `}` found --> $DIR/broken_format.rs:1:32 | LL | #[diagnostic::on_unimplemented(message = "{{Test } thing")] |                                ^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: duplicate diagnostic emitted due to `-Z deduplicate-diagnostics=no` error[E0277]: {{Test } thing --> $DIR/broken_format.rs:35:13 | LL |     check_1(()); |     ------- ^^ the trait `ImportantTrait1` is not implemented for `()` |     | |     required by a bound introduced by this call | help: this trait has no implementations, consider adding one --> $DIR/broken_format.rs:4:1 | LL | trait ImportantTrait1 {} | ^^^^^^^^^^^^^^^^^^^^^ note: required by a bound in `check_1` --> $DIR/broken_format.rs:28:20 | LL | fn check_1(_: impl ImportantTrait1) {} |                    ^^^^^^^^^^^^^^^ required by this bound in `check_1` warning: positional format arguments are not allowed here --> $DIR/broken_format.rs:6:32 | LL | #[diagnostic::on_unimplemented(message = "Test {}")] |                                ^^^^^^^^^^^^^^^^^^^ | = help: only named format arguments with the name of one of the generic types are allowed in this context = note: duplicate diagnostic emitted due to `-Z deduplicate-diagnostics=no` error[E0277]: Test {} --> $DIR/broken_format.rs:37:13 | LL |     check_2(()); |     ------- ^^ the trait `ImportantTrait2` is not implemented for `()` |     | |     required by a bound introduced by this call | help: this trait has no implementations, consider adding one --> $DIR/broken_format.rs:9:1 | LL | trait ImportantTrait2 {} | ^^^^^^^^^^^^^^^^^^^^^ note: required by a bound in `check_2` --> $DIR/broken_format.rs:29:20 | LL | fn check_2(_: impl ImportantTrait2) {} |                    ^^^^^^^^^^^^^^^ required by this bound in `check_2` warning: positional format arguments are not allowed here --> $DIR/broken_format.rs:11:32 | LL | #[diagnostic::on_unimplemented(message = "Test {1:}")] |                                ^^^^^^^^^^^^^^^^^^^^^ | = help: only named format arguments with the name of one of the generic types are allowed in this context = note: duplicate diagnostic emitted due to `-Z deduplicate-diagnostics=no` error[E0277]: Test {1} --> $DIR/broken_format.rs:39:13 | LL |     check_3(()); |     ------- ^^ the trait `ImportantTrait3` is not implemented for `()` |     | |     required by a bound introduced by this call | help: this trait has no implementations, consider adding one --> $DIR/broken_format.rs:14:1 | LL | trait ImportantTrait3 {} | ^^^^^^^^^^^^^^^^^^^^^ note: required by a bound in `check_3` --> $DIR/broken_format.rs:30:20 | LL | fn check_3(_: impl ImportantTrait3) {} |                    ^^^^^^^^^^^^^^^ required by this bound in `check_3` warning: invalid format specifier --> $DIR/broken_format.rs:16:32 | LL | #[diagnostic::on_unimplemented(message = "Test {Self:123}")] |                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: no format specifier are supported in this position = note: duplicate diagnostic emitted due to `-Z deduplicate-diagnostics=no` error[E0277]: Test () --> $DIR/broken_format.rs:41:13 | LL |     check_4(()); |     ------- ^^ the trait `ImportantTrait4` is not implemented for `()` |     | |     required by a bound introduced by this call | help: this trait has no implementations, consider adding one --> $DIR/broken_format.rs:19:1 | LL | trait ImportantTrait4 {} | ^^^^^^^^^^^^^^^^^^^^^ note: required by a bound in `check_4` --> $DIR/broken_format.rs:31:20 | LL | fn check_4(_: impl ImportantTrait4) {} |                    ^^^^^^^^^^^^^^^ required by this bound in `check_4` warning: expected `'}'`, found `'!'` --> $DIR/broken_format.rs:21:32 | LL | #[diagnostic::on_unimplemented(message = "Test {Self:!}")] |                                ^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: duplicate diagnostic emitted due to `-Z deduplicate-diagnostics=no` warning: unmatched `}` found --> $DIR/broken_format.rs:21:32 | LL | #[diagnostic::on_unimplemented(message = "Test {Self:!}")] |                                ^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: duplicate diagnostic emitted due to `-Z deduplicate-diagnostics=no` error[E0277]: Test {Self:!} --> $DIR/broken_format.rs:43:13 | LL |     check_5(()); |     ------- ^^ the trait `ImportantTrait5` is not implemented for `()` |     | |     required by a bound introduced by this call | help: this trait has no implementations, consider adding one --> $DIR/broken_format.rs:26:1 | LL | trait ImportantTrait5 {} | ^^^^^^^^^^^^^^^^^^^^^ note: required by a bound in `check_5` --> $DIR/broken_format.rs:32:20 | LL | fn check_5(_: impl ImportantTrait5) {} |                    ^^^^^^^^^^^^^^^ required by this bound in `check_5` error: aborting due to 5 previous errors; 12 warnings emitted For more information about this error, try `rustc --explain E0277`. </ins>


Question:
Replacing with in makes it compile, so it feels to me the RPIT version should be accepted too. This is minimized from the . bisected: searched nightlies: from nightly-2024-03-14 to nightly-2024-03-20 regressed nightly: nightly-2024-03-16 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.8</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details label F-type-alias-impl-trait
label F-typealiasimpl_trait
Strange that this is due to . I'll look into this :thinking:
This started passing in . I wonder if it's because we were erroneously defining an opaque to be equal to itself.
yea looks like it

<ins> //@ check-pass #![feature(type_alias_impl_trait)] fn spawn<T, F>(future: F) -> impl Sized where F: FnOnce() -> T, { future } fn spawn_task(sender: &'static ()) -> impl Sized { type Tait = impl Sized + 'static; spawn::<Tait, _>(move || sender) } fn main() {} </ins>


Question:
<!-- ICE: Rustc '-Znext-solver=coherence -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: did not expect successful goal when collecting ambiguity errors', 'error: internal compiler error: did not expect successful goal when collecting ambiguity errors' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [specializationgraphof] building specialization graph of trait [coherenttrait] coherence checking all impls of trait [checkwellformed] checking that is well-formed [checkmodtype_wf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
regression in

// FIXME: We should investigate the perf implications of not uniquifying // `ReErased`. We may be able to short-circuit registering region // obligations if we encounter a `ReErased` on one side, for example. <del> ty::ReStatic | ty::ReErased => match self.canonicalize_mode { </del> <ins> ty::ReStatic | ty::ReErased | ty::ReError(_) => match self.canonicalize_mode { </ins> CanonicalizeMode::Input => CanonicalVarKind::Region(ty::UniverseIndex::ROOT), CanonicalizeMode::Response { .. } => return r, },


Question:
<!-- ICE: Rustc '-Znext-solver=coherence -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: did not expect successful goal when collecting ambiguity errors', 'error: internal compiler error: did not expect successful goal when collecting ambiguity errors' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [specializationgraphof] building specialization graph of trait [coherenttrait] coherence checking all impls of trait [checkwellformed] checking that is well-formed [checkmodtype_wf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
regression in

} } } <del> ty::ReError(_) => return r, </del> }; let existing_bound_var = match self.canonicalize_mode {


Question:
<!-- ICE: Rustc '-Znext-solver=coherence -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: did not expect successful goal when collecting ambiguity errors', 'error: internal compiler error: did not expect successful goal when collecting ambiguity errors' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [specializationgraphof] building specialization graph of trait [coherenttrait] coherence checking all impls of trait [checkwellformed] checking that is well-formed [checkmodtype_wf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
regression in

<ins> //@ compile-flags: -Znext-solver trait Tr<'a> {} // Fulfillment in the new solver relies on an invariant to hold: Either // `has_changed` is true, or computing a goal's certainty is idempotent. // This isn't true for `ReError`, which we used to pass through in the // canonicalizer even on input mode, which can cause a goal to go from // ambig => pass, but we don't consider `has_changed` when the response // only contains region constraints (since we usually uniquify regions). // //   In this test: // Implicit negative coherence tries to prove `W<?0>: Constrain<'?1>`, // which will then match with the impl below. This constrains `'?1` to // `ReError`, but still bails w/ ambiguity bc we can't prove `?0: Sized`. // Then, when we recompute the goal `W<?0>: Constrain<'error>`, when // collecting ambiguities and overflows, we end up assembling a default // error candidate w/o ambiguity, which causes the goal to pass, and ICE. impl<'a, A: ?Sized> Tr<'a> for W<A> {} struct W<A: ?Sized>(A); impl<'a, A: ?Sized> Tr<'a> for A where A: Constrain<'a> {} //~^ ERROR conflicting implementations of trait `Tr<'_>` for type `W<_>` trait Constrain<'a> {} impl<A: Sized> Constrain<'missing> for W<A> {} //~^ ERROR use of undeclared lifetime name `'missing` fn main() {} </ins>


Question:
<!-- ICE: Rustc '-Znext-solver=coherence -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: did not expect successful goal when collecting ambiguity errors', 'error: internal compiler error: did not expect successful goal when collecting ambiguity errors' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [specializationgraphof] building specialization graph of trait [coherenttrait] coherence checking all impls of trait [checkwellformed] checking that is well-formed [checkmodtype_wf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
regression in

<ins> error[E0261]: use of undeclared lifetime name `'missing` --> $DIR/dont-canonicalize-re-error.rs:25:26 | LL | impl<A: Sized> Constrain<'missing> for W<A> {} |      -                   ^^^^^^^^ undeclared lifetime |      | |      help: consider introducing lifetime `'missing` here: `'missing,` error[E0119]: conflicting implementations of trait `Tr<'_>` for type `W<_>` --> $DIR/dont-canonicalize-re-error.rs:21:1 | LL | impl<'a, A: ?Sized> Tr<'a> for W<A> {} | ----------------------------------- first implementation here LL | struct W<A: ?Sized>(A); LL | impl<'a, A: ?Sized> Tr<'a> for A where A: Constrain<'a> {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `W<_>` error: aborting due to 2 previous errors Some errors have detailed explanations: E0119, E0261. For more information about an error, try `rustc --explain E0119`. </ins>


Question:
<!-- ICE: Rustc '-Zsanitizer=cfi -Ccodegen-units=1 -Clto -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0'', 'thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0'' File: --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 --
I believe this happens since cc
seems to also cause problems
The core problem here is the encoding of the receiver on a object that has no principal. There's a fix for this in the larger patch stack I was breaking down to land piecewise. I'll upload it in a moment. claim

tcx: TyCtxt<'tcx>, predicates: &List<ty::PolyExistentialPredicate<'tcx>>, ) -> &'tcx List<ty::PolyExistentialPredicate<'tcx>> { <del> let predicates: Vec<ty::PolyExistentialPredicate<'tcx>> = predicates .iter() .filter_map(|predicate| match predicate.skip_binder() { </del> <ins> tcx.mk_poly_existential_predicates_from_iter(predicates.iter().filter_map(|predicate| { match predicate.skip_binder() { </ins> ty::ExistentialPredicate::Trait(trait_ref) => { let trait_ref = ty::TraitRef::identity(tcx, trait_ref.def_id); Some(ty::Binder::dummy(ty::ExistentialPredicate::Trait(


Question:
<!-- ICE: Rustc '-Zsanitizer=cfi -Ccodegen-units=1 -Clto -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0'', 'thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0'' File: --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 --
I believe this happens since cc
seems to also cause problems
The core problem here is the encoding of the receiver on a object that has no principal. There's a fix for this in the larger patch stack I was breaking down to land piecewise. I'll upload it in a moment. claim

} ty::ExistentialPredicate::Projection(..) => None, ty::ExistentialPredicate::AutoTrait(..) => Some(predicate), <del> }) .collect(); tcx.mk_poly_existential_predicates(&predicates) </del> <ins> } })) </ins> } /// Transforms args for being encoded and used in the substitution dictionary.


Question:
<!-- ICE: Rustc '-Zsanitizer=cfi -Ccodegen-units=1 -Clto -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0'', 'thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0'' File: --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 --
I believe this happens since cc
seems to also cause problems
The core problem here is the encoding of the receiver on a object that has no principal. There's a fix for this in the larger patch stack I was breaking down to land piecewise. I'll upload it in a moment. claim

let ty::Dynamic(preds, lifetime, kind) = ty.kind() else { bug!("Tried to strip auto traits from non-dynamic type {ty}"); }; <del> let filtered_preds = if preds.principal().is_some() { </del> <ins> let new_rcvr = if preds.principal().is_some() { let filtered_preds = </ins> tcx.mk_poly_existential_predicates_from_iter(preds.into_iter().filter(|pred| { !matches!(pred.skip_binder(), ty::ExistentialPredicate::AutoTrait(..)) <del> })) } else { ty::List::empty() }; let new_rcvr = Ty::new_dynamic(tcx, filtered_preds, *lifetime, *kind); </del> <ins> })); Ty::new_dynamic(tcx, filtered_preds, *lifetime, *kind) } else { // If there's no principal type, re-encode it as a unit, since we don't know anything // about it. This technically discards the knowledge that it was a type that was made // into a trait object at some point, but that's not a lot. tcx.types.unit }; </ins> tcx.mk_args_trait(new_rcvr, args.into_iter().skip(1)) }


Question:
<!-- ICE: Rustc '-Zsanitizer=cfi -Ccodegen-units=1 -Clto -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0'', 'thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0'' File: --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 --
I believe this happens since cc
seems to also cause problems
The core problem here is the encoding of the receiver on a object that has no principal. There's a fix for this in the larger patch stack I was breaking down to land piecewise. I'll upload it in a moment. claim

<ins> // Check that dropping a trait object without a principal trait succeeds //@ needs-sanitizer-cfi // FIXME(#122848) Remove only-linux once OSX CFI binaries works //@ only-linux //@ compile-flags: --crate-type=bin -Cprefer-dynamic=off -Clto -Zsanitizer=cfi //@ compile-flags: -C target-feature=-crt-static -C codegen-units=1 -C opt-level=0 // FIXME(#118761) Should be run-pass once the labels on drop are compatible. // This test is being landed ahead of that to test that the compiler doesn't ICE while labeling the // callsite for a drop, but the vtable doesn't have the correct label yet. //@ build-pass struct CustomDrop; impl Drop for CustomDrop { fn drop(&mut self) {} } fn main() { let _ = Box::new(CustomDrop) as Box<dyn Send>; } </ins>


Question:
PRs are bouncing due to test timeouts. Nothing has landed since cc
Very, very unfortunately, just landed. This means that the breakage is not unconditional.
Segfault!
had also been reporting segfaults on master.
I got a segfault on
What is causing this?
Weird, seemed to make it through.
This appears to be because of a channel deadlock. Investigating now.
Fixed the deadlock, investigating the segfault now.

// See the discussion in the stream implementation for why we we // might decrement steals. Some(data) => { <del> self.steals += 1; </del> if self.steals > MAX_STEALS { match self.cnt.swap(0, atomics::SeqCst) { DISCONNECTED => {


Question:
PRs are bouncing due to test timeouts. Nothing has landed since cc
Very, very unfortunately, just landed. This means that the breakage is not unconditional.
Segfault!
had also been reporting segfaults on master.
I got a segfault on
What is causing this?
Weird, seemed to make it through.
This appears to be because of a channel deadlock. Investigating now.
Fixed the deadlock, investigating the segfault now.

n => { let m = cmp::min(n, self.steals); self.steals -= m; <del> self.cnt.fetch_add(n - m, atomics::SeqCst); </del> <ins> self.bump(n - m); </ins> } } assert!(self.steals >= 0); } <ins> self.steals += 1; </ins> Ok(data) }


Question:
PRs are bouncing due to test timeouts. Nothing has landed since cc
Very, very unfortunately, just landed. This means that the breakage is not unconditional.
Segfault!
had also been reporting segfaults on master.
I got a segfault on
What is causing this?
Weird, seemed to make it through.
This appears to be because of a channel deadlock. Investigating now.
Fixed the deadlock, investigating the segfault now.

// down as much as possible (without going negative), and then // adding back in whatever we couldn't factor into steals. Some(data) => { <del> self.steals += 1; </del> if self.steals > MAX_STEALS { match self.cnt.swap(0, atomics::SeqCst) { DISCONNECTED => {


Question:
PRs are bouncing due to test timeouts. Nothing has landed since cc
Very, very unfortunately, just landed. This means that the breakage is not unconditional.
Segfault!
had also been reporting segfaults on master.
I got a segfault on
What is causing this?
Weird, seemed to make it through.
This appears to be because of a channel deadlock. Investigating now.
Fixed the deadlock, investigating the segfault now.

n => { let m = cmp::min(n, self.steals); self.steals -= m; <del> self.cnt.fetch_add(n - m, atomics::SeqCst); </del> <ins> self.bump(n - m); </ins> } } assert!(self.steals >= 0); } <ins> self.steals += 1; </ins> match data { Data(t) => Ok(t), GoUp(up) => Err(Upgraded(up)),


Question:
Sorry, I don't have simple code to reproduce the issue, because the project is large. The repro is this: Contents of the mentioned file is: I tried increasing , did not help. Also works on stable. This may be duplicate of because timing.
This is also affecting :
Using the starlark-rust repro, this bisects to
overflow is fatal in the old trait solver, so by proving additional goals, especially if they have inference variables, we can end up with new sources of overflow causing an error. the most straightforward fix is to use the new solver for this lint given that the lint uses an empty environment it uses pretty much the same parts of the solver as coherence so it should already be ready for that
WG-prioritization assigning priority (). label -I-prioritize +P-high
I have a somewhat minimal repro, it has a lot of deps (via bevy) but not much code: Where is not something (I think) that can be decomposed into a tuple.

binder: EarlyBinder<TraitRef<'tcx>>, mut did_has_local_parent: impl FnMut(DefId) -> bool, ) -> bool { <del> let infcx = tcx.infer_ctxt().build(); </del> <ins> let infcx = tcx .infer_ctxt() // We use the new trait solver since the obligation we are trying to // prove here may overflow and those are fatal in the old trait solver. // Which is unacceptable for a lint. // // Thanksfully the part we use here are very similar to the // new-trait-solver-as-coherence, which is in stabilization. // // https://github.com/rust-lang/rust/issues/123573 .with_next_trait_solver(true) .build(); </ins> let trait_ref = binder.instantiate(tcx, infcx.fresh_args_for_item(infer_span, trait_def_id)); let trait_ref = trait_ref.fold_with(&mut ReplaceLocalTypesWithInfer {


Question:
Sorry, I don't have simple code to reproduce the issue, because the project is large. The repro is this: Contents of the mentioned file is: I tried increasing , did not help. Also works on stable. This may be duplicate of because timing.
This is also affecting :
Using the starlark-rust repro, this bisects to
overflow is fatal in the old trait solver, so by proving additional goals, especially if they have inference variables, we can end up with new sources of overflow causing an error. the most straightforward fix is to use the new solver for this lint given that the lint uses an empty environment it uses pretty much the same parts of the solver as coherence so it should already be ready for that
WG-prioritization assigning priority (). label -I-prioritize +P-high
I have a somewhat minimal repro, it has a lot of deps (via bevy) but not much code: Where is not something (I think) that can be decomposed into a tuple.

<ins> //@ check-pass //@ edition:2021 // https://github.com/rust-lang/rust/issues/123573#issue-2229428739 pub trait Test {} impl<'a, T: 'a> Test for &[T] where &'a T: Test {} fn main() { struct Local {} impl Test for &Local {} //~^ WARN non-local `impl` definition } </ins>


Question:
Sorry, I don't have simple code to reproduce the issue, because the project is large. The repro is this: Contents of the mentioned file is: I tried increasing , did not help. Also works on stable. This may be duplicate of because timing.
This is also affecting :
Using the starlark-rust repro, this bisects to
overflow is fatal in the old trait solver, so by proving additional goals, especially if they have inference variables, we can end up with new sources of overflow causing an error. the most straightforward fix is to use the new solver for this lint given that the lint uses an empty environment it uses pretty much the same parts of the solver as coherence so it should already be ready for that
WG-prioritization assigning priority (). label -I-prioritize +P-high
I have a somewhat minimal repro, it has a lot of deps (via bevy) but not much code: Where is not something (I think) that can be decomposed into a tuple.

<ins> warning: non-local `impl` definition, they should be avoided as they go against expectation --> $DIR/trait-solver-overflow-123573.rs:12:5 | LL |     impl Test for &Local {} |     ^^^^^^^^^^^^^^^^^^^^^^^ | = help: move this `impl` block outside the of the current function `main` = note: an `impl` definition is non-local if it is nested inside an item and may impact type checking outside of that item. This can be the case if neither the trait or the self type are at the same nesting level as the `impl` = note: one exception to the rule are anon-const (`const _: () = { ... }`) at top-level module and anon-const at the same nesting as the trait or type = note: this lint may become deny-by-default in the edition 2024 and higher, see the tracking issue <https://github.com/rust-lang/rust/issues/120363> = note: `#[warn(non_local_definitions)]` on by default warning: 1 warning emitted </ins>


Question:
<!-- ICE: Rustc '--edition=2018 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'we captured CapturedPlace {'', 'thread 'rustc' panicked at 'we captured CapturedPlace {'' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [typeck] type-checking [analysis] running analysis passes on this crate --
probably also caused by ?
yep ill put up a fix in a few

use rustc_middle::mir::FakeReadCause; use rustc_middle::traits::ObligationCauseCode; use rustc_middle::ty::{ <del> self, ClosureSizeProfileData, Ty, TyCtxt, TypeckResults, UpvarArgs, UpvarCapture, </del> <ins> self, ClosureSizeProfileData, Ty, TyCtxt, TypeVisitableExt as _, TypeckResults, UpvarArgs, UpvarCapture, </ins> }; use rustc_session::lint; use rustc_span::sym;


Question:
<!-- ICE: Rustc '--edition=2018 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'we captured CapturedPlace {'', 'thread 'rustc' panicked at 'we captured CapturedPlace {'' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [typeck] type-checking [analysis] running analysis passes on this crate --
probably also caused by ?
yep ill put up a fix in a few

); } }; <ins> let args = self.resolve_vars_if_possible(args); </ins> let closure_def_id = closure_def_id.expect_local(); assert_eq!(self.tcx.hir().body_owner_def_id(body.id()), closure_def_id);


Question:
<!-- ICE: Rustc '--edition=2018 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'we captured CapturedPlace {'', 'thread 'rustc' panicked at 'we captured CapturedPlace {'' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [typeck] type-checking [analysis] running analysis passes on this crate --
probably also caused by ?
yep ill put up a fix in a few

// For coroutine-closures, we additionally must compute the // `coroutine_captures_by_ref_ty` type, which is used to generate the by-ref // version of the coroutine-closure's output coroutine. <del> if let UpvarArgs::CoroutineClosure(args) = args { </del> <ins> if let UpvarArgs::CoroutineClosure(args) = args && !args.references_error() { </ins> let closure_env_region: ty::Region<'_> = ty::Region::new_bound( self.tcx, ty::INNERMOST,


Question:
<!-- ICE: Rustc '--edition=2018 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'we captured CapturedPlace {'', 'thread 'rustc' panicked at 'we captured CapturedPlace {'' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [typeck] type-checking [analysis] running analysis passes on this crate --
probably also caused by ?
yep ill put up a fix in a few

} } <del> #[derive(Debug, Copy, Clone, HashStable)] </del> <ins> #[derive(Debug, Copy, Clone, HashStable, TypeFoldable, TypeVisitable)] </ins> pub enum UpvarArgs<'tcx> { Closure(GenericArgsRef<'tcx>), Coroutine(GenericArgsRef<'tcx>),


Question:
<!-- ICE: Rustc '--edition=2018 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'we captured CapturedPlace {'', 'thread 'rustc' panicked at 'we captured CapturedPlace {'' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [typeck] type-checking [analysis] running analysis passes on this crate --
probably also caused by ?
yep ill put up a fix in a few

<ins> //@ edition: 2021 #![feature(async_closure)] struct DropMe; trait Impossible {} fn trait_error<T: Impossible>() {} pub fn main() { let b = DropMe; let async_closure = async move || { // Type error here taints the environment. This causes us to fallback all // variables to `Error`. This means that when we compute the upvars for the // *outer* coroutine-closure, we don't actually see any upvars since `MemCategorization` // and `ExprUseVisitor`` will bail early when it sees error. This means // that our underlying assumption that the parent and child captures are // compatible ends up being broken, previously leading to an ICE. trait_error::<()>(); //~^ ERROR the trait bound `(): Impossible` is not satisfied let _b = b; }; } </ins>


Question:
<!-- ICE: Rustc '--edition=2018 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'we captured CapturedPlace {'', 'thread 'rustc' panicked at 'we captured CapturedPlace {'' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [typeck] type-checking [analysis] running analysis passes on this crate --
probably also caused by ?
yep ill put up a fix in a few

<ins> error[E0277]: the trait bound `(): Impossible` is not satisfied --> $DIR/dont-ice-when-body-tainted-by-errors.rs:19:23 | LL |         trait_error::<()>(); |                       ^^ the trait `Impossible` is not implemented for `()` | help: this trait has no implementations, consider adding one --> $DIR/dont-ice-when-body-tainted-by-errors.rs:7:1 | LL | trait Impossible {} | ^^^^^^^^^^^^^^^^ note: required by a bound in `trait_error` --> $DIR/dont-ice-when-body-tainted-by-errors.rs:8:19 | LL | fn trait_error<T: Impossible>() {} |                   ^^^^^^^^^^ required by this bound in `trait_error` error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0277`. </ins>


Question:
Same issue as which was for blocks. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

passes_both_ffi_const_and_pure = `#[ffi_const]` function cannot be `#[ffi_pure]` <del> passes_break_inside_async_block = `{$name}` inside of an `async` block .label = cannot `{$name}` inside of an `async` block .async_block_label = enclosing `async` block </del> passes_break_inside_closure = `{$name}` inside of a closure .label = cannot `{$name}` inside of a closure .closure_label = enclosing closure <ins> passes_break_inside_coroutine = `{$name}` inside `{$kind}` {$source} .label = cannot `{$name}` inside `{$kind}` {$source} .coroutine_label = enclosing `{$kind}` {$source} </ins> passes_break_non_loop = `break` with value from a `{$kind}` loop .label = can only break with a value inside `loop` or breakable block


Question:
Same issue as which was for blocks. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

} #[derive(Diagnostic)] <del> #[diag(passes_break_inside_async_block, code = E0267)] pub struct BreakInsideAsyncBlock<'a> { </del> <ins> #[diag(passes_break_inside_coroutine, code = E0267)] pub struct BreakInsideCoroutine<'a> { </ins> #[primary_span] #[label] pub span: Span, <del> #[label(passes_async_block_label)] pub closure_span: Span, </del> <ins> #[label(passes_coroutine_label)] pub coroutine_span: Span, </ins> pub name: &'a str, <ins> pub kind: &'a str, pub source: &'a str, </ins> } #[derive(Diagnostic)]


Question:
Same issue as which was for blocks. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

use rustc_span::{BytePos, Span}; use crate::errors::{ <del> BreakInsideAsyncBlock, BreakInsideClosure, BreakNonLoop, ContinueLabeledBlock, OutsideLoop, </del> <ins> BreakInsideClosure, BreakInsideCoroutine, BreakNonLoop, ContinueLabeledBlock, OutsideLoop, </ins> OutsideLoopSuggestion, UnlabeledCfInWhileCondition, UnlabeledInLabeledBlock, };


Question:
Same issue as which was for blocks. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

Fn, Loop(hir::LoopSource), Closure(Span), <del> AsyncClosure(Span), </del> <ins> Coroutine { coroutine_span: Span, kind: hir::CoroutineDesugaring, source: hir::CoroutineSource }, </ins> UnlabeledBlock(Span), LabeledBlock, Constant,


Question:
Same issue as which was for blocks. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

hir::ExprKind::Closure(&hir::Closure { ref fn_decl, body, fn_decl_span, kind, .. }) => { <del> // FIXME(coroutines): This doesn't handle coroutines correctly </del> let cx = match kind { <del> hir::ClosureKind::Coroutine(hir::CoroutineKind::Desugared( hir::CoroutineDesugaring::Async, hir::CoroutineSource::Block, )) => AsyncClosure(fn_decl_span), </del> <ins> hir::ClosureKind::Coroutine(hir::CoroutineKind::Desugared(kind, source)) => { Coroutine { coroutine_span: fn_decl_span, kind, source } } </ins> _ => Closure(fn_decl_span), }; self.visit_fn_decl(fn_decl);


Question:
Same issue as which was for blocks. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

Closure(closure_span) => { self.sess.dcx().emit_err(BreakInsideClosure { span, closure_span, name }); } <del> AsyncClosure(closure_span) => { self.sess.dcx().emit_err(BreakInsideAsyncBlock { span, closure_span, name }); </del> <ins> Coroutine { coroutine_span, kind, source } => { let kind = match kind { hir::CoroutineDesugaring::Async => "async", hir::CoroutineDesugaring::Gen => "gen", hir::CoroutineDesugaring::AsyncGen => "async gen", }; let source = match source { hir::CoroutineSource::Block => "block", hir::CoroutineSource::Closure => "closure", hir::CoroutineSource::Fn => "function", }; self.sess.dcx().emit_err(BreakInsideCoroutine { span, coroutine_span, name, kind, source, }); </ins> } UnlabeledBlock(block_span) if is_break && block_span.eq_ctxt(break_span) => { let suggestion = Some(OutsideLoopSuggestion { block_span, break_span });


Question:
Same issue as which was for blocks. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

fn no_break_in_async_block() { async { <del> break 0u8; //~ ERROR `break` inside of an `async` block </del> <ins> break 0u8; //~ ERROR `break` inside `async` block </ins> }; } fn no_break_in_async_block_even_with_outer_loop() { loop { async { <del> break 0u8; //~ ERROR `break` inside of an `async` block </del> <ins> break 0u8; //~ ERROR `break` inside `async` block </ins> }; } }


Question:
Same issue as which was for blocks. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

<del> error[E0267]: `break` inside of an `async` block </del> <ins> error[E0267]: `break` inside `async` block </ins> --> $DIR/async-block-control-flow-static-semantics.rs:32:9 | LL | /     async { LL | |         break 0u8; <del> | |         ^^^^^^^^^ cannot `break` inside of an `async` block </del> <ins> | |         ^^^^^^^^^ cannot `break` inside `async` block </ins> LL | |     }; | |_____- enclosing `async` block <del> error[E0267]: `break` inside of an `async` block </del> <ins> error[E0267]: `break` inside `async` block </ins> --> $DIR/async-block-control-flow-static-semantics.rs:39:13 | LL | /         async { LL | |             break 0u8; <del> | |             ^^^^^^^^^ cannot `break` inside of an `async` block </del> <ins> | |             ^^^^^^^^^ cannot `break` inside `async` block </ins> LL | |         }; | |_________- enclosing `async` block


Question:
Same issue as which was for blocks. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

<ins> //@ edition: 2024 //@ compile-flags: -Z unstable-options #![feature(gen_blocks)] #![feature(async_closure)] async fn async_fn() { break; //~ ERROR `break` inside `async` function } gen fn gen_fn() { break; //~ ERROR `break` inside `gen` function } async gen fn async_gen_fn() { break; //~ ERROR `break` inside `async gen` function } fn main() { let _ = async { break; }; //~ ERROR `break` inside `async` block let _ = async || { break; }; //~ ERROR `break` inside `async` closure let _ = gen { break; }; //~ ERROR `break` inside `gen` block let _ = async gen { break; }; //~ ERROR `break` inside `async gen` block } </ins>


Question:
Same issue as which was for blocks. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

<ins> error[E0267]: `break` inside `async` function --> $DIR/break-inside-coroutine-issue-124495.rs:8:5 | LL |   async fn async_fn() { |  _____________________- LL | |     break; | |     ^^^^^ cannot `break` inside `async` function LL | | } | |_- enclosing `async` function error[E0267]: `break` inside `gen` function --> $DIR/break-inside-coroutine-issue-124495.rs:12:5 | LL |   gen fn gen_fn() { |  _________________- LL | |     break; | |     ^^^^^ cannot `break` inside `gen` function LL | | } | |_- enclosing `gen` function error[E0267]: `break` inside `async gen` function --> $DIR/break-inside-coroutine-issue-124495.rs:16:5 | LL |   async gen fn async_gen_fn() { |  _____________________________- LL | |     break; | |     ^^^^^ cannot `break` inside `async gen` function LL | | } | |_- enclosing `async gen` function error[E0267]: `break` inside `async` block --> $DIR/break-inside-coroutine-issue-124495.rs:20:21 | LL |     let _ = async { break; }; |             --------^^^^^--- |             |       | |             |       cannot `break` inside `async` block |             enclosing `async` block error[E0267]: `break` inside `async` closure --> $DIR/break-inside-coroutine-issue-124495.rs:21:24 | LL |     let _ = async || { break; }; |                      --^^^^^--- |                      | | |                      | cannot `break` inside `async` closure |                      enclosing `async` closure error[E0267]: `break` inside `gen` block --> $DIR/break-inside-coroutine-issue-124495.rs:23:19 | LL |     let _ = gen { break; }; |             ------^^^^^--- |             |     | |             |     cannot `break` inside `gen` block |             enclosing `gen` block error[E0267]: `break` inside `async gen` block --> $DIR/break-inside-coroutine-issue-124495.rs:25:25 | LL |     let _ = async gen { break; }; |             ------------^^^^^--- |             |           | |             |           cannot `break` inside `async gen` block |             enclosing `async gen` block error: aborting due to 7 previous errors For more information about this error, try `rustc --explain E0267`. </ins>


Question:
The idea of changing a field to unit type to preserve field numbering makes sense for fields in the middle of a tuple. However, if the unused field is at the end, or it's the only field, then deleting it won't affect field numbering of any other field. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

passes_proc_macro_bad_sig = {$kind} has incorrect signature <ins> passes_remove_fields = consider removing { $num -> [one] this *[other] these } { $num -> [one] field *[other] fields } </ins> passes_repr_conflicting = conflicting representation hints


Question:
The idea of changing a field to unit type to preserve field numbering makes sense for fields in the middle of a tuple. However, if the unused field is at the end, or it's the only field, then deleting it won't affect field numbering of any other field. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

use std::mem; use crate::errors::{ <del> ChangeFieldsToBeOfUnitType, IgnoredDerivedImpls, MultipleDeadCodes, ParentInfo, UselessAssignment, </del> <ins> ChangeFields, IgnoredDerivedImpls, MultipleDeadCodes, ParentInfo, UselessAssignment, </ins> }; // Any local node that may call something in its body block should be


Question:
The idea of changing a field to unit type to preserve field numbering makes sense for fields in the middle of a tuple. However, if the unused field is at the end, or it's the only field, then deleting it won't affect field numbering of any other field. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

}; let diag = match report_on { <del> ReportOn::TupleField => MultipleDeadCodes::UnusedTupleStructFields { multiple, num, descr, participle, name_list, change_fields_suggestion: ChangeFieldsToBeOfUnitType { num, spans: spans.clone() }, parent_info, ignored_derived_impls, }, </del> <ins> ReportOn::TupleField => { let tuple_fields = if let Some(parent_id) = parent_item && let node = tcx.hir_node_by_def_id(parent_id) && let hir::Node::Item(hir::Item { kind: hir::ItemKind::Struct(hir::VariantData::Tuple(fields, _, _), _), .. }) = node { *fields } else { &[] }; let trailing_tuple_fields = if tuple_fields.len() >= dead_codes.len() { LocalDefIdSet::from_iter( tuple_fields .iter() .skip(tuple_fields.len() - dead_codes.len()) .map(|f| f.def_id), ) } else { LocalDefIdSet::default() }; let fields_suggestion = // Suggest removal if all tuple fields are at the end. // Otherwise suggest removal or changing to unit type if dead_codes.iter().all(|dc| trailing_tuple_fields.contains(&dc.def_id)) { ChangeFields::Remove { num } } else { ChangeFields::ChangeToUnitTypeOrRemove { num, spans: spans.clone() } }; MultipleDeadCodes::UnusedTupleStructFields { multiple, num, descr, participle, name_list, change_fields_suggestion: fields_suggestion, parent_info, ignored_derived_impls, } } </ins> ReportOn::NamedField => MultipleDeadCodes::DeadCodes { multiple, num,


Question:
The idea of changing a field to unit type to preserve field numbering makes sense for fields in the middle of a tuple. However, if the unused field is at the end, or it's the only field, then deleting it won't affect field numbering of any other field. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

participle: &'tcx str, name_list: DiagSymbolList, #[subdiagnostic] <del> change_fields_suggestion: ChangeFieldsToBeOfUnitType, </del> <ins> change_fields_suggestion: ChangeFields, </ins> #[subdiagnostic] parent_info: Option<ParentInfo<'tcx>>, #[subdiagnostic]


Question:
The idea of changing a field to unit type to preserve field numbering makes sense for fields in the middle of a tuple. However, if the unused field is at the end, or it's the only field, then deleting it won't affect field numbering of any other field. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

} #[derive(Subdiagnostic)] <del> #[multipart_suggestion(passes_change_fields_to_be_of_unit_type, applicability = "has-placeholders")] pub struct ChangeFieldsToBeOfUnitType { pub num: usize, #[suggestion_part(code = "()")] pub spans: Vec<Span>, </del> <ins> pub enum ChangeFields { #[multipart_suggestion( passes_change_fields_to_be_of_unit_type, applicability = "has-placeholders" )] ChangeToUnitTypeOrRemove { num: usize, #[suggestion_part(code = "()")] spans: Vec<Span>, }, #[help(passes_remove_fields)] Remove { num: usize }, </ins> } #[derive(Diagnostic)]


Question:
The idea of changing a field to unit type to preserve field numbering makes sense for fields in the middle of a tuple. However, if the unused field is at the end, or it's the only field, then deleting it won't affect field numbering of any other field. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

const LEN: usize = 4; <del> struct SingleUnused(i32, [u8; LEN], String); //~^ ERROR: field `1` is never read </del> <ins> struct UnusedAtTheEnd(i32, f32, [u8; LEN], String, u8); //~^ ERROR:fields `1`, `2`, `3`, and `4` are never read //~| NOTE: fields in this struct //~| HELP: consider removing these fields struct UnusedJustOneField(i32); //~^ ERROR: field `0` is never read </ins> //~| NOTE: field in this struct <del> //~| HELP: consider changing the field to be of unit type </del> <ins> //~| HELP: consider removing this field </ins> <del> struct MultipleUnused(i32, f32, String, u8); //~^ ERROR: fields `0`, `1`, `2`, and `3` are never read </del> <ins> struct UnusedInTheMiddle(i32, f32, String, u8, u32); //~^ ERROR: fields `1`, `2`, and `4` are never read </ins> //~| NOTE: fields in this struct <del> //~| HELP: consider changing the fields to be of unit type </del> <ins> //~| HELP: consider changing the fields to be of unit type to suppress this warning while preserving the field numbering, or remove the fields </ins> struct GoodUnit(());


Question:
The idea of changing a field to unit type to preserve field numbering makes sense for fields in the middle of a tuple. However, if the unused field is at the end, or it's the only field, then deleting it won't affect field numbering of any other field. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

struct GoodVoid(Void); fn main() { <del> let w = SingleUnused(42, [0, 1, 2, 3], "abc".to_string()); let _ = w.0; let _ = w.2; </del> <ins> let u1 = UnusedAtTheEnd(42, 3.14, [0, 1, 2, 3], "def".to_string(), 4u8); let _ = u1.0; let _ = UnusedJustOneField(42); let u2 = UnusedInTheMiddle(42, 3.14, "def".to_string(), 4u8, 5); let _ = u2.0; let _ = u2.3; </ins> <del> let m = MultipleUnused(42, 3.14, "def".to_string(), 4u8); </del> let gu = GoodUnit(()); let gp = GoodPhantom(PhantomData); let gv = GoodVoid(Void); <del> let _ = (gu, gp, gv, m); </del> <ins> let _ = (gu, gp, gv); </ins> }


Question:
The idea of changing a field to unit type to preserve field numbering makes sense for fields in the middle of a tuple. However, if the unused field is at the end, or it's the only field, then deleting it won't affect field numbering of any other field. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

<del> error: field `1` is never read --> $DIR/tuple-struct-field.rs:8:26 </del> <ins> error: fields `1`, `2`, `3`, and `4` are never read --> $DIR/tuple-struct-field.rs:8:28 </ins> | <del> LL | struct SingleUnused(i32, [u8; LEN], String); |        ------------      ^^^^^^^^^ </del> <ins> LL | struct UnusedAtTheEnd(i32, f32, [u8; LEN], String, u8); |        --------------      ^^^  ^^^^^^^^^  ^^^^^^  ^^ </ins> |        | <del> |        field in this struct </del> <ins> |        fields in this struct </ins> | <ins> = help: consider removing these fields </ins> note: the lint level is defined here --> $DIR/tuple-struct-field.rs:1:9 | LL | #![deny(dead_code)] |         ^^^^^^^^^ <del> help: consider changing the field to be of unit type to suppress this warning while preserving the field numbering, or remove the field </del> <ins> error: field `0` is never read --> $DIR/tuple-struct-field.rs:13:27 | LL | struct UnusedJustOneField(i32); |        ------------------ ^^^ |        | |        field in this struct </ins> | <del> LL | struct SingleUnused(i32, (), String); |                          ~~ </del> <ins> = help: consider removing this field </ins> <del> error: fields `0`, `1`, `2`, and `3` are never read --> $DIR/tuple-struct-field.rs:13:23 </del> <ins> error: fields `1`, `2`, and `4` are never read --> $DIR/tuple-struct-field.rs:18:31 </ins> | <del> LL | struct MultipleUnused(i32, f32, String, u8); |        -------------- ^^^  ^^^  ^^^^^^  ^^ </del> <ins> LL | struct UnusedInTheMiddle(i32, f32, String, u8, u32); |        -----------------      ^^^  ^^^^^^      ^^^ </ins> |        | |        fields in this struct | help: consider changing the fields to be of unit type to suppress this warning while preserving the field numbering, or remove the fields | <del> LL | struct MultipleUnused((), (), (), ()); |                       ~~  ~~  ~~  ~~ </del> <ins> LL | struct UnusedInTheMiddle(i32, (), (), u8, ()); |                               ~~  ~~      ~~ </ins> <del> error: aborting due to 2 previous errors </del> <ins> error: aborting due to 3 previous errors </ins>


Question:
: <details<summary<strongBacktrace</strong</summary<p</p</details
This looks to be a recent regression from cc and is on beta 1.79, but is just in diagnostics.

// Get the arguments for the found method, only specifying that `Self` is the receiver type. let Some(possible_rcvr_ty) = typeck_results.node_type_opt(rcvr.hir_id) else { return }; let args = GenericArgs::for_item(tcx, method_def_id, |param, _| { <del> if param.index == 0 { </del> <ins> if let ty::GenericParamDefKind::Lifetime = param.kind { tcx.lifetimes.re_erased.into() } else if param.index == 0 && param.name == kw::SelfUpper { </ins> possible_rcvr_ty.into() } else if param.index == closure_param.index { closure_ty.into()


Question:
: <details<summary<strongBacktrace</strong</summary<p</p</details
This looks to be a recent regression from cc and is on beta 1.79, but is just in diagnostics.

Obligation::misc(tcx, span, self.mir_def_id(), self.param_env, pred) })); <del> if ocx.select_all_or_error().is_empty() { </del> <ins> if ocx.select_all_or_error().is_empty() && count > 0 { </ins> diag.span_suggestion_verbose( tcx.hir().body(*body).value.peel_blocks().span.shrink_to_lo(), "dereference the return value",


Question:
: <details<summary<strongBacktrace</strong</summary<p</p</details
This looks to be a recent regression from cc and is on beta 1.79, but is just in diagnostics.

<del> //@ known-bug: rust-lang/rust#124563 use std::marker::PhantomData; pub trait Trait {} pub trait Foo { type Trait: Trait; type Bar: Bar; fn foo(&mut self); } pub struct FooImpl<'a, 'b, A: Trait>(PhantomData<&'a &'b A>); impl<'a, 'b, T> Foo for FooImpl<'a, 'b, T> where T: Trait, { type Trait = T; type Bar = BarImpl<'a, 'b, T>; fn foo(&mut self) { self.enter_scope(|ctx| { BarImpl(ctx); }); } } impl<'a, 'b, T> FooImpl<'a, 'b, T> where T: Trait, { fn enter_scope(&mut self, _scope: impl FnOnce(&mut Self)) {} } pub trait Bar { type Foo: Foo; } pub struct BarImpl<'a, 'b, T: Trait>(&'b mut FooImpl<'a, 'b, T>); impl<'a, 'b, T> Bar for BarImpl<'a, 'b, T> where T: Trait, { type Foo = FooImpl<'a, 'b, T>; } </del>


Question:
: <details<summary<strongBacktrace</strong</summary<p</p</details
This looks to be a recent regression from cc and is on beta 1.79, but is just in diagnostics.

<ins> // #125634 struct Thing; // Invariant in 'a, Covariant in 'b struct TwoThings<'a, 'b>(*mut &'a (), &'b mut ()); impl Thing { fn enter_scope<'a>(self, _scope: impl for<'b> FnOnce(TwoThings<'a, 'b>)) {} } fn foo() { Thing.enter_scope(|ctx| { SameLifetime(ctx); //~ ERROR lifetime may not live long enough }); } struct SameLifetime<'a>(TwoThings<'a, 'a>); fn main() {} </ins>


Question:
: <details<summary<strongBacktrace</strong</summary<p</p</details
This looks to be a recent regression from cc and is on beta 1.79, but is just in diagnostics.

<ins> error: lifetime may not live long enough --> $DIR/account-for-lifetimes-in-closure-suggestion.rs:13:22 | LL |     Thing.enter_scope(|ctx| { |                        --- |                        | |                        has type `TwoThings<'_, '1>` |                        has type `TwoThings<'2, '_>` LL |         SameLifetime(ctx); |                      ^^^ this usage requires that `'1` must outlive `'2` | = note: requirement occurs because of the type `TwoThings<'_, '_>`, which makes the generic argument `'_` invariant = note: the struct `TwoThings<'a, 'b>` is invariant over the parameter `'a` = help: see <https://doc.rust-lang.org/nomicon/subtyping.html> for more information about variance error: aborting due to 1 previous error </ins>


Question:
: <details<summary<strongBacktrace</strong</summary<p</p</details
This looks to be a recent regression from cc and is on beta 1.79, but is just in diagnostics.

<ins> // #124563 use std::marker::PhantomData; pub trait Trait {} pub trait Foo { type Trait: Trait; type Bar: Bar; fn foo(&mut self); } pub struct FooImpl<'a, 'b, A: Trait>(PhantomData<&'a &'b A>); impl<'a, 'b, T> Foo for FooImpl<'a, 'b, T> where T: Trait, { type Trait = T; type Bar = BarImpl<'a, 'b, T>; //~ ERROR lifetime bound not satisfied fn foo(&mut self) { self.enter_scope(|ctx| { //~ ERROR lifetime may not live long enough BarImpl(ctx); //~ ERROR lifetime may not live long enough }); } } impl<'a, 'b, T> FooImpl<'a, 'b, T> where T: Trait, { fn enter_scope(&mut self, _scope: impl FnOnce(&mut Self)) {} } pub trait Bar { type Foo: Foo; } pub struct BarImpl<'a, 'b, T: Trait>(&'b mut FooImpl<'a, 'b, T>); impl<'a, 'b, T> Bar for BarImpl<'a, 'b, T> where T: Trait, { type Foo = FooImpl<'a, 'b, T>; } fn main() {} </ins>


Question:
: <details<summary<strongBacktrace</strong</summary<p</p</details
This looks to be a recent regression from cc and is on beta 1.79, but is just in diagnostics.

<ins> error[E0478]: lifetime bound not satisfied --> $DIR/lifetime-not-long-enough-suggestion-regression-test-124563.rs:19:16 | LL |     type Bar = BarImpl<'a, 'b, T>; |                ^^^^^^^^^^^^^^^^^^ | note: lifetime parameter instantiated with the lifetime `'a` as defined here --> $DIR/lifetime-not-long-enough-suggestion-regression-test-124563.rs:14:6 | LL | impl<'a, 'b, T> Foo for FooImpl<'a, 'b, T> |      ^^ note: but lifetime parameter must outlive the lifetime `'b` as defined here --> $DIR/lifetime-not-long-enough-suggestion-regression-test-124563.rs:14:10 | LL | impl<'a, 'b, T> Foo for FooImpl<'a, 'b, T> |          ^^ error: lifetime may not live long enough --> $DIR/lifetime-not-long-enough-suggestion-regression-test-124563.rs:23:21 | LL |         self.enter_scope(|ctx| { |                           --- |                           | |                           has type `&'1 mut FooImpl<'_, '_, T>` |                           has type `&mut FooImpl<'2, '_, T>` LL |             BarImpl(ctx); |                     ^^^ this usage requires that `'1` must outlive `'2` error: lifetime may not live long enough --> $DIR/lifetime-not-long-enough-suggestion-regression-test-124563.rs:22:9 | LL |   impl<'a, 'b, T> Foo for FooImpl<'a, 'b, T> |        --  -- lifetime `'b` defined here |        | |        lifetime `'a` defined here ... LL | /         self.enter_scope(|ctx| { LL | |             BarImpl(ctx); LL | |         }); | |__________^ argument requires that `'a` must outlive `'b` | = help: consider adding the following bound: `'a: 'b` = note: requirement occurs because of a mutable reference to `FooImpl<'_, '_, T>` = note: mutable references are invariant over their type parameter = help: see <https://doc.rust-lang.org/nomicon/subtyping.html> for more information about variance error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0478`. </ins>


Question:
: <details<summary<strongBacktrace</strong</summary<p</p</details
This looks to be a recent regression from cc and is on beta 1.79, but is just in diagnostics.

<ins> // Test a method call where the parameter `B` would (illegally) be // inferred to a region bound in the method argument. If this program // were accepted, then the closure passed to `s.f` could escape its // argument. //@ run-rustfix struct S; impl S { fn f<B, F>(&self, _: F) where F: FnOnce(&i32) -> B { } } fn main() { let s = S; s.f(|p| *p) //~ ERROR lifetime may not live long enough } </ins>


Question:
: <details<summary<strongBacktrace</strong</summary<p</p</details
This looks to be a recent regression from cc and is on beta 1.79, but is just in diagnostics.

// inferred to a region bound in the method argument. If this program // were accepted, then the closure passed to `s.f` could escape its // argument. <ins> //@ run-rustfix </ins> struct S;


Question:
: <details<summary<strongBacktrace</strong</summary<p</p</details
This looks to be a recent regression from cc and is on beta 1.79, but is just in diagnostics.

error: lifetime may not live long enough <del> --> $DIR/regions-escape-method.rs:15:13 </del> <ins> --> $DIR/regions-escape-method.rs:16:13 </ins> | LL |     s.f(|p| p) |          -- ^ returning this value requires that `'1` must outlive `'2` |          || |          |return type of closure is &'2 i32 |          has type `&'1 i32` <ins> | help: dereference the return value | LL |     s.f(|p| *p) |             + </ins> error: aborting due to 1 previous error


Question: The for that function state (emphasis mine) However, the way this function gets called does not ensure that the alignment is at least the size of a word. Cc (discovered by failing CI in )

cfg_if::cfg_if! { if #[cfg(any( target_os = "android", <del> target_os = "illumos", </del> target_os = "redox", <del> target_os = "solaris", </del> target_os = "espidf", target_os = "horizon", target_os = "vita",


Question:
This crashes with every edition except 2015 :thinking: <!-- ICE: Rustc '-Zunstable-options --edition=2024 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'assertion failed: ().isnone()'', 'thread 'rustc' panicked at 'assertion failed: ().isnone()'' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [resolverforlowering_raw] getting the resolver for lowering --
Minimized:
:sweatsmile: while the "minimized" example is fixed, my original finding still crashes :upsidedown_face: cc in case you would like to have a look again

let Some(module) = single_import.imported_module.get() else { return Err((Undetermined, Weak::No)); }; <del> let ImportKind::Single { source: ident, source_bindings, .. } = &single_import.kind </del> <ins> let ImportKind::Single { source: ident, target, target_bindings, .. } = &single_import.kind </ins> else { unreachable!(); }; <del> if binding.map_or(false, |binding| binding.module().is_some()) && source_bindings.iter().all(|binding| matches!(binding.get(), Err(Undetermined))) { // This branch allows the binding to be defined or updated later, </del> <ins> if (ident != target) && target_bindings.iter().all(|binding| binding.get().is_none()) { // This branch allows the binding to be defined or updated later if the target name // can hide the source but these bindings are not obtained. </ins> // avoiding module inconsistency between the resolve process and the finalize process. // See more details in #124840 return Err((Undetermined, Weak::No));


Question:
This crashes with every edition except 2015 :thinking: <!-- ICE: Rustc '-Zunstable-options --edition=2024 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'assertion failed: ().isnone()'', 'thread 'rustc' panicked at 'assertion failed: ().isnone()'' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [resolverforlowering_raw] getting the resolver for lowering --
Minimized:
:sweatsmile: while the "minimized" example is fixed, my original finding still crashes :upsidedown_face: cc in case you would like to have a look again

<ins> //@ edition: 2018 // https://github.com/rust-lang/rust/issues/124490 use ops::{self as std}; //~^ ERROR: unresolved import `ops` use std::collections::{self as ops}; fn main() {} </ins>


Question:
This crashes with every edition except 2015 :thinking: <!-- ICE: Rustc '-Zunstable-options --edition=2024 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'assertion failed: ().isnone()'', 'thread 'rustc' panicked at 'assertion failed: ().isnone()'' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [resolverforlowering_raw] getting the resolver for lowering --
Minimized:
:sweatsmile: while the "minimized" example is fixed, my original finding still crashes :upsidedown_face: cc in case you would like to have a look again

<ins> error[E0432]: unresolved import `ops` --> $DIR/cycle-import-in-std-1.rs:5:11 | LL | use ops::{self as std}; |           ^^^^^^^^^^^ no external crate `ops` | = help: consider importing one of these items instead: core::ops std::ops error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0432`. </ins>


Question:
This crashes with every edition except 2015 :thinking: <!-- ICE: Rustc '-Zunstable-options --edition=2024 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'assertion failed: ().isnone()'', 'thread 'rustc' panicked at 'assertion failed: ().isnone()'' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [resolverforlowering_raw] getting the resolver for lowering --
Minimized:
:sweatsmile: while the "minimized" example is fixed, my original finding still crashes :upsidedown_face: cc in case you would like to have a look again

<ins> //@ edition: 2018 // https://github.com/rust-lang/rust/issues/125013 use ops::{self as std}; //~^ ERROR: unresolved import `ops` use std::ops::Deref::{self as ops}; fn main() {} </ins>


Question:
This crashes with every edition except 2015 :thinking: <!-- ICE: Rustc '-Zunstable-options --edition=2024 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'assertion failed: ().isnone()'', 'thread 'rustc' panicked at 'assertion failed: ().isnone()'' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [resolverforlowering_raw] getting the resolver for lowering --
Minimized:
:sweatsmile: while the "minimized" example is fixed, my original finding still crashes :upsidedown_face: cc in case you would like to have a look again

<ins> error[E0432]: unresolved import `ops` --> $DIR/cycle-import-in-std-2.rs:5:11 | LL | use ops::{self as std}; |           ^^^^^^^^^^^ no external crate `ops` | = help: consider importing one of these items instead: core::ops std::ops error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0432`. </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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
rustc repro:
This ^ bisects to cc
This likely exposed a preexisting bug in cc previously was silently bailing when it couldn't deref a type it expected to be able to deref.
is most likely going to be removed, but this also reproduces with edition 2024 and : claim

use rustc_hir::def::{CtorOf, Res}; use rustc_hir::def_id::LocalDefId; use rustc_hir::{HirId, PatKind}; <del> use rustc_middle::{bug, span_bug}; </del> use rustc_middle::hir::place::ProjectionKind; use rustc_middle::mir::FakeReadCause; use rustc_middle::ty::{ self, adjustment, AdtKind, Ty, TyCtxt, TypeFoldable, TypeVisitableExt as _, }; <ins> use rustc_middle::{bug, span_bug}; </ins> use rustc_span::{ErrorGuaranteed, Span}; use rustc_target::abi::{FieldIdx, VariantIdx, FIRST_VARIANT}; use rustc_trait_selection::infer::InferCtxtExt;


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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
rustc repro:
This ^ bisects to cc
This likely exposed a preexisting bug in cc previously was silently bailing when it couldn't deref a type it expected to be able to deref.
is most likely going to be removed, but this also reproduces with edition 2024 and : claim

debug!("pat_ty(pat={:?}) found adjusted ty `{:?}`", pat, first_ty); return Ok(*first_ty); } <ins> } else if let PatKind::Ref(subpat, _) = pat.kind && self.cx.typeck_results().skipped_ref_pats().contains(pat.hir_id) { return self.pat_ty_adjusted(subpat); </ins> } self.pat_ty_unadjusted(pat)


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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
rustc repro:
This ^ bisects to cc
This likely exposed a preexisting bug in cc previously was silently bailing when it couldn't deref a type it expected to be able to deref.
is most likely going to be removed, but this also reproduces with edition 2024 and : claim

self.cat_pattern(place_with_id, subpat, op)?; } <ins> PatKind::Ref(subpat, _) if self.cx.typeck_results().skipped_ref_pats().contains(pat.hir_id) => { self.cat_pattern(place_with_id, subpat, op)?; } </ins> PatKind::Box(subpat) | PatKind::Ref(subpat, _) => { // box p1, &p1, &mut p1. we can ignore the mutability of // PatKind::Ref since that information is already contained


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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
rustc repro:
This ^ bisects to cc
This likely exposed a preexisting bug in cc previously was silently bailing when it couldn't deref a type it expected to be able to deref.
is most likely going to be removed, but this also reproduces with edition 2024 and : claim

<ins> //@ run-pass //@ edition: 2024 //@ compile-flags: -Zunstable-options #![allow(incomplete_features)] #![feature(ref_pat_eat_one_layer_2024)] struct Foo; //~^ WARN struct `Foo` is never constructed fn main() { || { //~^ WARN unused closure that must be used if let Some(Some(&mut x)) = &mut Some(&mut Some(0)) { let _: u32 = x; } }; } </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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
rustc repro:
This ^ bisects to cc
This likely exposed a preexisting bug in cc previously was silently bailing when it couldn't deref a type it expected to be able to deref.
is most likely going to be removed, but this also reproduces with edition 2024 and : claim

<ins> warning: struct `Foo` is never constructed --> $DIR/skipped-ref-pats-issue-125058.rs:8:8 | LL | struct Foo; |        ^^^ | = note: `#[warn(dead_code)]` on by default warning: unused closure that must be used --> $DIR/skipped-ref-pats-issue-125058.rs:12:5 | LL | /     || { LL | | LL | |         if let Some(Some(&mut x)) = &mut Some(&mut Some(0)) { LL | |             let _: u32 = x; LL | |         } LL | |     }; | |_____^ | = note: closures are lazy and do nothing unless called = note: `#[warn(unused_must_use)]` on by default warning: 2 warnings emitted </ins>