jiebi/CodeConvo huggingface dataset:
Code change:
(Edit: Actually, being an inherent fn doesn't matter. It happens with top-level fns too.) This prints the diagnostic: The suggestion in the last line is not valid syntax (). It also emits malformed syntax if the first parameter is a or parameter. The diagnostic becomes well-formed if any of the following is done: The first parameter is changed to instead ofThe fn is not an async fn. In either case, the diagnostic correctly says: Happens on both nightly: ... and stable:
This should hopefully be a fairly straightforward patch to the diagnostics code that generates the suggestion.

Related discussion:
text: LL | fn bak<I: Iterator + std::fmt::Debug>(constraints: I) where <I as Iterator>::Item: Debug { |       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^              ^  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ <del> error: aborting due to 5 previous errors </del> <ins> error[E0277]: `<impl Iterator as Iterator>::Item` doesn't implement `Debug` --> $DIR/impl-trait-with-missing-bounds.rs:45:13 | LL |         qux(constraint); |             ^^^^^^^^^^ `<impl Iterator as Iterator>::Item` cannot be formatted using `{:?}` because it doesn't implement `Debug` ... LL | fn qux(_: impl std::fmt::Debug) {} |                --------------- required by this bound in `qux` | = help: the trait `Debug` is not implemented for `<impl Iterator as Iterator>::Item` help: introduce a type parameter with a trait bound instead of using `impl Trait` | LL | fn baw<I: Iterator>(constraints: I) where <I as Iterator>::Item: Debug { |       ^^^^^^^^^^^^^              ^  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to 6 previous errors </ins> For more information about this error, try `rustc --explain E0277`.
Code change:
(Edit: Actually, being an inherent fn doesn't matter. It happens with top-level fns too.) This prints the diagnostic: The suggestion in the last line is not valid syntax (). It also emits malformed syntax if the first parameter is a or parameter. The diagnostic becomes well-formed if any of the following is done: The first parameter is changed to instead ofThe fn is not an async fn. In either case, the diagnostic correctly says: Happens on both nightly: ... and stable:
This should hopefully be a fairly straightforward patch to the diagnostics code that generates the suggestion.

Related discussion:
text: <ins> // Regression test: if we suggest replacing an `impl Trait` argument to an async // fn with a named type parameter in order to add bounds, the suggested function // signature should be well-formed. // // edition:2018 trait Foo { type Bar; fn bar(&self) -> Self::Bar; } async fn run(_: &(), foo: impl Foo) -> std::io::Result<()> { let bar = foo.bar(); assert_is_send(&bar); //~^ ERROR: `<impl Foo as Foo>::Bar` cannot be sent between threads safely Ok(()) } // Test our handling of cases where there is a generic parameter list in the // source, but only synthetic generic parameters async fn run2< >(_: &(), foo: impl Foo) -> std::io::Result<()> { let bar = foo.bar(); assert_is_send(&bar); //~^ ERROR: `<impl Foo as Foo>::Bar` cannot be sent between threads safely Ok(()) } fn assert_is_send<T: Send>(_: &T) {} fn main() {} </ins>
Code change:
(Edit: Actually, being an inherent fn doesn't matter. It happens with top-level fns too.) This prints the diagnostic: The suggestion in the last line is not valid syntax (). It also emits malformed syntax if the first parameter is a or parameter. The diagnostic becomes well-formed if any of the following is done: The first parameter is changed to instead ofThe fn is not an async fn. In either case, the diagnostic correctly says: Happens on both nightly: ... and stable:
This should hopefully be a fairly straightforward patch to the diagnostics code that generates the suggestion.

Related discussion:
text: <ins> error[E0277]: `<impl Foo as Foo>::Bar` cannot be sent between threads safely --> $DIR/issue-79843-impl-trait-with-missing-bounds-on-async-fn.rs:14:20 | LL |     assert_is_send(&bar); |                    ^^^^ `<impl Foo as Foo>::Bar` cannot be sent between threads safely ... LL | fn assert_is_send<T: Send>(_: &T) {} |                      ---- required by this bound in `assert_is_send` | = help: the trait `Send` is not implemented for `<impl Foo as Foo>::Bar` help: introduce a type parameter with a trait bound instead of using `impl Trait` | LL | async fn run<F: Foo>(_: &(), foo: F) -> std::io::Result<()> where <F as Foo>::Bar: Send { |             ^^^^^^^^              ^                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^ error[E0277]: `<impl Foo as Foo>::Bar` cannot be sent between threads safely --> $DIR/issue-79843-impl-trait-with-missing-bounds-on-async-fn.rs:24:20 | LL |     assert_is_send(&bar); |                    ^^^^ `<impl Foo as Foo>::Bar` cannot be sent between threads safely ... LL | fn assert_is_send<T: Send>(_: &T) {} |                      ---- required by this bound in `assert_is_send` | = help: the trait `Send` is not implemented for `<impl Foo as Foo>::Bar` help: introduce a type parameter with a trait bound instead of using `impl Trait` | LL | async fn run2<F: Foo>(_: &(), foo: F) -> std::io::Result<()> where <F as Foo>::Bar: Send { |              ^^^^^^^^              ^                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0277`. </ins>
Code change:
The rustdoc search results page has three tabs of results: "In Names", "In Parameters", and "In Return Types". In my browser with the default theme, the selected tab heading is drawn in black on black. !
modify labels +T-rustdoc +A-rustdoc-ui +regression-from-stable-to-nightly
Yes, I've been having this too. You beat me to reporting this bug and ; thank you for making good reports!
I did some bisection and it seems the most likely cause is .
Ah, I think I know what the issue is.
Labeled as P-medium since I made the fix and it's in the bors queue.

Related discussion:
text: } #titles > button:hover, #titles > button.selected { <ins> background-color: #ffffff; </ins> border-top-color: #0089ff; <del> background-color: #353535; </del> } #titles > button > div.count {
Code change:
<!-- 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. --<!-- The steps to reproduce the bug. --(The actual target doesn't seem to matter, the feature just requires that we pass a argument.) The following error occurs: I think this issue occurs because already landed, while the cargo-side revert in did not. So this issue will likely go away after the next cargo update. I still decided to open this issue in case other people encounter the same problem. <!-- 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. --:
Cc for
This will be fixed by .

Related discussion:
text: ] [[package]] <ins> name = "cargo-credential" version = "0.1.0" [[package]] name = "cargo-credential-1password" version = "0.1.0" dependencies = [ "cargo-credential", "serde", "serde_json", ] [[package]] name = "cargo-credential-macos-keychain" version = "0.1.0" dependencies = [ "cargo-credential", "security-framework", ] [[package]] name = "cargo-credential-wincred" version = "0.1.0" dependencies = [ "cargo-credential", "winapi 0.3.9", ] [[package]] </ins> name = "cargo-miri" version = "0.1.0" dependencies = [
Code change:
<!-- 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. --<!-- The steps to reproduce the bug. --(The actual target doesn't seem to matter, the feature just requires that we pass a argument.) The following error occurs: I think this issue occurs because already landed, while the cargo-side revert in did not. So this issue will likely go away after the next cargo update. I still decided to open this issue in case other people encounter the same problem. <!-- 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. --:
Cc for
This will be fixed by .

Related discussion:
text: checksum = "d29ab0c6d3fc0ee92fe66e2d99f700eab17a8d57d1c1d3b748380fb20baa78cd" [[package]] <ins> name = "security-framework" version = "2.0.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "c1759c2e3c8580017a484a7ac56d3abc5a6c1feadf88db2f3633f12ae4268c69" dependencies = [ "bitflags", "core-foundation", "core-foundation-sys", "libc", "security-framework-sys", ] [[package]] name = "security-framework-sys" version = "2.0.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "f99b9d5e26d2a71633cc4f2ebae7cc9f874044e0c351a27e17892d76dce5678b" dependencies = [ "core-foundation-sys", "libc", ] [[package]] </ins> name = "semver" version = "0.9.0" source = "registry+https://github.com/rust-lang/crates.io-index"
Code change:
<!-- 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. --<!-- The steps to reproduce the bug. --(The actual target doesn't seem to matter, the feature just requires that we pass a argument.) The following error occurs: I think this issue occurs because already landed, while the cargo-side revert in did not. So this issue will likely go away after the next cargo update. I still decided to open this issue in case other people encounter the same problem. <!-- 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. --:
Cc for
This will be fixed by .

Related discussion:
text: [[package]] name = "serde" <del> version = "1.0.115" </del> <ins> version = "1.0.118" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "e54c9a88f2da7238af84b5101443f0c0d0a3bbdc455e34a5c9497b1903ed55d5" </del> <ins> checksum = "06c64263859d87aa2eb554587e2d23183398d617427327cf2b3d0ed8c69e4800" </ins> dependencies = [ "serde_derive", ] [[package]] name = "serde_derive" <del> version = "1.0.115" </del> <ins> version = "1.0.118" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "609feed1d0a73cc36a0182a840a9b37b4a82f0b1150369f0536a9e3f2a31dc48" </del> <ins> checksum = "c84d3526699cd55261af4b941e4e725444df67aa4f9e6a3564f18030d12672df" </ins> dependencies = [ "proc-macro2", "quote",
Code change:
<!-- 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. --<!-- The steps to reproduce the bug. --(The actual target doesn't seem to matter, the feature just requires that we pass a argument.) The following error occurs: I think this issue occurs because already landed, while the cargo-side revert in did not. So this issue will likely go away after the next cargo update. I still decided to open this issue in case other people encounter the same problem. <!-- 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. --:
Cc for
This will be fixed by .

Related discussion:
text: "src/tools/rust-installer", "src/tools/rust-demangler", "src/tools/cargo", <ins> "src/tools/cargo/crates/credential/cargo-credential-1password", "src/tools/cargo/crates/credential/cargo-credential-macos-keychain", "src/tools/cargo/crates/credential/cargo-credential-wincred", </ins> "src/tools/rustdoc", "src/tools/rls", "src/tools/rustfmt",
Code change:
<!-- 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. --<!-- The steps to reproduce the bug. --(The actual target doesn't seem to matter, the feature just requires that we pass a argument.) The following error occurs: I think this issue occurs because already landed, while the cargo-side revert in did not. So this issue will likely go away after the next cargo update. I still decided to open this issue in case other people encounter the same problem. <!-- 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. --:
Cc for
This will be fixed by .

Related discussion:
text: builder.create_dir(&image.join("etc/bash_completion.d")); let cargo = builder.ensure(tool::Cargo { compiler, target }); builder.install(&cargo, &image.join("bin"), 0o755); <ins> for dirent in fs::read_dir(cargo.parent().unwrap()).expect("read_dir") { let dirent = dirent.expect("read dir entry"); if dirent.file_name().to_str().expect("utf8").starts_with("cargo-credential-") { builder.install(&dirent.path(), &image.join("libexec"), 0o755); } } </ins> for man in t!(etc.join("man").read_dir()) { let man = t!(man); builder.install(&man.path(), &image.join("share/man/man1"), 0o644);
Code change:
<!-- 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. --<!-- The steps to reproduce the bug. --(The actual target doesn't seem to matter, the feature just requires that we pass a argument.) The following error occurs: I think this issue occurs because already landed, while the cargo-side revert in did not. So this issue will likely go away after the next cargo update. I still decided to open this issue in case other people encounter the same problem. <!-- 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. --:
Cc for
This will be fixed by .

Related discussion:
text: } fn run(self, builder: &Builder<'_>) -> PathBuf { <del> builder </del> <ins> let cargo_bin_path = builder </ins> .ensure(ToolBuild { compiler: self.compiler, target: self.target,
Code change:
<!-- 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. --<!-- The steps to reproduce the bug. --(The actual target doesn't seem to matter, the feature just requires that we pass a argument.) The following error occurs: I think this issue occurs because already landed, while the cargo-side revert in did not. So this issue will likely go away after the next cargo update. I still decided to open this issue in case other people encounter the same problem. <!-- 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. --:
Cc for
This will be fixed by .

Related discussion:
text: source_type: SourceType::Submodule, extra_features: Vec::new(), }) <del> .expect("expected to build -- essential tool") </del> <ins> .expect("expected to build -- essential tool"); let build_cred = |name, path| { // These credential helpers are currently experimental. // Any build failures will be ignored. let _ = builder.ensure(ToolBuild { compiler: self.compiler, target: self.target, tool: name, mode: Mode::ToolRustc, path, is_optional_tool: true, source_type: SourceType::Submodule, extra_features: Vec::new(), }); }; if self.target.contains("windows") { build_cred( "cargo-credential-wincred", "src/tools/cargo/crates/credential/cargo-credential-wincred", ); } if self.target.contains("apple-darwin") { build_cred( "cargo-credential-macos-keychain", "src/tools/cargo/crates/credential/cargo-credential-macos-keychain", ); } build_cred( "cargo-credential-1password", "src/tools/cargo/crates/credential/cargo-credential-1password", ); cargo_bin_path </ins> } }
Code change:
<!-- 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. --<!-- The steps to reproduce the bug. --(The actual target doesn't seem to matter, the feature just requires that we pass a argument.) The following error occurs: I think this issue occurs because already landed, while the cargo-side revert in did not. So this issue will likely go away after the next cargo update. I still decided to open this issue in case other people encounter the same problem. <!-- 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. --:
Cc for
This will be fixed by .

Related discussion:
text: <del> Subproject commit d274fcf862b89264fa2c6b917b15230705257317 </del> <ins> Subproject commit a3c2627fbc2f5391c65ba45ab53b81bf71fa323c </ins>
Code change:
I haven't been able to minimize this yet. The similar, already resolved, bug report doesn't seem to help - changing the 's return signature from to the full definition doesn't help here. The bug is also present in the nightly build (). <details<summary<strongBacktrace</strong</summary<p</p</details
:
Note the error goes away if you add , or if you change to . So I think the bug is that the trait bound is not being checked. cc
Triage: no change
No longe crashes with master toolchain
Crashing again after
This is also a compiles -ice regression
This never should have passed. Removing regression label; this can remain open to track the ICE.
no longer produces an ICE as of rust 1.81.0

Related discussion:
text: <ins> // check-pass #![allow(unreachable_code, unused)] use std::marker::PhantomData; struct FsmBuilder<TFsm> { _fsm: PhantomData<TFsm>, } impl<TFsm> FsmBuilder<TFsm> { fn state(&mut self) -> FsmStateBuilder<TFsm> { todo!() } } struct FsmStateBuilder<TFsm> { _state: PhantomData<TFsm>, } impl<TFsm> FsmStateBuilder<TFsm> { fn on_entry<TAction: Fn(&mut StateContext<'_, TFsm>)>(&self, _action: TAction) {} } trait Fsm { type Context; } struct StateContext<'a, TFsm: Fsm> { context: &'a mut TFsm::Context, } fn main() { let mut builder: FsmBuilder<usize> = todo!(); builder.state().on_entry(|_| {}); } </ins>
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --code from <!-- 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</detailsThis happens since cc
Oh my, I'll fix that now. The syntax is gated but evidently the flag can still reach into the parts which were not completed yet. Update: Ah but I misread the code, this is actually using const generics defaults. They're not done yet, ICE-ing is expected until the feature is completed in . how did you hit that ? Were you trying to use const generics defaults or did the ICE come up unexpectedly ? I can open a PR that will do nothing here instead of ICE-ing.
I made a small program that executes rustc on all the rust files with different flags and filters the ICEs. The file showed up as previously unknown crash.
On nightly-2020-12-31 (commit ), I get a parse error with the code you provided:
Yes, the PR was merged ~7 hours ago, it's not in nightly yet.
Ah, things move fast :) How did you get a build with the commit then? Did you use ?
There are inofficial "master" builds released for every merge commit in the repo (the latest one is then promoted to "nightly" once at some point of the day) You can install them with and run something like or afterwards.
Oh, I forgot about RTIM
will remove the ICE so that only the appears

Related discussion:
text: s.print_type_bounds(":", &param.bounds); if let Some(ref _default) = default { // FIXME(const_generics_defaults): print the `default` value here <del> todo!(); </del> } } }
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. --code from <!-- 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</detailsThis happens since cc
Oh my, I'll fix that now. The syntax is gated but evidently the flag can still reach into the parts which were not completed yet. Update: Ah but I misread the code, this is actually using const generics defaults. They're not done yet, ICE-ing is expected until the feature is completed in . how did you hit that ? Were you trying to use const generics defaults or did the ICE come up unexpectedly ? I can open a PR that will do nothing here instead of ICE-ing.
I made a small program that executes rustc on all the rust files with different flags and filters the ICEs. The file showed up as previously unknown crash.
On nightly-2020-12-31 (commit ), I get a parse error with the code you provided:
Yes, the PR was merged ~7 hours ago, it's not in nightly yet.
Ah, things move fast :) How did you get a build with the commit then? Did you use ?
There are inofficial "master" builds released for every merge commit in the repo (the latest one is then promoted to "nightly" once at some point of the day) You can install them with and run something like or afterwards.
Oh, I forgot about RTIM
will remove the ICE so that only the appears

Related discussion:
text: self.print_type(ty); if let Some(ref _default) = default { // FIXME(const_generics_defaults): print the `default` value here <del> todo!(); </del> } } }
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. --code from <!-- 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</detailsThis happens since cc
Oh my, I'll fix that now. The syntax is gated but evidently the flag can still reach into the parts which were not completed yet. Update: Ah but I misread the code, this is actually using const generics defaults. They're not done yet, ICE-ing is expected until the feature is completed in . how did you hit that ? Were you trying to use const generics defaults or did the ICE come up unexpectedly ? I can open a PR that will do nothing here instead of ICE-ing.
I made a small program that executes rustc on all the rust files with different flags and filters the ICEs. The file showed up as previously unknown crash.
On nightly-2020-12-31 (commit ), I get a parse error with the code you provided:
Yes, the PR was merged ~7 hours ago, it's not in nightly yet.
Ah, things move fast :) How did you get a build with the commit then? Did you use ?
There are inofficial "master" builds released for every merge commit in the repo (the latest one is then promoted to "nightly" once at some point of the day) You can install them with and run something like or afterwards.
Oh, I forgot about RTIM
will remove the ICE so that only the appears

Related discussion:
text: param_text.push_str(&ty_to_string(&ty)); if let Some(ref _default) = default { // FIXME(const_generics_defaults): push the `default` value here <del> todo!(); </del> } } if !param.bounds.is_empty() {