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
Minimized a bit more:
It started ICE-ing in 1.41.0:
This compiles successfully without the bound. It also compiles if you change the bound to constrain the associated type:
I bisected it to be between and : I've tried to bisect between these commits, but I'm getting a compilation error in llvm.
It'll be , which changed the coherence rules to allow . The impl in this code is intentionally allowed under the new rules and should be fine, so it didn't really regress in that PR so much as it was newly permitted but likely surfaced a pre-existing bug. I tried to replicate this issue with a local trait but compiles successfully, so this does seem to involve the built-in trait and operator (the error message complains about the MIR statement which is a built-in index).
Further reduced to: , but not on 1.24.0 I agree with assessment:
So it could be considered a stable-to-stable regression? I don't how or who could add this label.
Yeah, I guess we could modify labels +regression-from-stable-to-stable although it's a regression from a very old stable
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium

<ins> // compile-flags: -Z mir-opt-level=0 // EMIT_MIR issue_91633.hey.mir_map.0.mir fn hey<T> (it: &[T]) where [T] : std::ops::Index<usize>, { let _ = &it[0]; } // EMIT_MIR issue_91633.bar.mir_map.0.mir fn bar<T> (it: Box<[T]>) where [T] : std::ops::Index<usize>, { let _ = it[0]; } // EMIT_MIR issue_91633.fun.mir_map.0.mir fn fun<T> (it: &[T]) -> &T { let f = &it[0]; f } // EMIT_MIR issue_91633.foo.mir_map.0.mir fn foo<T: Clone> (it: Box<[T]>) -> T { let f = it[0].clone(); f } fn main(){} </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Minimized a bit more:
It started ICE-ing in 1.41.0:
This compiles successfully without the bound. It also compiles if you change the bound to constrain the associated type:
I bisected it to be between and : I've tried to bisect between these commits, but I'm getting a compilation error in llvm.
It'll be , which changed the coherence rules to allow . The impl in this code is intentionally allowed under the new rules and should be fine, so it didn't really regress in that PR so much as it was newly permitted but likely surfaced a pre-existing bug. I tried to replicate this issue with a local trait but compiles successfully, so this does seem to involve the built-in trait and operator (the error message complains about the MIR statement which is a built-in index).
Further reduced to: , but not on 1.24.0 I agree with assessment:
So it could be considered a stable-to-stable regression? I don't how or who could add this label.
Yeah, I guess we could modify labels +regression-from-stable-to-stable although it's a regression from a very old stable
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium

<ins> // MIR for `bar` 0 mir_map fn bar(_1: Box<[T]>) -> () { debug it => _1;                      // in scope 0 at $DIR/issue-91633.rs:+0:12: +0:14 let mut _0: ();                      // return place in scope 0 at $DIR/issue-91633.rs:+1:2: +1:2 let mut _2: &<[T] as std::ops::Index<usize>>::Output; // in scope 0 at $DIR/issue-91633.rs:+4:14: +4:19 let mut _3: &[T];                    // in scope 0 at $DIR/issue-91633.rs:+4:14: +4:16 scope 1 { } bb0: { StorageLive(_2);                 // scope 0 at $DIR/issue-91633.rs:+4:14: +4:19 StorageLive(_3);                 // scope 0 at $DIR/issue-91633.rs:+4:14: +4:16 _3 = &(*_1);                     // scope 0 at $DIR/issue-91633.rs:+4:14: +4:16 _2 = <[T] as Index<usize>>::index(move _3, const 0_usize) -> [return: bb1, unwind: bb3]; // scope 0 at $DIR/issue-91633.rs:+4:14: +4:19 // mir::Constant // + span: $DIR/issue-91633.rs:15:14: 15:19 // + literal: Const { ty: for<'r> fn(&'r [T], usize) -> &'r <[T] as Index<usize>>::Output {<[T] as Index<usize>>::index}, val: Value(<ZST>) } } bb1: { StorageDead(_3);                 // scope 0 at $DIR/issue-91633.rs:+4:18: +4:19 StorageDead(_2);                 // scope 0 at $DIR/issue-91633.rs:+4:19: +4:20 _0 = const ();                   // scope 0 at $DIR/issue-91633.rs:+3:2: +5:3 drop(_1) -> [return: bb2, unwind: bb4]; // scope 0 at $DIR/issue-91633.rs:+5:2: +5:3 } bb2: { return;                          // scope 0 at $DIR/issue-91633.rs:+5:3: +5:3 } bb3 (cleanup): { drop(_1) -> bb4;                 // scope 0 at $DIR/issue-91633.rs:+5:2: +5:3 } bb4 (cleanup): { resume;                          // scope 0 at $DIR/issue-91633.rs:+0:1: +5:3 } } </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
Minimized a bit more:
It started ICE-ing in 1.41.0:
This compiles successfully without the bound. It also compiles if you change the bound to constrain the associated type:
I bisected it to be between and : I've tried to bisect between these commits, but I'm getting a compilation error in llvm.
It'll be , which changed the coherence rules to allow . The impl in this code is intentionally allowed under the new rules and should be fine, so it didn't really regress in that PR so much as it was newly permitted but likely surfaced a pre-existing bug. I tried to replicate this issue with a local trait but compiles successfully, so this does seem to involve the built-in trait and operator (the error message complains about the MIR statement which is a built-in index).
Further reduced to: , but not on 1.24.0 I agree with assessment:
So it could be considered a stable-to-stable regression? I don't how or who could add this label.
Yeah, I guess we could modify labels +regression-from-stable-to-stable although it's a regression from a very old stable
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium

<ins> // MIR for `foo` 0 mir_map fn foo(_1: Box<[T]>) -> T { debug it => _1;                      // in scope 0 at $DIR/issue-91633.rs:+0:19: +0:21 let mut _0: T;                       // return place in scope 0 at $DIR/issue-91633.rs:+0:36: +0:37 let _2: T;                           // in scope 0 at $DIR/issue-91633.rs:+2:10: +2:11 let mut _3: &T;                      // in scope 0 at $DIR/issue-91633.rs:+2:14: +2:27 let _4: usize;                       // in scope 0 at $DIR/issue-91633.rs:+2:17: +2:18 let mut _5: usize;                   // in scope 0 at $DIR/issue-91633.rs:+2:14: +2:19 let mut _6: bool;                    // in scope 0 at $DIR/issue-91633.rs:+2:14: +2:19 scope 1 { debug f => _2;                   // in scope 1 at $DIR/issue-91633.rs:+2:10: +2:11 } bb0: { StorageLive(_2);                 // scope 0 at $DIR/issue-91633.rs:+2:10: +2:11 StorageLive(_3);                 // scope 0 at $DIR/issue-91633.rs:+2:14: +2:27 StorageLive(_4);                 // scope 0 at $DIR/issue-91633.rs:+2:17: +2:18 _4 = const 0_usize;              // scope 0 at $DIR/issue-91633.rs:+2:17: +2:18 _5 = Len((*_1));                 // scope 0 at $DIR/issue-91633.rs:+2:14: +2:19 _6 = Lt(_4, _5);                 // scope 0 at $DIR/issue-91633.rs:+2:14: +2:19 assert(move _6, "index out of bounds: the length is {} but the index is {}", move _5, _4) -> [success: bb1, unwind: bb5]; // scope 0 at $DIR/issue-91633.rs:+2:14: +2:19 } bb1: { _3 = &(*_1)[_4];                 // scope 0 at $DIR/issue-91633.rs:+2:14: +2:27 _2 = <T as Clone>::clone(move _3) -> [return: bb2, unwind: bb5]; // scope 0 at $DIR/issue-91633.rs:+2:14: +2:27 // mir::Constant // + span: $DIR/issue-91633.rs:28:20: 28:25 // + literal: Const { ty: for<'r> fn(&'r T) -> T {<T as Clone>::clone}, val: Value(<ZST>) } } bb2: { StorageDead(_3);                 // scope 0 at $DIR/issue-91633.rs:+2:26: +2:27 FakeRead(ForLet(None), _2);      // scope 0 at $DIR/issue-91633.rs:+2:10: +2:11 StorageDead(_4);                 // scope 0 at $DIR/issue-91633.rs:+2:27: +2:28 _0 = move _2;                    // scope 1 at $DIR/issue-91633.rs:+3:6: +3:7 drop(_2) -> [return: bb3, unwind: bb5]; // scope 0 at $DIR/issue-91633.rs:+4:2: +4:3 } bb3: { StorageDead(_2);                 // scope 0 at $DIR/issue-91633.rs:+4:2: +4:3 drop(_1) -> [return: bb4, unwind: bb6]; // scope 0 at $DIR/issue-91633.rs:+4:2: +4:3 } bb4: { return;                          // scope 0 at $DIR/issue-91633.rs:+4:3: +4:3 } bb5 (cleanup): { drop(_1) -> bb6;                 // scope 0 at $DIR/issue-91633.rs:+4:2: +4:3 } bb6 (cleanup): { resume;                          // scope 0 at $DIR/issue-91633.rs:+0:1: +4:3 } } </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
Minimized a bit more:
It started ICE-ing in 1.41.0:
This compiles successfully without the bound. It also compiles if you change the bound to constrain the associated type:
I bisected it to be between and : I've tried to bisect between these commits, but I'm getting a compilation error in llvm.
It'll be , which changed the coherence rules to allow . The impl in this code is intentionally allowed under the new rules and should be fine, so it didn't really regress in that PR so much as it was newly permitted but likely surfaced a pre-existing bug. I tried to replicate this issue with a local trait but compiles successfully, so this does seem to involve the built-in trait and operator (the error message complains about the MIR statement which is a built-in index).
Further reduced to: , but not on 1.24.0 I agree with assessment:
So it could be considered a stable-to-stable regression? I don't how or who could add this label.
Yeah, I guess we could modify labels +regression-from-stable-to-stable although it's a regression from a very old stable
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium

<ins> // MIR for `fun` 0 mir_map fn fun(_1: &[T]) -> &T { debug it => _1;                      // in scope 0 at $DIR/issue-91633.rs:+0:12: +0:14 let mut _0: &T;                      // return place in scope 0 at $DIR/issue-91633.rs:+0:25: +0:27 let _2: &T;                          // in scope 0 at $DIR/issue-91633.rs:+2:10: +2:11 let _3: usize;                       // in scope 0 at $DIR/issue-91633.rs:+2:18: +2:19 let mut _4: usize;                   // in scope 0 at $DIR/issue-91633.rs:+2:15: +2:20 let mut _5: bool;                    // in scope 0 at $DIR/issue-91633.rs:+2:15: +2:20 scope 1 { debug f => _2;                   // in scope 1 at $DIR/issue-91633.rs:+2:10: +2:11 } bb0: { StorageLive(_2);                 // scope 0 at $DIR/issue-91633.rs:+2:10: +2:11 StorageLive(_3);                 // scope 0 at $DIR/issue-91633.rs:+2:18: +2:19 _3 = const 0_usize;              // scope 0 at $DIR/issue-91633.rs:+2:18: +2:19 _4 = Len((*_1));                 // scope 0 at $DIR/issue-91633.rs:+2:15: +2:20 _5 = Lt(_3, _4);                 // scope 0 at $DIR/issue-91633.rs:+2:15: +2:20 assert(move _5, "index out of bounds: the length is {} but the index is {}", move _4, _3) -> [success: bb1, unwind: bb2]; // scope 0 at $DIR/issue-91633.rs:+2:15: +2:20 } bb1: { _2 = &(*_1)[_3];                 // scope 0 at $DIR/issue-91633.rs:+2:14: +2:20 FakeRead(ForLet(None), _2);      // scope 0 at $DIR/issue-91633.rs:+2:10: +2:11 _0 = &(*_2);                     // scope 1 at $DIR/issue-91633.rs:+3:6: +3:7 StorageDead(_3);                 // scope 0 at $DIR/issue-91633.rs:+4:2: +4:3 StorageDead(_2);                 // scope 0 at $DIR/issue-91633.rs:+4:2: +4:3 return;                          // scope 0 at $DIR/issue-91633.rs:+4:3: +4:3 } bb2 (cleanup): { resume;                          // scope 0 at $DIR/issue-91633.rs:+0:1: +4:3 } } </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
Minimized a bit more:
It started ICE-ing in 1.41.0:
This compiles successfully without the bound. It also compiles if you change the bound to constrain the associated type:
I bisected it to be between and : I've tried to bisect between these commits, but I'm getting a compilation error in llvm.
It'll be , which changed the coherence rules to allow . The impl in this code is intentionally allowed under the new rules and should be fine, so it didn't really regress in that PR so much as it was newly permitted but likely surfaced a pre-existing bug. I tried to replicate this issue with a local trait but compiles successfully, so this does seem to involve the built-in trait and operator (the error message complains about the MIR statement which is a built-in index).
Further reduced to: , but not on 1.24.0 I agree with assessment:
So it could be considered a stable-to-stable regression? I don't how or who could add this label.
Yeah, I guess we could modify labels +regression-from-stable-to-stable although it's a regression from a very old stable
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium

<ins> // MIR for `hey` 0 mir_map fn hey(_1: &[T]) -> () { debug it => _1;                      // in scope 0 at $DIR/issue-91633.rs:+0:12: +0:14 let mut _0: ();                      // return place in scope 0 at $DIR/issue-91633.rs:+1:2: +1:2 let mut _2: &<[T] as std::ops::Index<usize>>::Output; // in scope 0 at $DIR/issue-91633.rs:+4:14: +4:20 let _3: &<[T] as std::ops::Index<usize>>::Output; // in scope 0 at $DIR/issue-91633.rs:+4:15: +4:20 let mut _4: &[T];                    // in scope 0 at $DIR/issue-91633.rs:+4:15: +4:17 scope 1 { } bb0: { StorageLive(_2);                 // scope 0 at $DIR/issue-91633.rs:+4:14: +4:20 StorageLive(_3);                 // scope 0 at $DIR/issue-91633.rs:+4:15: +4:20 StorageLive(_4);                 // scope 0 at $DIR/issue-91633.rs:+4:15: +4:17 _4 = &(*_1);                     // scope 0 at $DIR/issue-91633.rs:+4:15: +4:17 _3 = <[T] as Index<usize>>::index(move _4, const 0_usize) -> [return: bb1, unwind: bb2]; // scope 0 at $DIR/issue-91633.rs:+4:15: +4:20 // mir::Constant // + span: $DIR/issue-91633.rs:7:15: 7:20 // + literal: Const { ty: for<'r> fn(&'r [T], usize) -> &'r <[T] as Index<usize>>::Output {<[T] as Index<usize>>::index}, val: Value(<ZST>) } } bb1: { StorageDead(_4);                 // scope 0 at $DIR/issue-91633.rs:+4:19: +4:20 _2 = &(*_3);                     // scope 0 at $DIR/issue-91633.rs:+4:14: +4:20 StorageDead(_2);                 // scope 0 at $DIR/issue-91633.rs:+4:20: +4:21 _0 = const ();                   // scope 0 at $DIR/issue-91633.rs:+3:2: +5:3 StorageDead(_3);                 // scope 0 at $DIR/issue-91633.rs:+5:2: +5:3 return;                          // scope 0 at $DIR/issue-91633.rs:+5:3: +5:3 } bb2 (cleanup): { resume;                          // scope 0 at $DIR/issue-91633.rs:+0:1: +5:3 } } </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
Minimized a bit more:
It started ICE-ing in 1.41.0:
This compiles successfully without the bound. It also compiles if you change the bound to constrain the associated type:
I bisected it to be between and : I've tried to bisect between these commits, but I'm getting a compilation error in llvm.
It'll be , which changed the coherence rules to allow . The impl in this code is intentionally allowed under the new rules and should be fine, so it didn't really regress in that PR so much as it was newly permitted but likely surfaced a pre-existing bug. I tried to replicate this issue with a local trait but compiles successfully, so this does seem to involve the built-in trait and operator (the error message complains about the MIR statement which is a built-in index).
Further reduced to: , but not on 1.24.0 I agree with assessment:
So it could be considered a stable-to-stable regression? I don't how or who could add this label.
Yeah, I guess we could modify labels +regression-from-stable-to-stable although it's a regression from a very old stable
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium

<ins> // check-pass fn f<T> (it: &[T]) where [T] : std::ops::Index<usize>, { let _ = &it[0]; } fn main(){} </ins>


Question:
In the middle of a large refactoring that was mostly automated by rust-analyzer's structural-search-and-replace, I had a lot of qualified paths that shouldn't be qualified. I made do with a regular text-based search-and-replace since I couldn't find a better way, but I think that better way could have been , because introducing an import for the relevant type once per file is much easier than replacing all uses manually. As such, it would be nice if the unnecessary qualification lint had a machine-applicable suggestion attached to it. However, one interesting thing about this is that I also had warnings about the import for that same type being unused. I don't know whether it would be possible with the current compiler infrastructure to create mutually-exclusive suggestions. Either way the suggestion would be helpful, since a simple could disable the automatic removal of the imports.
I second that should be applicable. To fix the violations I almost found and removed the qualified prefix one by one.
Mentoring instructions: Add a new .

db.span_note(glob_reexport_span, format!("the name `{}` in the {} namespace is supposed to be publicly re-exported here", name, namespace)); db.span_note(private_item_span, "but the private item here shadows it".to_owned()); } <ins> BuiltinLintDiagnostics::UnusedQualifications { path_span, unqualified_path } => { db.span_suggestion_verbose( path_span, "replace it with the unqualified path", unqualified_path, Applicability::MachineApplicable ); } </ins> } // Rewrap `db`, and pass control to the user. decorate(db)


Question:
In the middle of a large refactoring that was mostly automated by rust-analyzer's structural-search-and-replace, I had a lot of qualified paths that shouldn't be qualified. I made do with a regular text-based search-and-replace since I couldn't find a better way, but I think that better way could have been , because introducing an import for the relevant type once per file is much easier than replacing all uses manually. As such, it would be nice if the unnecessary qualification lint had a machine-applicable suggestion attached to it. However, one interesting thing about this is that I also had warnings about the import for that same type being unused. I don't know whether it would be possible with the current compiler infrastructure to create mutually-exclusive suggestions. Either way the suggestion would be helpful, since a simple could disable the automatic removal of the imports.
I second that should be applicable. To fix the violations I almost found and removed the qualified prefix one by one.
Mentoring instructions: Add a new .

/// The local binding that shadows the glob reexport. private_item_span: Span, }, <ins> UnusedQualifications { /// The span of the unnecessarily-qualified path. path_span: Span, /// The replacement unqualified path. unqualified_path: Ident, }, </ins> } /// Lints that are buffered up early on in the `Session` before the


Question:
In the middle of a large refactoring that was mostly automated by rust-analyzer's structural-search-and-replace, I had a lot of qualified paths that shouldn't be qualified. I made do with a regular text-based search-and-replace since I couldn't find a better way, but I think that better way could have been , because introducing an import for the relevant type once per file is much easier than replacing all uses manually. As such, it would be nice if the unnecessary qualification lint had a machine-applicable suggestion attached to it. However, one interesting thing about this is that I also had warnings about the import for that same type being unused. I don't know whether it would be possible with the current compiler infrastructure to create mutually-exclusive suggestions. Either way the suggestion would be helpful, since a simple could disable the automatic removal of the imports.
I second that should be applicable. To fix the violations I almost found and removed the qualified prefix one by one.
Mentoring instructions: Add a new .

}; if res == unqualified_result { let lint = lint::builtin::UNUSED_QUALIFICATIONS; <del> self.r.lint_buffer.buffer_lint( </del> <ins> self.r.lint_buffer.buffer_lint_with_diagnostic( </ins> lint, finalize.node_id, finalize.path_span, "unnecessary qualification", <ins> lint::BuiltinLintDiagnostics::UnusedQualifications { path_span: finalize.path_span, unqualified_path: path.last().unwrap().ident } </ins> ) } }


Question:
In the middle of a large refactoring that was mostly automated by rust-analyzer's structural-search-and-replace, I had a lot of qualified paths that shouldn't be qualified. I made do with a regular text-based search-and-replace since I couldn't find a better way, but I think that better way could have been , because introducing an import for the relevant type once per file is much easier than replacing all uses manually. As such, it would be nice if the unnecessary qualification lint had a machine-applicable suggestion attached to it. However, one interesting thing about this is that I also had warnings about the import for that same type being unused. I don't know whether it would be possible with the current compiler infrastructure to create mutually-exclusive suggestions. Either way the suggestion would be helpful, since a simple could disable the automatic removal of the imports.
I second that should be applicable. To fix the violations I almost found and removed the qualified prefix one by one.
Mentoring instructions: Add a new .

| LL | #![deny(unused_qualifications)] |         ^^^^^^^^^^^^^^^^^^^^^ <ins> help: replace it with the unqualified path | LL |     bar(); |     ~~~ </ins> error: aborting due to previous error


Question:
In the middle of a large refactoring that was mostly automated by rust-analyzer's structural-search-and-replace, I had a lot of qualified paths that shouldn't be qualified. I made do with a regular text-based search-and-replace since I couldn't find a better way, but I think that better way could have been , because introducing an import for the relevant type once per file is much easier than replacing all uses manually. As such, it would be nice if the unnecessary qualification lint had a machine-applicable suggestion attached to it. However, one interesting thing about this is that I also had warnings about the import for that same type being unused. I don't know whether it would be possible with the current compiler infrastructure to create mutually-exclusive suggestions. Either way the suggestion would be helpful, since a simple could disable the automatic removal of the imports.
I second that should be applicable. To fix the violations I almost found and removed the qualified prefix one by one.
Mentoring instructions: Add a new .

<ins> // run-rustfix #![deny(unused_qualifications)] mod foo { pub fn bar() {} } mod baz { pub mod qux { pub fn quux() {} } } fn main() { use foo::bar; bar(); //~^ ERROR unnecessary qualification use baz::qux::quux; quux(); //~^ ERROR unnecessary qualification } </ins>


Question:
In the middle of a large refactoring that was mostly automated by rust-analyzer's structural-search-and-replace, I had a lot of qualified paths that shouldn't be qualified. I made do with a regular text-based search-and-replace since I couldn't find a better way, but I think that better way could have been , because introducing an import for the relevant type once per file is much easier than replacing all uses manually. As such, it would be nice if the unnecessary qualification lint had a machine-applicable suggestion attached to it. However, one interesting thing about this is that I also had warnings about the import for that same type being unused. I don't know whether it would be possible with the current compiler infrastructure to create mutually-exclusive suggestions. Either way the suggestion would be helpful, since a simple could disable the automatic removal of the imports.
I second that should be applicable. To fix the violations I almost found and removed the qualified prefix one by one.
Mentoring instructions: Add a new .

<ins> // run-rustfix #![deny(unused_qualifications)] mod foo { pub fn bar() {} } mod baz { pub mod qux { pub fn quux() {} } } fn main() { use foo::bar; foo::bar(); //~^ ERROR unnecessary qualification use baz::qux::quux; baz::qux::quux(); //~^ ERROR unnecessary qualification } </ins>


Question:
In the middle of a large refactoring that was mostly automated by rust-analyzer's structural-search-and-replace, I had a lot of qualified paths that shouldn't be qualified. I made do with a regular text-based search-and-replace since I couldn't find a better way, but I think that better way could have been , because introducing an import for the relevant type once per file is much easier than replacing all uses manually. As such, it would be nice if the unnecessary qualification lint had a machine-applicable suggestion attached to it. However, one interesting thing about this is that I also had warnings about the import for that same type being unused. I don't know whether it would be possible with the current compiler infrastructure to create mutually-exclusive suggestions. Either way the suggestion would be helpful, since a simple could disable the automatic removal of the imports.
I second that should be applicable. To fix the violations I almost found and removed the qualified prefix one by one.
Mentoring instructions: Add a new .

<ins> error: unnecessary qualification --> $DIR/unused-qualifications-suggestion.rs:17:5 | LL |     foo::bar(); |     ^^^^^^^^ | note: the lint level is defined here --> $DIR/unused-qualifications-suggestion.rs:3:9 | LL | #![deny(unused_qualifications)] |         ^^^^^^^^^^^^^^^^^^^^^ help: replace it with the unqualified path | LL |     bar(); |     ~~~ error: unnecessary qualification --> $DIR/unused-qualifications-suggestion.rs:21:5 | LL |     baz::qux::quux(); |     ^^^^^^^^^^^^^^ | help: replace it with the unqualified path | LL |     quux(); |     ~~~~ error: aborting due to 2 previous errors </ins>


Question:
Repro steps: create a new cargo binary with . Replace with the following code. Then run . Hope this is helpful! I've tried to minimize the code as much as possible. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
The same issue happens in the latest nightly as well.
This bisects to nightly-2021-06-25. Commit range: It only reproduces with , not , which means bisecting to the old nightly needs in In that range, looks the most relevant because it is the only thing introducing edition-specific behavior, and it's dealing with closure capture and the presence of a closure appears necessary in the minimal repro. would you be interested in taking a look?
For comparison, the same code with doesn't emit a compiler error and has a bit more info:
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
In both and , function returns value every time but somehow in value unwraps into error, even though it's This is the returned value:
Triage: This is no longer ICE with the latest nightly, since (presumably ). Marked as .

<ins> // edition:2021 use std::iter; fn f<T>(data: &[T]) -> impl Iterator<Item = Vec> { //~^ ERROR: missing generics for struct `Vec` [E0107] iter::empty() //~ ERROR: type annotations needed [E0282] } fn g<T>(data: &[T], target: T) -> impl Iterator<Item = Vec<T>> { //~^ ERROR: type annotations needed [E0282] f(data).filter(|x| x == target) } fn main() {} </ins>


Question:
Repro steps: create a new cargo binary with . Replace with the following code. Then run . Hope this is helpful! I've tried to minimize the code as much as possible. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
The same issue happens in the latest nightly as well.
This bisects to nightly-2021-06-25. Commit range: It only reproduces with , not , which means bisecting to the old nightly needs in In that range, looks the most relevant because it is the only thing introducing edition-specific behavior, and it's dealing with closure capture and the presence of a closure appears necessary in the minimal repro. would you be interested in taking a look?
For comparison, the same code with doesn't emit a compiler error and has a bit more info:
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
In both and , function returns value every time but somehow in value unwraps into error, even though it's This is the returned value:
Triage: This is no longer ICE with the latest nightly, since (presumably ). Marked as .

<ins> error[E0107]: missing generics for struct `Vec` --> $DIR/issue-92305.rs:5:45 | LL | fn f<T>(data: &[T]) -> impl Iterator<Item = Vec> { |                                             ^^^ expected at least 1 generic argument | note: struct defined here, with at least 1 generic parameter: `T` --> $SRC_DIR/alloc/src/vec/mod.rs:LL:COL | LL | pub struct Vec<T, #[unstable(feature = "allocator_api", issue = "32838")] A: Allocator = Global> { |            ^^^ - help: add missing generic argument | LL | fn f<T>(data: &[T]) -> impl Iterator<Item = Vec<T>> { |                                             ~~~~~~ error[E0282]: type annotations needed --> $DIR/issue-92305.rs:7:5 | LL |     iter::empty() |     ^^^^^^^^^^^ cannot infer type for type parameter `T` declared on the function `empty` error[E0282]: type annotations needed --> $DIR/issue-92305.rs:10:35 | LL | fn g<T>(data: &[T], target: T) -> impl Iterator<Item = Vec<T>> { |                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot infer type error: aborting due to 3 previous errors Some errors have detailed explanations: E0107, E0282. For more information about an error, try `rustc --explain E0107`. </ins>


Question:
Error is with genericconstexprs : <!-- 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 --
I actually hit this same issue with capturing un-normalized types in generator interiors when playing around with . I think I know a fix. claim

saved_locals: &GeneratorSavedLocals, ) { let did = body.source.def_id(); <del> let allowed_upvars = tcx.erase_regions(upvars); </del> <ins> let param_env = tcx.param_env(did); let allowed_upvars = tcx.normalize_erasing_regions(param_env, upvars); </ins> let allowed = match witness.kind() { <del> &ty::GeneratorWitness(s) => tcx.erase_late_bound_regions(s), </del> <ins> &ty::GeneratorWitness(interior_tys) => { tcx.normalize_erasing_late_bound_regions(param_env, interior_tys) } </ins> _ => { tcx.sess.delay_span_bug( body.span,


Question:
Error is with genericconstexprs : <!-- 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 --
I actually hit this same issue with capturing un-normalized types in generator interiors when playing around with . I think I know a fix. claim

} }; <del> let param_env = tcx.param_env(did); </del> for (local, decl) in body.local_decls.iter_enumerated() { // Ignore locals which are internal or not saved between yields. if !saved_locals.contains(local) || decl.internal {


Question:
Error is with genericconstexprs : <!-- 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 --
I actually hit this same issue with capturing un-normalized types in generator interiors when playing around with . I think I know a fix. claim

<ins> // edition:2018 // run-pass #![allow(incomplete_features)] #![feature(generic_const_exprs)] #![allow(unused)] fn main() { let x = test(); } fn concat<const A: usize, const B: usize>(a: [f32; A], b: [f32; B]) -> [f32; A + B] { todo!() } async fn reverse<const A: usize>(x: [f32; A]) -> [f32; A] { todo!() } async fn test() { let a = [0.0]; let b = [1.0, 2.0]; let ab = concat(a,b); let ba = reverse(ab).await; println!("{:?}", ba); } </ins>


Question:
The section of the Manual would benefit from some code examples, especially those that clarify how traits and impls interact with the new name. I find the term "type definition" confusing because this section seems to be describing what I think of as "type aliases". Aren't and also examples of "type definitions"? If so, is it worth changing this terminology?
Here are some relevant thanks to
cc
Yeah, I'm not sure what the right terminology is here. Hmm.
what do you think?
+1 for "type alias" -- much clearer.

Extern functions may be called directly from Rust code as Rust uses large, contiguous stack segments like C. <del> ### Type definitions </del> <ins> ### Type aliases </ins> <del> A _type definition_ defines a new name for an existing [type](#types). Type definitions are declared with the keyword `type`. Every value has a single, </del> <ins> A _type alias_ defines a new name for an existing [type](#types). Type aliases are declared with the keyword `type`. Every value has a single, </ins> specific type; the type-specified aspects of a value include: * Whether the value is composed of sub-values or is indivisible.


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. --With the experimental feature (), there's a compiler issue that surfaces during documentation generation but not a regular build. In the code example below, produces an unhelpful error message. <!-- 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. --: The error on running is: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Isn't it the same as ?
No, I don't think so, that initial instance did not require to be enabled (we controlled for that variable using ).
looks fixed to me, marking as needs-test

<ins> // Regression test for <https://github.com/rust-lang/rust/issues/92859>. #![allow(incomplete_features)] #![feature(generic_const_exprs)] #![crate_name = "foo"] // @has 'foo/trait.Foo.html' pub trait Foo: Sized { const WIDTH: usize; fn arrayify(self) -> [Self; Self::WIDTH]; } impl<T: Sized> Foo for T { const WIDTH: usize = 1; // @has - '//*[@id="tymethod.arrayify"]/*[@class="code-header"]'  // 'fn arrayify(self) -> [Self; Self::WIDTH]' fn arrayify(self) -> [Self; Self::WIDTH] { [self] } } </ins>


Question:
Nested markdown lists as below are not rendered as nested lists, but as single-level lists. Works as expected: stable (, ) beta (, ) Produces unintended output: nightly (, ) Initially reported at foo bar baz With (with stable toolchain): ! foo + bar + baz With with nightly toolchain: !
I need to confirm if it comes from rustdoc or pulldown-cmark. I'll try to fix it in the next days.
This is a regression in pulldown-cmark, I have opened
This also affects
Thanks !
A patch release of pulldown-cmark is about to be released. Could someone open a PR to update to it?
Ok, release is out.
Just opened for it.
Marking as P-high: regression that breaks relatively simple Markdown syntax

"clippy_utils", "if_chain", "itertools 0.10.1", <del> "pulldown-cmark 0.9.0", </del> <ins> "pulldown-cmark", </ins> "quine-mc_cluskey", "regex-syntax", "rustc-semver",


Question:
Nested markdown lists as below are not rendered as nested lists, but as single-level lists. Works as expected: stable (, ) beta (, ) Produces unintended output: nightly (, ) Initially reported at foo bar baz With (with stable toolchain): ! foo + bar + baz With with nightly toolchain: !
I need to confirm if it comes from rustdoc or pulldown-cmark. I'll try to fix it in the next days.
This is a regression in pulldown-cmark, I have opened
This also affects
Thanks !
A patch release of pulldown-cmark is about to be released. Could someone open a PR to update to it?
Ok, release is out.
Just opened for it.
Marking as P-high: regression that breaks relatively simple Markdown syntax

[[package]] name = "mdbook" <del> version = "0.4.14" </del> <ins> version = "0.4.15" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "f6e77253c46a90eb7e96b2807201dab941a4db5ea05eca5aaaf7027395f352b3" </del> <ins> checksum = "241f10687eb3b4e0634b3b4e423f97c5f1efbd69dc9522e24a8b94583eeec3c6" </ins> dependencies = [ "ammonia", "anyhow",


Question:
Nested markdown lists as below are not rendered as nested lists, but as single-level lists. Works as expected: stable (, ) beta (, ) Produces unintended output: nightly (, ) Initially reported at foo bar baz With (with stable toolchain): ! foo + bar + baz With with nightly toolchain: !
I need to confirm if it comes from rustdoc or pulldown-cmark. I'll try to fix it in the next days.
This is a regression in pulldown-cmark, I have opened
This also affects
Thanks !
A patch release of pulldown-cmark is about to be released. Could someone open a PR to update to it?
Ok, release is out.
Just opened for it.
Marking as P-high: regression that breaks relatively simple Markdown syntax

"log", "memchr", "opener", <del> "pulldown-cmark 0.8.0", </del> <ins> "pulldown-cmark", </ins> "regex", "serde", "serde_derive",


Question:
Nested markdown lists as below are not rendered as nested lists, but as single-level lists. Works as expected: stable (, ) beta (, ) Produces unintended output: nightly (, ) Initially reported at foo bar baz With (with stable toolchain): ! foo + bar + baz With with nightly toolchain: !
I need to confirm if it comes from rustdoc or pulldown-cmark. I'll try to fix it in the next days.
This is a regression in pulldown-cmark, I have opened
This also affects
Thanks !
A patch release of pulldown-cmark is about to be released. Could someone open a PR to update to it?
Ok, release is out.
Just opened for it.
Marking as P-high: regression that breaks relatively simple Markdown syntax

[[package]] name = "pulldown-cmark" <del> version = "0.8.0" </del> <ins> version = "0.9.1" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "ffade02495f22453cd593159ea2f59827aae7f53fa8323f756799b670881dcf8" </del> <ins> checksum = "34f197a544b0c9ab3ae46c359a7ec9cbbb5c7bf97054266fecb7ead794a181d6" </ins> dependencies = [ "bitflags", "getopts",


Question:
Nested markdown lists as below are not rendered as nested lists, but as single-level lists. Works as expected: stable (, ) beta (, ) Produces unintended output: nightly (, ) Initially reported at foo bar baz With (with stable toolchain): ! foo + bar + baz With with nightly toolchain: !
I need to confirm if it comes from rustdoc or pulldown-cmark. I'll try to fix it in the next days.
This is a regression in pulldown-cmark, I have opened
This also affects
Thanks !
A patch release of pulldown-cmark is about to be released. Could someone open a PR to update to it?
Ok, release is out.
Just opened for it.
Marking as P-high: regression that breaks relatively simple Markdown syntax

] [[package]] <del> name = "pulldown-cmark" version = "0.9.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "acd16514d1af5f7a71f909a44ef253cdb712a376d7ebc8ae4a471a9be9743548" dependencies = [ "bitflags", "memchr", "unicase", ] [[package]] </del> name = "punycode" version = "0.4.1" source = "registry+https://github.com/rust-lang/crates.io-index"


Question:
Nested markdown lists as below are not rendered as nested lists, but as single-level lists. Works as expected: stable (, ) beta (, ) Produces unintended output: nightly (, ) Initially reported at foo bar baz With (with stable toolchain): ! foo + bar + baz With with nightly toolchain: !
I need to confirm if it comes from rustdoc or pulldown-cmark. I'll try to fix it in the next days.
This is a regression in pulldown-cmark, I have opened
This also affects
Thanks !
A patch release of pulldown-cmark is about to be released. Could someone open a PR to update to it?
Ok, release is out.
Just opened for it.
Marking as P-high: regression that breaks relatively simple Markdown syntax

"expect-test", "itertools 0.9.0", "minifier", <del> "pulldown-cmark 0.9.0", </del> <ins> "pulldown-cmark", </ins> "rayon", "regex", "rustdoc-json-types",


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. --Please clone and build it. <!-- 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
This is a new incremental compilation issue, distinct from the previous 'called Option::unwrap' issues. cc
Thanks for the great reproducer - I was able to reproduce this by first building commit , then building commit
This is caused by the way that we handle (which is an anon dep-node). The current query system is set up so that we will never try to force a query with a stale . Normally, the only way of invoking a query with a is to obtain that from another query result, or to receive that as part of the query argument. If a query 'A' obtains a by invoking another query 'B', then removing the corresponding definition from the crate will change the result of query 'B', causing it to be marked red. When we try to mark query 'A' as green, we will see the red dependency 'B' and bail out, before we ever attempt to force another query with the stale that we saved from the previous compilation session. When we actually invoke a query during the execution of some query's body, we will try to find a matching from the previous compilation session. If the input to the invoked query contains a (e.g. as part of the inside of a ), then a change to the will cause us to compute a different hash for the query input. As a result, we will never try to load the depnode from a previous session, since we will not find a node with a matching hash. However, anon dep nodes break this assumption. Specifically, when we create a , we invoke queries like using s taken from the surrounding . From the perspective of the query system, these s are essentially pulled out of thin air - the query system sees as having no input. Specifically, we call: Inside a (recursive) call to , we may call queries with s obtained from the predicate - for example, to look up constituent types for auto trait impls. As a result, trying to mark a node green can cause us to try to force a query with a stale , since our edges vec will not contain a dependency on a query used to produce the to begin with. With normal non-anon nodes, the dependency on a particular will always be explicitly carried through the graph of query invocations - either being forwarded through a query argument (thus affecting the hash), or by using the result of another query. The fact that we will never legitimately try to force a stale has helped us find bugs (e.g. ), so I think it would be unfortunate if we had to start silently ignoring the forcing of a stale . I'll need to think about how we can adjust anon dep nodes to fix this issue. Ideally, we would just remove the concept of anon dep nodes entirely - however, I'm pretty sure that it's the only way to make the global evaluation cache work with incremental compilation.
I've determined the root cause of the issue - we're failing to keep track of the created when using the provisional cache. When evaluation finishes 'normally', we store the created anon depnode into the evaluation cache: When we later read from the evaluation cache, we will generate a read of that : This ensures that any queries using a cached result will still get all of the dependency edges created during the initial uncached execution (e.g. a call to when determining constituent types). However, when we store a result in the provisional cache (due to an auto-trait cycle), we don't store the generated : When we later move entires from the provisional cache to the 'real' evaluation cache, we insert them using a different : In the provided reproducer, we first store in the provisional cache, and then move it to the 'real' evaluation cache. This means that any queries using the cached result of evaluating (e.g. a call to ) will not get dependency edges for any queries invoked during the initial 'provisional' evaluation of the predicate. In particular, we will not get the edge to , which has a changed result between the two compilation sessions. I've confirmed that storing the provisional result into the evaluation cache using its original fixes the ICE. However, I need to do some more investigation - I think we may need to combine both 's to ensure that we don't miss any edges.
Minimal reproduction script: : : produces:

debug!(?result, "CACHE MISS"); self.insert_evaluation_cache(param_env, fresh_trait_pred, dep_node, result); <del> stack.cache().on_completion(stack.dfn, |fresh_trait_pred, provisional_result| { self.insert_evaluation_cache( param_env, fresh_trait_pred, dep_node, provisional_result.max(result), ); }); </del> <ins> stack.cache().on_completion( stack.dfn, |fresh_trait_pred, provisional_result, provisional_dep_node| { // Create a new `DepNode` that has dependencies on: // * The `DepNode` for the original evaluation that resulted in a provisional cache // entry being crated // * The `DepNode` for the *current* evaluation, which resulted in us completing // provisional caches entries and inserting them into the evaluation cache // // This ensures that when a query reads this entry from the evaluation cache, // it will end up (transitively) dependening on all of the incr-comp dependencies // created during the evaluation of this trait. For example, evaluating a trait // will usually require us to invoke `type_of(field_def_id)` to determine the // constituent types, and we want any queries reading from this evaluation // cache entry to end up with a transitive `type_of(field_def_id`)` dependency. // // By using `in_task`, we're also creating an edge from the *current* query // to the newly-created `combined_dep_node`. This is probably redundant, // but it's better to add too many dep graph edges than to add too few // dep graph edges. let ((), combined_dep_node) = self.in_task(|this| { this.tcx().dep_graph.read_index(provisional_dep_node); this.tcx().dep_graph.read_index(dep_node); }); self.insert_evaluation_cache( param_env, fresh_trait_pred, combined_dep_node, provisional_result.max(result), ); }, ); </ins> } else { debug!(?result, "PROVISIONAL"); debug!(


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. --Please clone and build it. <!-- 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
This is a new incremental compilation issue, distinct from the previous 'called Option::unwrap' issues. cc
Thanks for the great reproducer - I was able to reproduce this by first building commit , then building commit
This is caused by the way that we handle (which is an anon dep-node). The current query system is set up so that we will never try to force a query with a stale . Normally, the only way of invoking a query with a is to obtain that from another query result, or to receive that as part of the query argument. If a query 'A' obtains a by invoking another query 'B', then removing the corresponding definition from the crate will change the result of query 'B', causing it to be marked red. When we try to mark query 'A' as green, we will see the red dependency 'B' and bail out, before we ever attempt to force another query with the stale that we saved from the previous compilation session. When we actually invoke a query during the execution of some query's body, we will try to find a matching from the previous compilation session. If the input to the invoked query contains a (e.g. as part of the inside of a ), then a change to the will cause us to compute a different hash for the query input. As a result, we will never try to load the depnode from a previous session, since we will not find a node with a matching hash. However, anon dep nodes break this assumption. Specifically, when we create a , we invoke queries like using s taken from the surrounding . From the perspective of the query system, these s are essentially pulled out of thin air - the query system sees as having no input. Specifically, we call: Inside a (recursive) call to , we may call queries with s obtained from the predicate - for example, to look up constituent types for auto trait impls. As a result, trying to mark a node green can cause us to try to force a query with a stale , since our edges vec will not contain a dependency on a query used to produce the to begin with. With normal non-anon nodes, the dependency on a particular will always be explicitly carried through the graph of query invocations - either being forwarded through a query argument (thus affecting the hash), or by using the result of another query. The fact that we will never legitimately try to force a stale has helped us find bugs (e.g. ), so I think it would be unfortunate if we had to start silently ignoring the forcing of a stale . I'll need to think about how we can adjust anon dep nodes to fix this issue. Ideally, we would just remove the concept of anon dep nodes entirely - however, I'm pretty sure that it's the only way to make the global evaluation cache work with incremental compilation.
I've determined the root cause of the issue - we're failing to keep track of the created when using the provisional cache. When evaluation finishes 'normally', we store the created anon depnode into the evaluation cache: When we later read from the evaluation cache, we will generate a read of that : This ensures that any queries using a cached result will still get all of the dependency edges created during the initial uncached execution (e.g. a call to when determining constituent types). However, when we store a result in the provisional cache (due to an auto-trait cycle), we don't store the generated : When we later move entires from the provisional cache to the 'real' evaluation cache, we insert them using a different : In the provided reproducer, we first store in the provisional cache, and then move it to the 'real' evaluation cache. This means that any queries using the cached result of evaluating (e.g. a call to ) will not get dependency edges for any queries invoked during the initial 'provisional' evaluation of the predicate. In particular, we will not get the edge to , which has a changed result between the two compilation sessions. I've confirmed that storing the provisional result into the evaluation cache using its original fixes the ICE. However, I need to do some more investigation - I think we may need to combine both 's to ensure that we don't miss any edges.
Minimal reproduction script: : : produces:

fresh_trait_pred, stack.depth, reached_depth, ); <del> stack.cache().insert_provisional(stack.dfn, reached_depth, fresh_trait_pred, result); </del> <ins> stack.cache().insert_provisional( stack.dfn, reached_depth, fresh_trait_pred, result, dep_node, ); </ins> } Ok(result)


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. --Please clone and build it. <!-- 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
This is a new incremental compilation issue, distinct from the previous 'called Option::unwrap' issues. cc
Thanks for the great reproducer - I was able to reproduce this by first building commit , then building commit
This is caused by the way that we handle (which is an anon dep-node). The current query system is set up so that we will never try to force a query with a stale . Normally, the only way of invoking a query with a is to obtain that from another query result, or to receive that as part of the query argument. If a query 'A' obtains a by invoking another query 'B', then removing the corresponding definition from the crate will change the result of query 'B', causing it to be marked red. When we try to mark query 'A' as green, we will see the red dependency 'B' and bail out, before we ever attempt to force another query with the stale that we saved from the previous compilation session. When we actually invoke a query during the execution of some query's body, we will try to find a matching from the previous compilation session. If the input to the invoked query contains a (e.g. as part of the inside of a ), then a change to the will cause us to compute a different hash for the query input. As a result, we will never try to load the depnode from a previous session, since we will not find a node with a matching hash. However, anon dep nodes break this assumption. Specifically, when we create a , we invoke queries like using s taken from the surrounding . From the perspective of the query system, these s are essentially pulled out of thin air - the query system sees as having no input. Specifically, we call: Inside a (recursive) call to , we may call queries with s obtained from the predicate - for example, to look up constituent types for auto trait impls. As a result, trying to mark a node green can cause us to try to force a query with a stale , since our edges vec will not contain a dependency on a query used to produce the to begin with. With normal non-anon nodes, the dependency on a particular will always be explicitly carried through the graph of query invocations - either being forwarded through a query argument (thus affecting the hash), or by using the result of another query. The fact that we will never legitimately try to force a stale has helped us find bugs (e.g. ), so I think it would be unfortunate if we had to start silently ignoring the forcing of a stale . I'll need to think about how we can adjust anon dep nodes to fix this issue. Ideally, we would just remove the concept of anon dep nodes entirely - however, I'm pretty sure that it's the only way to make the global evaluation cache work with incremental compilation.
I've determined the root cause of the issue - we're failing to keep track of the created when using the provisional cache. When evaluation finishes 'normally', we store the created anon depnode into the evaluation cache: When we later read from the evaluation cache, we will generate a read of that : This ensures that any queries using a cached result will still get all of the dependency edges created during the initial uncached execution (e.g. a call to when determining constituent types). However, when we store a result in the provisional cache (due to an auto-trait cycle), we don't store the generated : When we later move entires from the provisional cache to the 'real' evaluation cache, we insert them using a different : In the provided reproducer, we first store in the provisional cache, and then move it to the 'real' evaluation cache. This means that any queries using the cached result of evaluating (e.g. a call to ) will not get dependency edges for any queries invoked during the initial 'provisional' evaluation of the predicate. In particular, we will not get the edge to , which has a changed result between the two compilation sessions. I've confirmed that storing the provisional result into the evaluation cache using its original fixes the ICE. However, I need to do some more investigation - I think we may need to combine both 's to ensure that we don't miss any edges.
Minimal reproduction script: : : produces:

from_dfn: usize, reached_depth: usize, result: EvaluationResult, <ins> /// The `DepNodeIndex` created for the `evaluate_stack` call for this provisional /// evaluation. When we create an entry in the evaluation cache using this provisional /// cache entry (see `on_completion`), we use this `dep_node` to ensure that future reads from /// the cache will have all of the necessary incr comp dependencies tracked. dep_node: DepNodeIndex, </ins> } impl<'tcx> Default for ProvisionalEvaluationCache<'tcx> {


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. --Please clone and build it. <!-- 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
This is a new incremental compilation issue, distinct from the previous 'called Option::unwrap' issues. cc
Thanks for the great reproducer - I was able to reproduce this by first building commit , then building commit
This is caused by the way that we handle (which is an anon dep-node). The current query system is set up so that we will never try to force a query with a stale . Normally, the only way of invoking a query with a is to obtain that from another query result, or to receive that as part of the query argument. If a query 'A' obtains a by invoking another query 'B', then removing the corresponding definition from the crate will change the result of query 'B', causing it to be marked red. When we try to mark query 'A' as green, we will see the red dependency 'B' and bail out, before we ever attempt to force another query with the stale that we saved from the previous compilation session. When we actually invoke a query during the execution of some query's body, we will try to find a matching from the previous compilation session. If the input to the invoked query contains a (e.g. as part of the inside of a ), then a change to the will cause us to compute a different hash for the query input. As a result, we will never try to load the depnode from a previous session, since we will not find a node with a matching hash. However, anon dep nodes break this assumption. Specifically, when we create a , we invoke queries like using s taken from the surrounding . From the perspective of the query system, these s are essentially pulled out of thin air - the query system sees as having no input. Specifically, we call: Inside a (recursive) call to , we may call queries with s obtained from the predicate - for example, to look up constituent types for auto trait impls. As a result, trying to mark a node green can cause us to try to force a query with a stale , since our edges vec will not contain a dependency on a query used to produce the to begin with. With normal non-anon nodes, the dependency on a particular will always be explicitly carried through the graph of query invocations - either being forwarded through a query argument (thus affecting the hash), or by using the result of another query. The fact that we will never legitimately try to force a stale has helped us find bugs (e.g. ), so I think it would be unfortunate if we had to start silently ignoring the forcing of a stale . I'll need to think about how we can adjust anon dep nodes to fix this issue. Ideally, we would just remove the concept of anon dep nodes entirely - however, I'm pretty sure that it's the only way to make the global evaluation cache work with incremental compilation.
I've determined the root cause of the issue - we're failing to keep track of the created when using the provisional cache. When evaluation finishes 'normally', we store the created anon depnode into the evaluation cache: When we later read from the evaluation cache, we will generate a read of that : This ensures that any queries using a cached result will still get all of the dependency edges created during the initial uncached execution (e.g. a call to when determining constituent types). However, when we store a result in the provisional cache (due to an auto-trait cycle), we don't store the generated : When we later move entires from the provisional cache to the 'real' evaluation cache, we insert them using a different : In the provided reproducer, we first store in the provisional cache, and then move it to the 'real' evaluation cache. This means that any queries using the cached result of evaluating (e.g. a call to ) will not get dependency edges for any queries invoked during the initial 'provisional' evaluation of the predicate. In particular, we will not get the edge to , which has a changed result between the two compilation sessions. I've confirmed that storing the provisional result into the evaluation cache using its original fixes the ICE. However, I need to do some more investigation - I think we may need to combine both 's to ensure that we don't miss any edges.
Minimal reproduction script: : : produces:

reached_depth: usize, fresh_trait_pred: ty::PolyTraitPredicate<'tcx>, result: EvaluationResult, <ins> dep_node: DepNodeIndex, </ins> ) { debug!(?from_dfn, ?fresh_trait_pred, ?result, "insert_provisional");


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. --Please clone and build it. <!-- 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
This is a new incremental compilation issue, distinct from the previous 'called Option::unwrap' issues. cc
Thanks for the great reproducer - I was able to reproduce this by first building commit , then building commit
This is caused by the way that we handle (which is an anon dep-node). The current query system is set up so that we will never try to force a query with a stale . Normally, the only way of invoking a query with a is to obtain that from another query result, or to receive that as part of the query argument. If a query 'A' obtains a by invoking another query 'B', then removing the corresponding definition from the crate will change the result of query 'B', causing it to be marked red. When we try to mark query 'A' as green, we will see the red dependency 'B' and bail out, before we ever attempt to force another query with the stale that we saved from the previous compilation session. When we actually invoke a query during the execution of some query's body, we will try to find a matching from the previous compilation session. If the input to the invoked query contains a (e.g. as part of the inside of a ), then a change to the will cause us to compute a different hash for the query input. As a result, we will never try to load the depnode from a previous session, since we will not find a node with a matching hash. However, anon dep nodes break this assumption. Specifically, when we create a , we invoke queries like using s taken from the surrounding . From the perspective of the query system, these s are essentially pulled out of thin air - the query system sees as having no input. Specifically, we call: Inside a (recursive) call to , we may call queries with s obtained from the predicate - for example, to look up constituent types for auto trait impls. As a result, trying to mark a node green can cause us to try to force a query with a stale , since our edges vec will not contain a dependency on a query used to produce the to begin with. With normal non-anon nodes, the dependency on a particular will always be explicitly carried through the graph of query invocations - either being forwarded through a query argument (thus affecting the hash), or by using the result of another query. The fact that we will never legitimately try to force a stale has helped us find bugs (e.g. ), so I think it would be unfortunate if we had to start silently ignoring the forcing of a stale . I'll need to think about how we can adjust anon dep nodes to fix this issue. Ideally, we would just remove the concept of anon dep nodes entirely - however, I'm pretty sure that it's the only way to make the global evaluation cache work with incremental compilation.
I've determined the root cause of the issue - we're failing to keep track of the created when using the provisional cache. When evaluation finishes 'normally', we store the created anon depnode into the evaluation cache: When we later read from the evaluation cache, we will generate a read of that : This ensures that any queries using a cached result will still get all of the dependency edges created during the initial uncached execution (e.g. a call to when determining constituent types). However, when we store a result in the provisional cache (due to an auto-trait cycle), we don't store the generated : When we later move entires from the provisional cache to the 'real' evaluation cache, we insert them using a different : In the provided reproducer, we first store in the provisional cache, and then move it to the 'real' evaluation cache. This means that any queries using the cached result of evaluating (e.g. a call to ) will not get dependency edges for any queries invoked during the initial 'provisional' evaluation of the predicate. In particular, we will not get the edge to , which has a changed result between the two compilation sessions. I've confirmed that storing the provisional result into the evaluation cache using its original fixes the ICE. However, I need to do some more investigation - I think we may need to combine both 's to ensure that we don't miss any edges.
Minimal reproduction script: : : produces:

} } <del> map.insert(fresh_trait_pred, ProvisionalEvaluation { from_dfn, reached_depth, result }); </del> <ins> map.insert( fresh_trait_pred, ProvisionalEvaluation { from_dfn, reached_depth, result, dep_node }, ); </ins> } /// Invoked when the node with dfn `dfn` does not get a successful


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. --Please clone and build it. <!-- 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
This is a new incremental compilation issue, distinct from the previous 'called Option::unwrap' issues. cc
Thanks for the great reproducer - I was able to reproduce this by first building commit , then building commit
This is caused by the way that we handle (which is an anon dep-node). The current query system is set up so that we will never try to force a query with a stale . Normally, the only way of invoking a query with a is to obtain that from another query result, or to receive that as part of the query argument. If a query 'A' obtains a by invoking another query 'B', then removing the corresponding definition from the crate will change the result of query 'B', causing it to be marked red. When we try to mark query 'A' as green, we will see the red dependency 'B' and bail out, before we ever attempt to force another query with the stale that we saved from the previous compilation session. When we actually invoke a query during the execution of some query's body, we will try to find a matching from the previous compilation session. If the input to the invoked query contains a (e.g. as part of the inside of a ), then a change to the will cause us to compute a different hash for the query input. As a result, we will never try to load the depnode from a previous session, since we will not find a node with a matching hash. However, anon dep nodes break this assumption. Specifically, when we create a , we invoke queries like using s taken from the surrounding . From the perspective of the query system, these s are essentially pulled out of thin air - the query system sees as having no input. Specifically, we call: Inside a (recursive) call to , we may call queries with s obtained from the predicate - for example, to look up constituent types for auto trait impls. As a result, trying to mark a node green can cause us to try to force a query with a stale , since our edges vec will not contain a dependency on a query used to produce the to begin with. With normal non-anon nodes, the dependency on a particular will always be explicitly carried through the graph of query invocations - either being forwarded through a query argument (thus affecting the hash), or by using the result of another query. The fact that we will never legitimately try to force a stale has helped us find bugs (e.g. ), so I think it would be unfortunate if we had to start silently ignoring the forcing of a stale . I'll need to think about how we can adjust anon dep nodes to fix this issue. Ideally, we would just remove the concept of anon dep nodes entirely - however, I'm pretty sure that it's the only way to make the global evaluation cache work with incremental compilation.
I've determined the root cause of the issue - we're failing to keep track of the created when using the provisional cache. When evaluation finishes 'normally', we store the created anon depnode into the evaluation cache: When we later read from the evaluation cache, we will generate a read of that : This ensures that any queries using a cached result will still get all of the dependency edges created during the initial uncached execution (e.g. a call to when determining constituent types). However, when we store a result in the provisional cache (due to an auto-trait cycle), we don't store the generated : When we later move entires from the provisional cache to the 'real' evaluation cache, we insert them using a different : In the provided reproducer, we first store in the provisional cache, and then move it to the 'real' evaluation cache. This means that any queries using the cached result of evaluating (e.g. a call to ) will not get dependency edges for any queries invoked during the initial 'provisional' evaluation of the predicate. In particular, we will not get the edge to , which has a changed result between the two compilation sessions. I've confirmed that storing the provisional result into the evaluation cache using its original fixes the ICE. However, I need to do some more investigation - I think we may need to combine both 's to ensure that we don't miss any edges.
Minimal reproduction script: : : produces:

fn on_completion( &self, dfn: usize, <del> mut op: impl FnMut(ty::PolyTraitPredicate<'tcx>, EvaluationResult), </del> <ins> mut op: impl FnMut(ty::PolyTraitPredicate<'tcx>, EvaluationResult, DepNodeIndex), </ins> ) { debug!(?dfn, "on_completion");


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. --Please clone and build it. <!-- 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
This is a new incremental compilation issue, distinct from the previous 'called Option::unwrap' issues. cc
Thanks for the great reproducer - I was able to reproduce this by first building commit , then building commit
This is caused by the way that we handle (which is an anon dep-node). The current query system is set up so that we will never try to force a query with a stale . Normally, the only way of invoking a query with a is to obtain that from another query result, or to receive that as part of the query argument. If a query 'A' obtains a by invoking another query 'B', then removing the corresponding definition from the crate will change the result of query 'B', causing it to be marked red. When we try to mark query 'A' as green, we will see the red dependency 'B' and bail out, before we ever attempt to force another query with the stale that we saved from the previous compilation session. When we actually invoke a query during the execution of some query's body, we will try to find a matching from the previous compilation session. If the input to the invoked query contains a (e.g. as part of the inside of a ), then a change to the will cause us to compute a different hash for the query input. As a result, we will never try to load the depnode from a previous session, since we will not find a node with a matching hash. However, anon dep nodes break this assumption. Specifically, when we create a , we invoke queries like using s taken from the surrounding . From the perspective of the query system, these s are essentially pulled out of thin air - the query system sees as having no input. Specifically, we call: Inside a (recursive) call to , we may call queries with s obtained from the predicate - for example, to look up constituent types for auto trait impls. As a result, trying to mark a node green can cause us to try to force a query with a stale , since our edges vec will not contain a dependency on a query used to produce the to begin with. With normal non-anon nodes, the dependency on a particular will always be explicitly carried through the graph of query invocations - either being forwarded through a query argument (thus affecting the hash), or by using the result of another query. The fact that we will never legitimately try to force a stale has helped us find bugs (e.g. ), so I think it would be unfortunate if we had to start silently ignoring the forcing of a stale . I'll need to think about how we can adjust anon dep nodes to fix this issue. Ideally, we would just remove the concept of anon dep nodes entirely - however, I'm pretty sure that it's the only way to make the global evaluation cache work with incremental compilation.
I've determined the root cause of the issue - we're failing to keep track of the created when using the provisional cache. When evaluation finishes 'normally', we store the created anon depnode into the evaluation cache: When we later read from the evaluation cache, we will generate a read of that : This ensures that any queries using a cached result will still get all of the dependency edges created during the initial uncached execution (e.g. a call to when determining constituent types). However, when we store a result in the provisional cache (due to an auto-trait cycle), we don't store the generated : When we later move entires from the provisional cache to the 'real' evaluation cache, we insert them using a different : In the provided reproducer, we first store in the provisional cache, and then move it to the 'real' evaluation cache. This means that any queries using the cached result of evaluating (e.g. a call to ) will not get dependency edges for any queries invoked during the initial 'provisional' evaluation of the predicate. In particular, we will not get the edge to , which has a changed result between the two compilation sessions. I've confirmed that storing the provisional result into the evaluation cache using its original fixes the ICE. However, I need to do some more investigation - I think we may need to combine both 's to ensure that we don't miss any edges.
Minimal reproduction script: : : produces:

{ debug!(?fresh_trait_pred, ?eval, "on_completion"); <del> op(fresh_trait_pred, eval.result); </del> <ins> op(fresh_trait_pred, eval.result, eval.dep_node); </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. --Please clone and build it. <!-- 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
This is a new incremental compilation issue, distinct from the previous 'called Option::unwrap' issues. cc
Thanks for the great reproducer - I was able to reproduce this by first building commit , then building commit
This is caused by the way that we handle (which is an anon dep-node). The current query system is set up so that we will never try to force a query with a stale . Normally, the only way of invoking a query with a is to obtain that from another query result, or to receive that as part of the query argument. If a query 'A' obtains a by invoking another query 'B', then removing the corresponding definition from the crate will change the result of query 'B', causing it to be marked red. When we try to mark query 'A' as green, we will see the red dependency 'B' and bail out, before we ever attempt to force another query with the stale that we saved from the previous compilation session. When we actually invoke a query during the execution of some query's body, we will try to find a matching from the previous compilation session. If the input to the invoked query contains a (e.g. as part of the inside of a ), then a change to the will cause us to compute a different hash for the query input. As a result, we will never try to load the depnode from a previous session, since we will not find a node with a matching hash. However, anon dep nodes break this assumption. Specifically, when we create a , we invoke queries like using s taken from the surrounding . From the perspective of the query system, these s are essentially pulled out of thin air - the query system sees as having no input. Specifically, we call: Inside a (recursive) call to , we may call queries with s obtained from the predicate - for example, to look up constituent types for auto trait impls. As a result, trying to mark a node green can cause us to try to force a query with a stale , since our edges vec will not contain a dependency on a query used to produce the to begin with. With normal non-anon nodes, the dependency on a particular will always be explicitly carried through the graph of query invocations - either being forwarded through a query argument (thus affecting the hash), or by using the result of another query. The fact that we will never legitimately try to force a stale has helped us find bugs (e.g. ), so I think it would be unfortunate if we had to start silently ignoring the forcing of a stale . I'll need to think about how we can adjust anon dep nodes to fix this issue. Ideally, we would just remove the concept of anon dep nodes entirely - however, I'm pretty sure that it's the only way to make the global evaluation cache work with incremental compilation.
I've determined the root cause of the issue - we're failing to keep track of the created when using the provisional cache. When evaluation finishes 'normally', we store the created anon depnode into the evaluation cache: When we later read from the evaluation cache, we will generate a read of that : This ensures that any queries using a cached result will still get all of the dependency edges created during the initial uncached execution (e.g. a call to when determining constituent types). However, when we store a result in the provisional cache (due to an auto-trait cycle), we don't store the generated : When we later move entires from the provisional cache to the 'real' evaluation cache, we insert them using a different : In the provided reproducer, we first store in the provisional cache, and then move it to the 'real' evaluation cache. This means that any queries using the cached result of evaluating (e.g. a call to ) will not get dependency edges for any queries invoked during the initial 'provisional' evaluation of the predicate. In particular, we will not get the edge to , which has a changed result between the two compilation sessions. I've confirmed that storing the provisional result into the evaluation cache using its original fixes the ICE. However, I need to do some more investigation - I think we may need to combine both 's to ensure that we don't miss any edges.
Minimal reproduction script: : : produces:

<ins> // revisions: rpass1 rpass2 // Regression test for issue #92987 // Tests that we properly manage `DepNode`s during trait evaluation // involing an auto-trait cycle. #[cfg(rpass1)] struct CycleOne(Box<CycleTwo>); #[cfg(rpass2)] enum CycleOne { Variant(Box<CycleTwo>) } struct CycleTwo(CycleOne); fn assert_send<T: Send>() {} fn bar() { assert_send::<CycleOne>(); assert_send::<CycleTwo>(); } fn main() {} </ins>


Question:
: <details<summary<strongBacktrace</strong</summary<p</p</details
this is not exactly ICE, but I did not find an appropriate variant for this
label -I-ICE +I-crash
searched nightlies: from nightly-2021-12-01 to nightly-2022-01-18 regressed nightly: nightly-2021-12-06 searched commits: from to regressed commit: cc
Looks like a stack overflow in . Needs a call to somewhere, probably at the end of around , although there might be a better spot. This will have perf implications, however.
Fixed by , marking as E-needs-test.


Question:
(desktop) Safari the search box here: a letter the letter another letter how the empty space below the search bar changes size cc – I think this is a recent regression; it's in nightly. I presume it has some connection to either your "All crates" change or your sidebar change. This bug is not present in beta.
Hm, I can't reproduce on desktop Safari 15.1. Can you share a video? I can observe a small change in the width of the sidebar between typing a letter and deleting. I'll investigate that.
I'm on Safari 15.2, though I'm not sure if it matters. I'll see if I can get a video sometime soon but I'm a bit busy right now.
https://user-
Thanks!
Thanks for the video that really helped me figure out what I was looking for. I was able to bisect it to (moving the crate dropdown onto the search page). Surprisingly, the minimum diff that causes the issue was not any of the CSS, but removing the dropdown element. So long as the search input has a previous sibling of any kind, the bumpiness does not happen. It's quite mysterious. I haven't been able to find a style that causes this.

 {#- -#} <form class="search-form"> {#- -#}
 {#- -#}   {#- This empty span is a hacky fix for Safari - See #93184 -#}  <input {# -#} class="search-input" {# -#} name="search" {# -#}


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: intradoc links for the block residing in (where is not defined) are valid links. Instead, this happened: Rustdoc thinks that , resolved to , is not in scope here: A workaround is to make sure that , without prefix, is in scope: In other words, it seems that in intradoc links resolve to the name of the item, not the full path? <!-- 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. --:
I'll see if I can look into this. If someone else wants to work on it, feel free to claim it from me!
This appears to have since been fixed, probably by .
Actually, it'd probably be good to add a test for this.
Thanks! That looks to already have trickled down into recent stable rust releases, as I can't reproduce it with . Awesome!

<ins> // Regression test for #93205 #![crate_name = "foo"] mod generated { pub struct MyNewType; impl MyNewType { pub const FOO: Self = Self; } } pub use generated::MyNewType; mod prelude { impl super::MyNewType { /// An alias for [`Self::FOO`]. // @has 'foo/struct.MyNewType.html' '//a[@href="struct.MyNewType.html#associatedconstant.FOO"]' 'Self::FOO' pub const FOO2: Self = Self::FOO; } } </ins>


Question:
Gives (rustc 1.60.0-nightly 2022-01-30): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim

self } <ins> /// Clear any existing suggestions. pub fn clear_suggestions(&mut self) -> &mut Self { if let Ok(suggestions) = &mut self.suggestions { suggestions.clear(); } self } </ins> /// Helper for pushing to `self.suggestions`, if available (not disable). fn push_suggestion(&mut self, suggestion: CodeSuggestion) { if let Ok(suggestions) = &mut self.suggestions {


Question:
Gives (rustc 1.60.0-nightly 2022-01-30): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim

forward!(pub fn set_is_lint(&mut self,) -> &mut Self); forward!(pub fn disable_suggestions(&mut self,) -> &mut Self); <ins> forward!(pub fn clear_suggestions(&mut self,) -> &mut Self); </ins> forward!(pub fn multipart_suggestion( &mut self,


Question:
Gives (rustc 1.60.0-nightly 2022-01-30): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim

//    | //    = note: cannot satisfy `_: Tt` <ins> // Clear any more general suggestions in favor of our specific one err.clear_suggestions(); </ins> err.span_suggestion_verbose( span.shrink_to_hi(), &format!(


Question:
Gives (rustc 1.60.0-nightly 2022-01-30): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim

| = help: normalized in stderr note: required by a bound in `DiagnosticBuilder::<'a, G>::set_arg` <del> --> $COMPILER_DIR/rustc_errors/src/diagnostic_builder.rs:538:19 </del> <ins> --> $COMPILER_DIR/rustc_errors/src/diagnostic_builder.rs:539:19 </ins> | LL |         arg: impl IntoDiagnosticArg, |                   ^^^^^^^^^^^^^^^^^ required by this bound in `DiagnosticBuilder::<'a, G>::set_arg`


Question:
Gives (rustc 1.60.0-nightly 2022-01-30): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim

| LL | fn foo<T, K, W: Default, Z: Default>(t: T, k: K) -> Foo<T, K, W, Z> { |                 ^^^^^^^ required by this bound in `foo` <del> help: consider giving `foo` an explicit type, where the type for type parameter `W` is specified | LL |     let foo: Foo<i32, &str, W, Z> = foo(1, ""); |            ++++++++++++++++++++++ </del> help: consider specifying the type arguments in the function call | LL |     let foo = foo::<T, K, W, Z>(1, "");


Question:
Gives (rustc 1.60.0-nightly 2022-01-30): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim

| LL | fn bar<T, K, Z: Default>(t: T, k: K) -> Bar<T, K, Z> { |                 ^^^^^^^ required by this bound in `bar` <del> help: consider giving `bar` an explicit type, where the type for type parameter `Z` is specified | LL |     let bar: Bar<i32, &str, Z> = bar(1, ""); |            +++++++++++++++++++ </del> help: consider specifying the type arguments in the function call | LL |     let bar = bar::<T, K, Z>(1, "");


Question:
Gives (rustc 1.60.0-nightly 2022-01-30): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim

| LL |         K: Borrow<Q>, |            ^^^^^^^^^ required by this bound in `HashMap::<K, V, S>::get` <del> help: consider specifying the generic argument | LL |         .get::<Q>(&"key".into()) |             +++++ </del> help: consider specifying the type argument in the function call | LL |         .get::<Q>(&"key".into())


Question:
Gives (rustc 1.60.0-nightly 2022-01-30): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim

| LL |         K: Borrow<Q>, |            ^^^^^^^^^ required by this bound in `HashMap::<K, V, S>::get` <del> help: consider specifying the generic argument | LL |     opts.get::<Q>(opt.as_ref()); |             +++++ </del> help: consider specifying the type argument in the function call | LL |     opts.get::<Q>(opt.as_ref());


Question:
Gives (rustc 1.60.0-nightly 2022-01-30): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim

|    ---- required by a bound in this LL | where T : Convert<U> |           ^^^^^^^^^^ required by this bound in `test` <del> help: consider specifying the generic arguments | LL |     test::<i32, U>(22, std::default::Default::default()); |         ++++++++++ </del> help: consider specifying the type arguments in the function call | LL |     test::<T, U>(22, std::default::Default::default());


Question:
Gives (rustc 1.60.0-nightly 2022-01-30): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim

| LL | fn foo<T: Into<String>>(x: i32) {} |           ^^^^^^^^^^^^ required by this bound in `foo` <del> help: consider specifying the generic argument | LL |     foo::<T>(42); |        +++++ </del> help: consider specifying the type argument in the function call | LL |     foo::<T>(42);


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --This code panics on Windows: According to the documentation for , it should either succeed or return . Instead, it panics due to an out-of-range index: <!-- 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. --: The bug is also present in nightly. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I can confirm this. The problem originates in . A minimal example:
It seems that the in causes the issue, I'll try to fix.
claim

if self.has_root() { return false; } <del> let mut iter = self.path[self.prefix_len()..].iter(); </del> <ins> let mut iter = self.path[self.prefix_remaining()..].iter(); </ins> match (iter.next(), iter.next()) { (Some(&b'.'), None) => true, (Some(&b'.'), Some(&b)) => self.is_sep_byte(b),


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --This code panics on Windows: According to the documentation for , it should either succeed or return . Instead, it panics due to an out-of-range index: <!-- 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. --: The bug is also present in nightly. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I can confirm this. The problem originates in . A minimal example:
It seems that the in causes the issue, I'll try to fix.
claim

assert_eq!(prefix, parse_prefix(r"/?C:windowssystem32notepad.exe")); assert_eq!(prefix, parse_prefix(r"?/C:windowssystem32notepad.exe")); } <ins> // See #93586 for more infomation. #[test] fn test_windows_prefix_components() { use crate::path::Path; let path = Path::new("C:"); let mut components = path.components(); let drive = components.next().expect("drive is expected here"); assert_eq!(drive.as_os_str(), OsStr::new("C:")); assert_eq!(components.as_path(), Path::new("")); } </ins>


Question:
Const generic defaults are being stabilized, <!-- 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 --
Seems to also happen with closures:
I got a fix for this one I think. claim
even worse, this compiles on beta but shouldn't
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
I think this needs to remain open until the fix is beta-backported :thinking: not 100% sure on procedure here
You might be correct. At least that's what happened last time one of my PRs was backport nominated (), though I'm not sure if that was due to that being a regression on stable. Regardless, thanks for reopening this.
that's my understading, too. I /think/ issues that are pending a beta/stable backport (like this one) will stay open until the corresponding backport PR has landed. The {stable,beta}-backport procedure is detailed but this detail is not explicited (I'll see if I can fix that to be more clear). For completeness, backports are discussed every Thursday during the compiler team weekly meeting (). Anyway, thanks a lot for fixing this issue and also to + for reporting and debugging :)
Copied from Zulip: Question/thought: Is this a case where tracking bound vars got in the way? Or did it actually help uncover a potential bug?
Not sure what you mean. The bug was that we were just not doing lifetime name resolution at all on const generic defaults. Like this code compiles on beta: edit: ohhh, you mean ? Yeah I think in this case it helped uncover the bug, because of the fact it ICEd and showed us we weren't resolving the closure default.
I guess this example shows that this did help us uncover a bug, but kind of indirectly: This just didn't uncover a case where "lost" bound vars.
this is now fixed on beta

this.visit_ty(&ty); } } <del> GenericParamKind::Const { ref ty, .. } => { </del> <ins> GenericParamKind::Const { ref ty, default } => { </ins> let was_in_const_generic = this.is_in_const_generic; this.is_in_const_generic = true; walk_list!(this, visit_param_bound, param.bounds); this.visit_ty(&ty); <ins> if let Some(default) = default { this.visit_body(this.tcx.hir().body(default.body)); } </ins> this.is_in_const_generic = was_in_const_generic; } }