jiebi/CodeConvo huggingface dataset:
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. --I tried this code: I expected to see this happen: The warning fires on all three lines of , and the suggestions should only suggest removing the parentheses, not the attribute also. Instead, this happened: The fires on the first and last lines of , and the suggestion also removes the . No warning fires on the second line (but this is probably a separate issue, unrelated to attributes; it happens even when the attribute is removed; maybe overrides it or something). <!-- 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. --: Requires use of , otherwise the is not legal in that position (though note that the warning and suggestion is the same on stable, there's just an first). The issue is not specific to closures and , but that was the simplest example of a reasonable attribute-on-expression I thought of. label +A-diagnostics +requires-nightly <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim

Related discussion:
text: <ins> error: unnecessary parentheses around assigned value --> $DIR/unused-parens-for-stmt-expr-attributes-issue-129833.rs:9:13 | LL |     let _ = (#[inline] #[allow(dead_code)] || println!("Hello!")); |             ^                                                   ^ | note: the lint level is defined here --> $DIR/unused-parens-for-stmt-expr-attributes-issue-129833.rs:6:9 | LL | #![deny(unused_parens)] |         ^^^^^^^^^^^^^ help: remove these parentheses | LL -     let _ = (#[inline] #[allow(dead_code)] || println!("Hello!")); LL +     let _ = #[inline] #[allow(dead_code)] || println!("Hello!"); | error: unnecessary parentheses around block return value --> $DIR/unused-parens-for-stmt-expr-attributes-issue-129833.rs:10:5 | LL |     (#[inline] #[allow(dead_code)] || println!("Hello!")) |     ^                                                   ^ | help: remove these parentheses | LL -     (#[inline] #[allow(dead_code)] || println!("Hello!")) LL +     #[inline] #[allow(dead_code)] || println!("Hello!") | error: aborting due to 2 previous errors </ins>
Code change:
Ferrocene CI has detected that this test was broken by rust-lang/rust . Specifically, by the change in , shown below: Test output: Reverting that single line diff fixes the test for the QNX7.1 targets, e.g. and can the change be reverted or does QNX7.0 need to use , instead of , here? from looking at libc, it appears that both and are available on QNX7.0 so reverting the change should at least not cause compilation or linking errors. if the case is the latter, then we should use in addition to .
thanks for the report! I will need to re-test it for QNX 7.0, to see if it is a 7.0 requirement (i don't recall why this was required initially, but clearly I ran into some issues with it). I also plan to do a similar automation to ensure 7.0 builds run without problems on our hardware. Is there a list of tests you see failing on 7.1 that are OK to ignore? I see a list - is this the most relevant one? Thx!
we do not ignore any single unit test at the moment and we run library (e.g. libstd) tests as well as (cross) compilation tests using . we don't pass to but instead pass the list of test suites as arguments. we currently run these test suites:
WG-prioritization assigning priority (). label -I-prioritize +P-low
fixed in

Related discussion:
text: run_path_with_cstr(original, &|original| { run_path_with_cstr(link, &|link| { cfg_if::cfg_if! { <del> if #[cfg(any(target_os = "vxworks", target_os = "redox", target_os = "android", target_os = "espidf", target_os = "horizon", target_os = "vita", target_os = "nto"))] { </del> <ins> if #[cfg(any(target_os = "vxworks", target_os = "redox", target_os = "android", target_os = "espidf", target_os = "horizon", target_os = "vita", target_env = "nto70"))] { </ins> // VxWorks, Redox and ESP-IDF lack `linkat`, so use `link` instead. POSIX leaves // it implementation-defined whether `link` follows symlinks, so rely on the // `symlink_hard_link` test in library/std/src/fs/tests.rs to check the behavior.
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. --After adding to , I get the ICE. The resulting : The full project: <!-- 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. . --
Looks like another label: +T-types +WG-trait-system-refactor +regression-from-stable-to-nightly
Stable passes, beta passes. Nightly passes with either or Discovered with It does sporadically succeed, thus needing to clean and rerun the build to make sure. Either something is up with or it only barely exercises these conditions in the parallel frontend, even after cleaning and running the build 100 times. Meanwhile, fails something like ~50% of the time on my machine.
stable passes obviously, as -Zthreads this is a unstable nightly-only flag?
Hm, not actually obvious given that works, though I suppose that does mean it isn't a regression per se. :^)
oh I thought you knew by now that this is the forbidden env flag that should only ever be used for bootstrapping and nothing else and we should not even tell users about it. If you set the flag, your "stable" will also eat nightly-only features, but why would that make a "to-stable" regression if you explicitly tell the compiler "please act like you are NOT a stable release"? I don't think it make sense to backport fixes for untable nightly features into stable lol
who mentioned backports?
The label is used to gather regressions between release channels, which are then discussed whether they are backport-worthy or not. Is that not how the label is used?
I don't really think regression-from-stable-to-nightly nor regression-from-stable-to-stable are used for that at all? Probably regression-from-stable-to-beta is?

Related discussion:
text: } } <ins> fn evaluation_is_concurrent(&self) -> bool { self.sess.threads() > 1 } </ins> fn expand_abstract_consts<T: TypeFoldable<TyCtxt<'tcx>>>(self, t: T) -> T { self.expand_abstract_consts(t) }
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. --After adding to , I get the ICE. The resulting : The full project: <!-- 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. . --
Looks like another label: +T-types +WG-trait-system-refactor +regression-from-stable-to-nightly
Stable passes, beta passes. Nightly passes with either or Discovered with It does sporadically succeed, thus needing to clean and rerun the build to make sure. Either something is up with or it only barely exercises these conditions in the parallel frontend, even after cleaning and running the build 100 times. Meanwhile, fails something like ~50% of the time on my machine.
stable passes obviously, as -Zthreads this is a unstable nightly-only flag?
Hm, not actually obvious given that works, though I suppose that does mean it isn't a regression per se. :^)
oh I thought you knew by now that this is the forbidden env flag that should only ever be used for bootstrapping and nothing else and we should not even tell users about it. If you set the flag, your "stable" will also eat nightly-only features, but why would that make a "to-stable" regression if you explicitly tell the compiler "please act like you are NOT a stable release"? I don't think it make sense to backport fixes for untable nightly features into stable lol
who mentioned backports?
The label is used to gather regressions between release channels, which are then discussed whether they are backport-worthy or not. Is that not how the label is used?
I don't really think regression-from-stable-to-nightly nor regression-from-stable-to-stable are used for that at all? Probably regression-from-stable-to-beta is?

Related discussion:
text: f: impl FnOnce(&mut search_graph::GlobalCache<Self>) -> R, ) -> R; <ins> fn evaluation_is_concurrent(&self) -> bool; </ins> fn expand_abstract_consts<T: TypeFoldable<Self>>(self, t: T) -> T; type GenericsOf: GenericsOf<Self>;
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. --After adding to , I get the ICE. The resulting : The full project: <!-- 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. . --
Looks like another label: +T-types +WG-trait-system-refactor +regression-from-stable-to-nightly
Stable passes, beta passes. Nightly passes with either or Discovered with It does sporadically succeed, thus needing to clean and rerun the build to make sure. Either something is up with or it only barely exercises these conditions in the parallel frontend, even after cleaning and running the build 100 times. Meanwhile, fails something like ~50% of the time on my machine.
stable passes obviously, as -Zthreads this is a unstable nightly-only flag?
Hm, not actually obvious given that works, though I suppose that does mean it isn't a regression per se. :^)
oh I thought you knew by now that this is the forbidden env flag that should only ever be used for bootstrapping and nothing else and we should not even tell users about it. If you set the flag, your "stable" will also eat nightly-only features, but why would that make a "to-stable" regression if you explicitly tell the compiler "please act like you are NOT a stable release"? I don't think it make sense to backport fixes for untable nightly features into stable lol
who mentioned backports?
The label is used to gather regressions between release channels, which are then discussed whether they are backport-worthy or not. Is that not how the label is used?
I don't really think regression-from-stable-to-nightly nor regression-from-stable-to-stable are used for that at all? Probably regression-from-stable-to-beta is?

Related discussion:
text: ) -> R { I::with_global_cache(self, mode, f) } <ins> fn evaluation_is_concurrent(&self) -> bool { self.evaluation_is_concurrent() } </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. --After adding to , I get the ICE. The resulting : The full project: <!-- 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. . --
Looks like another label: +T-types +WG-trait-system-refactor +regression-from-stable-to-nightly
Stable passes, beta passes. Nightly passes with either or Discovered with It does sporadically succeed, thus needing to clean and rerun the build to make sure. Either something is up with or it only barely exercises these conditions in the parallel frontend, even after cleaning and running the build 100 times. Meanwhile, fails something like ~50% of the time on my machine.
stable passes obviously, as -Zthreads this is a unstable nightly-only flag?
Hm, not actually obvious given that works, though I suppose that does mean it isn't a regression per se. :^)
oh I thought you knew by now that this is the forbidden env flag that should only ever be used for bootstrapping and nothing else and we should not even tell users about it. If you set the flag, your "stable" will also eat nightly-only features, but why would that make a "to-stable" regression if you explicitly tell the compiler "please act like you are NOT a stable release"? I don't think it make sense to backport fixes for untable nightly features into stable lol
who mentioned backports?
The label is used to gather regressions between release channels, which are then discussed whether they are backport-worthy or not. Is that not how the label is used?
I don't really think regression-from-stable-to-nightly nor regression-from-stable-to-stable are used for that at all? Probably regression-from-stable-to-beta is?

Related discussion:
text: cx: X, input: X::Input, <del> result: X::Result, </del> <ins> origin_result: X::Result, </ins> dep_node: X::DepNodeIndex, additional_depth: usize, encountered_overflow: bool, nested_goals: NestedGoals<X>, ) { <del> let result = cx.mk_tracked(result, dep_node); </del> <ins> let result = cx.mk_tracked(origin_result, dep_node); </ins> let entry = self.map.entry(input).or_default(); if encountered_overflow { let with_overflow = WithOverflow { nested_goals, result }; let prev = entry.with_overflow.insert(additional_depth, with_overflow); <del> assert!(prev.is_none()); </del> <ins> if let Some(prev) = &prev { assert!(cx.evaluation_is_concurrent()); assert_eq!(cx.get_tracked(&prev.result), origin_result); } </ins> } else { let prev = entry.success.replace(Success { additional_depth, nested_goals, result }); <del> assert!(prev.is_none()); </del> <ins> if let Some(prev) = &prev { assert!(cx.evaluation_is_concurrent()); assert_eq!(cx.get_tracked(&prev.result), origin_result); } </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. --After adding to , I get the ICE. The resulting : The full project: <!-- 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. . --
Looks like another label: +T-types +WG-trait-system-refactor +regression-from-stable-to-nightly
Stable passes, beta passes. Nightly passes with either or Discovered with It does sporadically succeed, thus needing to clean and rerun the build to make sure. Either something is up with or it only barely exercises these conditions in the parallel frontend, even after cleaning and running the build 100 times. Meanwhile, fails something like ~50% of the time on my machine.
stable passes obviously, as -Zthreads this is a unstable nightly-only flag?
Hm, not actually obvious given that works, though I suppose that does mean it isn't a regression per se. :^)
oh I thought you knew by now that this is the forbidden env flag that should only ever be used for bootstrapping and nothing else and we should not even tell users about it. If you set the flag, your "stable" will also eat nightly-only features, but why would that make a "to-stable" regression if you explicitly tell the compiler "please act like you are NOT a stable release"? I don't think it make sense to backport fixes for untable nightly features into stable lol
who mentioned backports?
The label is used to gather regressions between release channels, which are then discussed whether they are backport-worthy or not. Is that not how the label is used?
I don't really think regression-from-stable-to-nightly nor regression-from-stable-to-stable are used for that at all? Probably regression-from-stable-to-beta is?

Related discussion:
text: mode: SolverMode, f: impl FnOnce(&mut GlobalCache<Self>) -> R, ) -> R; <ins> fn evaluation_is_concurrent(&self) -> bool; </ins> } pub trait Delegate {
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. --After adding to , I get the ICE. The resulting : The full project: <!-- 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. . --
Looks like another label: +T-types +WG-trait-system-refactor +regression-from-stable-to-nightly
Stable passes, beta passes. Nightly passes with either or Discovered with It does sporadically succeed, thus needing to clean and rerun the build to make sure. Either something is up with or it only barely exercises these conditions in the parallel frontend, even after cleaning and running the build 100 times. Meanwhile, fails something like ~50% of the time on my machine.
stable passes obviously, as -Zthreads this is a unstable nightly-only flag?
Hm, not actually obvious given that works, though I suppose that does mean it isn't a regression per se. :^)
oh I thought you knew by now that this is the forbidden env flag that should only ever be used for bootstrapping and nothing else and we should not even tell users about it. If you set the flag, your "stable" will also eat nightly-only features, but why would that make a "to-stable" regression if you explicitly tell the compiler "please act like you are NOT a stable release"? I don't think it make sense to backport fixes for untable nightly features into stable lol
who mentioned backports?
The label is used to gather regressions between release channels, which are then discussed whether they are backport-worthy or not. Is that not how the label is used?
I don't really think regression-from-stable-to-nightly nor regression-from-stable-to-stable are used for that at all? Probably regression-from-stable-to-beta is?

Related discussion:
text: <ins> //@ compile-flags: -Zthreads=16 // original issue: https://github.com/rust-lang/rust/issues/129112 // Previously, the "next" solver asserted that each successful solution is only obtained once. // This test exhibits a repro that, with next-solver + -Zthreads, triggered that old assert. // In the presence of multithreaded solving, it's possible to concurrently evaluate things twice, // which leads to replacing already-solved solutions in the global solution cache! // We assume this is fine if we check to make sure they are solved the same way each time. // This test only nondeterministically fails but that's okay, as it will be rerun by CI many times, // so it should almost always fail before anything is merged. As other thread tests already exist, // we already face this difficulty, probably. If we need to fix this by reducing the error margin, // we should improve compiletest. #[derive(Clone, Eq)] //~ ERROR [E0277] pub struct Struct<T>(T); impl<T: Clone, U> PartialEq<U> for Struct<T> where U: Into<Struct<T>> + Clone { fn eq(&self, _other: &U) -> bool { todo!() } } fn main() {} </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. --After adding to , I get the ICE. The resulting : The full project: <!-- 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. . --
Looks like another label: +T-types +WG-trait-system-refactor +regression-from-stable-to-nightly
Stable passes, beta passes. Nightly passes with either or Discovered with It does sporadically succeed, thus needing to clean and rerun the build to make sure. Either something is up with or it only barely exercises these conditions in the parallel frontend, even after cleaning and running the build 100 times. Meanwhile, fails something like ~50% of the time on my machine.
stable passes obviously, as -Zthreads this is a unstable nightly-only flag?
Hm, not actually obvious given that works, though I suppose that does mean it isn't a regression per se. :^)
oh I thought you knew by now that this is the forbidden env flag that should only ever be used for bootstrapping and nothing else and we should not even tell users about it. If you set the flag, your "stable" will also eat nightly-only features, but why would that make a "to-stable" regression if you explicitly tell the compiler "please act like you are NOT a stable release"? I don't think it make sense to backport fixes for untable nightly features into stable lol
who mentioned backports?
The label is used to gather regressions between release channels, which are then discussed whether they are backport-worthy or not. Is that not how the label is used?
I don't really think regression-from-stable-to-nightly nor regression-from-stable-to-stable are used for that at all? Probably regression-from-stable-to-beta is?

Related discussion:
text: <ins> error[E0277]: the trait bound `T: Clone` is not satisfied --> $DIR/global-cache-and-parallel-frontend.rs:15:17 | LL | #[derive(Clone, Eq)] |                 ^^ the trait `Clone` is not implemented for `T`, which is required by `Struct<T>: PartialEq` | note: required for `Struct<T>` to implement `PartialEq` --> $DIR/global-cache-and-parallel-frontend.rs:18:19 | LL | impl<T: Clone, U> PartialEq<U> for Struct<T> |         -----     ^^^^^^^^^^^^     ^^^^^^^^^ |         | |         unsatisfied trait bound introduced here note: required by a bound in `Eq` --> $SRC_DIR/core/src/cmp.rs:LL:COL = note: this error originates in the derive macro `Eq` (in Nightly builds, run with -Z macro-backtrace for more info) help: consider restricting type parameter `T` | LL | pub struct Struct<T: std::clone::Clone>(T); |                    +++++++++++++++++++ error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0277`. </ins>
Code change:
() Reproduces on the playground using . label +D-incorrect +F-gen_blocks +requires-nightly

Related discussion:
text: } } <del> pub fn is_async(self) -> bool { matches!(self, CoroutineKind::Async { .. }) } pub fn is_gen(self) -> bool { matches!(self, CoroutineKind::Gen { .. }) </del> <ins> pub fn as_str(self) -> &'static str { match self { CoroutineKind::Async { .. } => "async", CoroutineKind::Gen { .. } => "gen", CoroutineKind::AsyncGen { .. } => "async gen", } </ins> } pub fn closure_id(self) -> NodeId {
Code change:
() Reproduces on the playground using . label +D-incorrect +F-gen_blocks +requires-nightly

Related discussion:
text: ast_passes_bound_in_context = bounds on `type`s in {$ctx} have no effect <del> ast_passes_const_and_async = functions cannot be both `const` and `async` .const = `const` because of this .async = `async` because of this .label = {""} </del> ast_passes_const_and_c_variadic = functions cannot be both `const` and C-variadic .const = `const` because of this .variadic = C-variadic because of this <ins> ast_passes_const_and_coroutine = functions cannot be both `const` and `{$coroutine_kind}` .const = `const` because of this .coroutine = `{$coroutine_kind}` because of this .label = {""} </ins> ast_passes_const_bound_trait_object = const trait bounds are not allowed in trait object types ast_passes_const_without_body =
Code change:
() Reproduces on the playground using . label +D-incorrect +F-gen_blocks +requires-nightly

Related discussion:
text: // Functions cannot both be `const async` or `const gen` if let Some(&FnHeader { <del> constness: Const::Yes(cspan), </del> <ins> constness: Const::Yes(const_span), </ins> coroutine_kind: Some(coroutine_kind), .. }) = fk.header() { <del> let aspan = match coroutine_kind { CoroutineKind::Async { span: aspan, .. } | CoroutineKind::Gen { span: aspan, .. } | CoroutineKind::AsyncGen { span: aspan, .. } => aspan, }; // FIXME(gen_blocks): Report a different error for `const gen` self.dcx().emit_err(errors::ConstAndAsync { spans: vec![cspan, aspan], cspan, aspan, </del> <ins> self.dcx().emit_err(errors::ConstAndCoroutine { spans: vec![coroutine_kind.span(), const_span], const_span, coroutine_span: coroutine_kind.span(), coroutine_kind: coroutine_kind.as_str(), </ins> span, }); }