jiebi/CodeConvo huggingface dataset:
Code change:
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 .

Related discussion:
text: /// 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
Code change:
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 .

Related discussion:
text: }; 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> ) } }
Code change:
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 .

Related discussion:
text: | LL | #![deny(unused_qualifications)] |         ^^^^^^^^^^^^^^^^^^^^^ <ins> help: replace it with the unqualified path | LL |     bar(); |     ~~~ </ins> error: aborting due to previous error
Code change:
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 .

Related discussion:
text: <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>
Code change:
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 .

Related discussion:
text: <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>
Code change:
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 .

Related discussion:
text: <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>
Code change:
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 .

Related discussion:
text: <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>
Code change:
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 .

Related discussion:
text: <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>
Code change:
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

Related discussion:
text: 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,
Code change:
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

Related discussion:
text: } }; <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 {
Code change:
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

Related discussion:
text: <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>
Code change:
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.

Related discussion:
text: 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.
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --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

Related discussion:
text: <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>
Code change:
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

Related discussion:
text: "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",
Code change:
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

Related discussion:
text: [[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",
Code change:
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

Related discussion:
text: "log", "memchr", "opener", <del> "pulldown-cmark 0.8.0", </del> <ins> "pulldown-cmark", </ins> "regex", "serde", "serde_derive",
Code change:
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

Related discussion:
text: [[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",
Code change:
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

Related discussion:
text: ] [[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"
Code change:
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

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