jiebi/CodeConvo huggingface dataset:
Code change:
When running with the above code, the docs list the following items: <details<summaryDocs</summary </detailsI would expect to be listed as a reexport, not a struct. The way it is now, it looks like and are different types, which is not the case. If is made , everything looks as it's supposed to. label +T-rustdoc
It's the intended behaviour. Since the module is private, is inlining the item into .
Yes, but is public, so should it really be inlined a second time?
Ok sorry I misunderstood what you meant. No, it shouldn't be inlined a second time.

Related discussion:
text: renamed: Option<Symbol>, glob: bool, please_inline: bool, <ins> path: &hir::UsePath<'_>, </ins> ) -> bool { debug!("maybe_inline_local res: {:?}", res);
Code change:
When running with the above code, the docs list the following items: <details<summaryDocs</summary </detailsI would expect to be listed as a reexport, not a struct. The way it is now, it looks like and are different types, which is not the case. If is made , everything looks as it's supposed to. label +T-rustdoc
It's the intended behaviour. Since the module is private, is inlining the item into .
Yes, but is public, so should it really be inlined a second time?
Ok sorry I misunderstood what you meant. No, it shouldn't be inlined a second time.

Related discussion:
text: return false; } <ins> if !please_inline && let mut visitor = OneLevelVisitor::new(self.cx.tcx.hir(), res_did) && let Some(item) = visitor.find_target(self.cx.tcx, def_id.to_def_id(), path) && let item_def_id = item.owner_id.def_id && item_def_id != def_id && self .cx .cache .effective_visibilities .is_directly_public(self.cx.tcx, item_def_id.to_def_id()) && !inherits_doc_hidden(self.cx.tcx, item_def_id) { // The imported item is public and not `doc(hidden)` so no need to inline it. return false; } </ins> let ret = match tcx.hir().get_by_def_id(res_did) { Node::Item(&hir::Item { kind: hir::ItemKind::Mod(ref m), .. }) if glob => { let prev = mem::replace(&mut self.inlining, true);
Code change:
When running with the above code, the docs list the following items: <details<summaryDocs</summary </detailsI would expect to be listed as a reexport, not a struct. The way it is now, it looks like and are different types, which is not the case. If is made , everything looks as it's supposed to. label +T-rustdoc
It's the intended behaviour. Since the module is private, is inlining the item into .
Yes, but is public, so should it really be inlined a second time?
Ok sorry I misunderstood what you meant. No, it shouldn't be inlined a second time.

Related discussion:
text: ident, is_glob, please_inline, <ins> path, </ins> ) { continue; }
Code change:
When running with the above code, the docs list the following items: <details<summaryDocs</summary </detailsI would expect to be listed as a reexport, not a struct. The way it is now, it looks like and are different types, which is not the case. If is made , everything looks as it's supposed to. label +T-rustdoc
It's the intended behaviour. Since the module is private, is inlining the item into .
Yes, but is public, so should it really be inlined a second time?
Ok sorry I misunderstood what you meant. No, it shouldn't be inlined a second time.

Related discussion:
text: <ins> // This test ensures that the `struct.B.html` only exists in `a`: // since `a::B` is public (and inlined too), `self::a::B` doesn't // need to be inlined as well. #![crate_name = "foo"] pub mod a { // @has 'foo/a/index.html' // Should only contain "Structs". // @count - '//*[@id="main-content"]//*[@class="item-table"]' 1 // @has - '//*[@id="structs"]' 'Structs' // @has - '//*[@id="main-content"]//a[@href="struct.A.html"]' 'A' // @has - '//*[@id="main-content"]//a[@href="struct.B.html"]' 'B' mod b { pub struct B; } pub use self::b::B; pub struct A; } // @has 'foo/index.html' // @!has - '//*[@id="structs"]' 'Structs' // @has - '//*[@id="reexports"]' 'Re-exports' // @has - '//*[@id="modules"]' 'Modules' // @has - '//*[@id="main-content"]//*[@id="reexport.A"]' 'pub use self::a::A;' // @has - '//*[@id="main-content"]//*[@id="reexport.B"]' 'pub use self::a::B;' // Should only contain "Modules" and "Re-exports". // @count - '//*[@id="main-content"]//*[@class="item-table"]' 2 pub use self::a::{A, B}; </ins>
Code change:
<!-- 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 --
searched nightlies: from nightly-2023-01-01 to nightly-2023-03-11 regressed nightly: nightly-2023-03-09 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailscc
This is "due" to , but probably needs to be passed through silently in the canonicalization code.
reduced via treereduce `
I'd argue that repro is worse than the one provided at the top of the issue, even if it's a few bytes shorter. It introduces a bit of superfluous syntax/unnecessary syntax errors. Here's a denser minimization that avoids the syntax errors (except for the one that actually is the root-cause of the issue):
haha, the original snipped looked like this but I though it looked a little too weird :)
claim
Sorry for the off-topic comment: In response to this feedback I made a wrapper for treereduce that avoids introducing unrelated issues. It also runs for you (when it doesn't remove the ICE), and can output a nice Markdown comment with the reduced program.

Related discussion:
text: r: ty::Region<'tcx>, ) -> ty::Region<'tcx> { match *r { <del> ty::ReEarlyBound(_) | ty::ReFree(_) | ty::ReErased | ty::ReStatic => r, </del> <ins> ty::ReEarlyBound(_) | ty::ReFree(_) | ty::ReErased | ty::ReStatic | ty::ReError(_) => r, </ins> ty::ReVar(_) => canonicalizer.canonical_var_for_region_in_root_universe(r), <del> _ => { </del> <ins> ty::RePlaceholder(..) | ty::ReLateBound(..) => { </ins> // We only expect region names that the user can type. bug!("unexpected region in query response: `{:?}`", r) }
Code change:
<!-- 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 --
searched nightlies: from nightly-2023-01-01 to nightly-2023-03-11 regressed nightly: nightly-2023-03-09 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailscc
This is "due" to , but probably needs to be passed through silently in the canonicalization code.
reduced via treereduce `
I'd argue that repro is worse than the one provided at the top of the issue, even if it's a few bytes shorter. It introduces a bit of superfluous syntax/unnecessary syntax errors. Here's a denser minimization that avoids the syntax errors (except for the one that actually is the root-cause of the issue):
haha, the original snipped looked like this but I though it looked a little too weird :)
claim
Sorry for the off-topic comment: In response to this feedback I made a wrapper for treereduce that avoids introducing unrelated issues. It also runs for you (when it doesn't remove the ICE), and can output a nice Markdown comment with the reduced program.

Related discussion:
text: <ins> // Regression test for #109072. // Check that we don't ICE when canonicalizing user annotation. trait Lt<'a> { type T; } impl Lt<'missing> for () { //~ ERROR undeclared lifetime type T = &'missing (); //~ ERROR undeclared lifetime } fn main() { let _: <() as Lt<'_>>::T = &(); } </ins>
Code change:
<!-- 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 --
searched nightlies: from nightly-2023-01-01 to nightly-2023-03-11 regressed nightly: nightly-2023-03-09 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailscc
This is "due" to , but probably needs to be passed through silently in the canonicalization code.
reduced via treereduce `
I'd argue that repro is worse than the one provided at the top of the issue, even if it's a few bytes shorter. It introduces a bit of superfluous syntax/unnecessary syntax errors. Here's a denser minimization that avoids the syntax errors (except for the one that actually is the root-cause of the issue):
haha, the original snipped looked like this but I though it looked a little too weird :)
claim
Sorry for the off-topic comment: In response to this feedback I made a wrapper for treereduce that avoids introducing unrelated issues. It also runs for you (when it doesn't remove the ICE), and can output a nice Markdown comment with the reduced program.

Related discussion:
text: <ins> error[E0261]: use of undeclared lifetime name `'missing` --> $DIR/region-error-ice-109072.rs:8:9 | LL | impl Lt<'missing> for () { |     -   ^^^^^^^^ undeclared lifetime |     | |     help: consider introducing lifetime `'missing` here: `<'missing>` error[E0261]: use of undeclared lifetime name `'missing` --> $DIR/region-error-ice-109072.rs:9:15 | LL |     type T = &'missing (); |               ^^^^^^^^ undeclared lifetime | help: consider introducing lifetime `'missing` here | LL |     type T<'missing> = &'missing (); |           ++++++++++ help: consider introducing lifetime `'missing` here | LL | impl<'missing> Lt<'missing> for () { |     ++++++++++ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0261`. </ins>
Code change:
or perhaps The bad help isn't related to the choice of or (even though the former needs to be followed by to be a statement and the latter doesn't, which could explain the source of the hint); also generates the help to add . %20%3D%3E%20%7B%3B%7D%3B%0A%7D%0A%0Afn%20main()%20%7B%0A%20%20%20%20let%20%20%3D%20statement!()%3B%0A%7D%0A) No response modify labels +D-incorrect <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

Related discussion:
text: e.note( "the macro call doesn't expand to an expression, but it can expand to a statement", ); <del> e.span_suggestion_verbose( site_span.shrink_to_hi(), "add `;` to interpret the expansion as a statement", ";", Applicability::MaybeIncorrect, ); </del> <ins> if parser.token == token::Semi { if let Ok(snippet) = parser.sess.source_map().span_to_snippet(site_span) { e.span_suggestion_verbose( site_span, "surround the macro invocation with `{}` to interpret the expansion as a statement", format!("{{ {}; }}", snippet), Applicability::MaybeIncorrect, ); } } else { e.span_suggestion_verbose( site_span.shrink_to_hi(), "add `;` to interpret the expansion as a statement", ";", Applicability::MaybeIncorrect, ); } </ins> } }, _ => annotate_err_with_kind(&mut e, kind, site_span),
Code change:
or perhaps The bad help isn't related to the choice of or (even though the former needs to be followed by to be a statement and the latter doesn't, which could explain the source of the hint); also generates the help to add . %20%3D%3E%20%7B%3B%7D%3B%0A%7D%0A%0Afn%20main()%20%7B%0A%20%20%20%20let%20%20%3D%20statement!()%3B%0A%7D%0A) No response modify labels +D-incorrect <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

Related discussion:
text: <ins> macro_rules! statement { () => {;}; //~ ERROR expected expression } fn main() { let _ = statement!(); } </ins>
Code change:
or perhaps The bad help isn't related to the choice of or (even though the former needs to be followed by to be a statement and the latter doesn't, which could explain the source of the hint); also generates the help to add . %20%3D%3E%20%7B%3B%7D%3B%0A%7D%0A%0Afn%20main()%20%7B%0A%20%20%20%20let%20%20%3D%20statement!()%3B%0A%7D%0A) No response modify labels +D-incorrect <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

Related discussion:
text: <ins> error: expected expression, found `;` --> $DIR/issue-109237.rs:2:12 | LL |     () => {;}; |            ^ expected expression ... LL |     let _ = statement!(); |             ------------ in this macro invocation | = note: the macro call doesn't expand to an expression, but it can expand to a statement = note: this error originates in the macro `statement` (in Nightly builds, run with -Z macro-backtrace for more info) help: surround the macro invocation with `{}` to interpret the expansion as a statement | LL |     let _ = { statement!(); }; |             ~~~~~~~~~~~~~~~~~ error: aborting due to previous error </ins>
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Regression in searched nightlies: from nightly-2023-03-10 to nightly-2023-03-18 regressed nightly: nightly-2023-03-12 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
We relate with during codegen when selecting an impl which now eagerly returns without constraining to anything wheras previously it would have been instantiated with . This then results in codegen returning an impl with in the substs from a query
output on beta/stable:
WG-prioritization assigning priority (). label -I-prioritize +P-medium

Related discussion:
text: // the expected const's type. Specifically, we don't want const infer vars // to do any type shapeshifting before and after resolution. if let Err(guar) = compatible_types { <del> return Ok(self.tcx.const_error_with_guaranteed( if relation.a_is_expected() { a.ty() } else { b.ty() }, guar, )); </del> <ins> // HACK: equating both sides with `[const error]` eagerly prevents us // from leaving unconstrained inference vars during things like impl // matching in the solver. let a_error = self.tcx.const_error_with_guaranteed(a.ty(), guar); if let ty::ConstKind::Infer(InferConst::Var(vid)) = a.kind() { return self.unify_const_variable(vid, a_error); } let b_error = self.tcx.const_error_with_guaranteed(b.ty(), guar); if let ty::ConstKind::Infer(InferConst::Var(vid)) = b.kind() { return self.unify_const_variable(vid, b_error); } return Ok(if relation.a_is_expected() { a_error } else { b_error }); </ins> } match (a.kind(), b.kind()) {
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Regression in searched nightlies: from nightly-2023-03-10 to nightly-2023-03-18 regressed nightly: nightly-2023-03-12 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
We relate with during codegen when selecting an impl which now eagerly returns without constraining to anything wheras previously it would have been instantiated with . This then results in codegen returning an impl with in the substs from a query
output on beta/stable:
WG-prioritization assigning priority (). label -I-prioritize +P-medium

Related discussion:
text: use rustc_data_structures::fx::FxIndexSet; use rustc_errors::{error_code, DelayDm, Diagnostic}; use rustc_hir::def_id::{DefId, LocalDefId}; <del> use rustc_middle::ty::{self, ImplSubject, Ty, TyCtxt}; </del> <ins> use rustc_middle::ty::{self, ImplSubject, Ty, TyCtxt, TypeVisitableExt}; </ins> use rustc_middle::ty::{InternalSubsts, SubstsRef}; use rustc_session::lint::builtin::COHERENCE_LEAK_CHECK; use rustc_session::lint::builtin::ORDER_DEPENDENT_TRAIT_OBJECTS;
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Regression in searched nightlies: from nightly-2023-03-10 to nightly-2023-03-18 regressed nightly: nightly-2023-03-12 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
We relate with during codegen when selecting an impl which now eagerly returns without constraining to anything wheras previously it would have been instantiated with . This then results in codegen returning an impl with in the substs from a query
output on beta/stable:
WG-prioritization assigning priority (). label -I-prioritize +P-medium

Related discussion:
text: impl_span: Span, err: &mut Diagnostic, ) { <ins> if (overlap.trait_ref, overlap.self_ty).references_error() { err.downgrade_to_delayed_bug(); } </ins> match tcx.span_of_impl(overlap.with_impl) { Ok(span) => { err.span_label(span, "first implementation here");
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Regression in searched nightlies: from nightly-2023-03-10 to nightly-2023-03-18 regressed nightly: nightly-2023-03-12 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
We relate with during codegen when selecting an impl which now eagerly returns without constraining to anything wheras previously it would have been instantiated with . This then results in codegen returning an impl with in the substs from a query
output on beta/stable:
WG-prioritization assigning priority (). label -I-prioritize +P-medium

Related discussion:
text: <ins> // incremental #![crate_type = "lib"] trait Q { const ASSOC: usize; } impl<const N: u64> Q for [u8; N] { //~^ ERROR mismatched types const ASSOC: usize = 1; } pub fn test() -> [u8; <[u8; 13] as Q>::ASSOC] { todo!() } </ins>
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Regression in searched nightlies: from nightly-2023-03-10 to nightly-2023-03-18 regressed nightly: nightly-2023-03-12 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
We relate with during codegen when selecting an impl which now eagerly returns without constraining to anything wheras previously it would have been instantiated with . This then results in codegen returning an impl with in the substs from a query
output on beta/stable:
WG-prioritization assigning priority (). label -I-prioritize +P-medium

Related discussion:
text: <ins> error[E0308]: mismatched types --> $DIR/bad-subst-const-kind.rs:8:31 | LL | impl<const N: u64> Q for [u8; N] { |                               ^ expected `usize`, found `u64` error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Regression in searched nightlies: from nightly-2023-03-10 to nightly-2023-03-18 regressed nightly: nightly-2023-03-12 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
We relate with during codegen when selecting an impl which now eagerly returns without constraining to anything wheras previously it would have been instantiated with . This then results in codegen returning an impl with in the substs from a query
output on beta/stable:
WG-prioritization assigning priority (). label -I-prioritize +P-medium

Related discussion:
text: // An impl that has an erroneous const substitution should not specialize one // that is well-formed. <ins> #[derive(Clone)] </ins> struct S<const L: usize>; impl<const N: i32> Copy for S<N> {} <ins> //~^ ERROR the constant `N` is not of type `usize` </ins> impl<const M: usize> Copy for S<M> {} <del> //~^ ERROR conflicting implementations of trait `Copy` for type `S<_>` </del> fn main() {}