jiebi/CodeConvo huggingface dataset:
Code change:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --Nearly 50% performance regression between versions 1.71 and 1.72 when copying small byte arrays with platform (Macbook Pro M1). Used to track down the regression to I tried this code: I expected to see this happen: to run about 6,200,000 ns/iter like version 1.71 Instead, this happened: 9,159,412 ns/iter <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.71 More specifically nightly-2023-06-06-aarch64-apple-darwin 72 nightly-2023-06-07-aarch64-apple-darwin <!-- Provide the version you are using that has the regression. --: Searched nightlies: from nightly-2023-06-06 to nightly-2023-06-07 regressed nightly: nightly-2023-06-07 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-apple-darwin Reproduce with: </details modify labels: +regression-from-stable-to-stable -regression-untriaged
Here's a demo for :
Oof, that's massively worse. But even with a nice size (), it's still a small regression: We should probably revert , or limit it to very small arrays (<= 8 bytes / 1 usize? )
The original motivation of that PR is for arrays larger than that, so I'm not so sure. If I strip this down to just the pointer write it's not as bad, but it's quite clear that the problem is just x86-isel: Is that even good instruction selection?
Hmm, curiously looking at just the part of the push logic that copies the value, the assembly is entirely reasonable: then in the context of a "real" push, it somehow still blows up:
Here's a small tweak to try to fix this for 1.73:
I've opened to track the suboptimal codegen mentioned in Once a new nightly is out, please give it a shot and reopen if you're still seeing the regression.
On Ubuntu VM running on Ryzen 5950X this is far worse: 4x regression.
Things look much better with . Thanks for the quick fix!
Thanks for confirming! I'll see if it can make 1.73.

Related discussion:
text: // Vectors, even for non-power-of-two sizes, have the same layout as // arrays but don't count as aggregate types <ins> // While LLVM theoretically supports non-power-of-two sizes, and they // often work fine, sometimes x86-isel deals with them horribly // (see #115212) so for now only use power-of-two ones. </ins> if let FieldsShape::Array { count, .. } = self.layout.fields() <ins> && count.is_power_of_two() </ins> && let element = self.field(cx, 0) && element.ty.is_integral() {
Code change:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --Nearly 50% performance regression between versions 1.71 and 1.72 when copying small byte arrays with platform (Macbook Pro M1). Used to track down the regression to I tried this code: I expected to see this happen: to run about 6,200,000 ns/iter like version 1.71 Instead, this happened: 9,159,412 ns/iter <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.71 More specifically nightly-2023-06-06-aarch64-apple-darwin 72 nightly-2023-06-07-aarch64-apple-darwin <!-- Provide the version you are using that has the regression. --: Searched nightlies: from nightly-2023-06-06 to nightly-2023-06-07 regressed nightly: nightly-2023-06-07 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-apple-darwin Reproduce with: </details modify labels: +regression-from-stable-to-stable -regression-untriaged
Here's a demo for :
Oof, that's massively worse. But even with a nice size (), it's still a small regression: We should probably revert , or limit it to very small arrays (<= 8 bytes / 1 usize? )
The original motivation of that PR is for arrays larger than that, so I'm not so sure. If I strip this down to just the pointer write it's not as bad, but it's quite clear that the problem is just x86-isel: Is that even good instruction selection?
Hmm, curiously looking at just the part of the push logic that copies the value, the assembly is entirely reasonable: then in the context of a "real" push, it somehow still blows up:
Here's a small tweak to try to fix this for 1.73:
I've opened to track the suboptimal codegen mentioned in Once a new nightly is out, please give it a shot and reopen if you're still seeing the regression.
On Ubuntu VM running on Ryzen 5950X this is far worse: 4x regression.
Things look much better with . Thanks for the quick fix!
Thanks for confirming! I'll see if it can make 1.73.

Related discussion:
text: // CHECK-LABEL: @swap_rgb48_manually( #[no_mangle] pub fn swap_rgb48_manually(x: &mut RGB48, y: &mut RGB48) { <del> // CHECK-NOT: alloca // CHECK: %[[TEMP0:.+]] = load <3 x i16>, ptr %x, align 2 // CHECK: %[[TEMP1:.+]] = load <3 x i16>, ptr %y, align 2 // CHECK: store <3 x i16> %[[TEMP1]], ptr %x, align 2 // CHECK: store <3 x i16> %[[TEMP0]], ptr %y, align 2 </del> <ins> // FIXME: See #115212 for why this has an alloca again // CHECK: alloca [3 x i16], align 2 // CHECK: call void @llvm.memcpy.p0.p0.i64({{.+}}, i64 6, i1 false) // CHECK: call void @llvm.memcpy.p0.p0.i64({{.+}}, i64 6, i1 false) // CHECK: call void @llvm.memcpy.p0.p0.i64({{.+}}, i64 6, i1 false) </ins> let temp = *x; *x = *y;
Code change:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --Nearly 50% performance regression between versions 1.71 and 1.72 when copying small byte arrays with platform (Macbook Pro M1). Used to track down the regression to I tried this code: I expected to see this happen: to run about 6,200,000 ns/iter like version 1.71 Instead, this happened: 9,159,412 ns/iter <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.71 More specifically nightly-2023-06-06-aarch64-apple-darwin 72 nightly-2023-06-07-aarch64-apple-darwin <!-- Provide the version you are using that has the regression. --: Searched nightlies: from nightly-2023-06-06 to nightly-2023-06-07 regressed nightly: nightly-2023-06-07 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-apple-darwin Reproduce with: </details modify labels: +regression-from-stable-to-stable -regression-untriaged
Here's a demo for :
Oof, that's massively worse. But even with a nice size (), it's still a small regression: We should probably revert , or limit it to very small arrays (<= 8 bytes / 1 usize? )
The original motivation of that PR is for arrays larger than that, so I'm not so sure. If I strip this down to just the pointer write it's not as bad, but it's quite clear that the problem is just x86-isel: Is that even good instruction selection?
Hmm, curiously looking at just the part of the push logic that copies the value, the assembly is entirely reasonable: then in the context of a "real" push, it somehow still blows up:
Here's a small tweak to try to fix this for 1.73:
I've opened to track the suboptimal codegen mentioned in Once a new nightly is out, please give it a shot and reopen if you're still seeing the regression.
On Ubuntu VM running on Ryzen 5950X this is far worse: 4x regression.
Things look much better with . Thanks for the quick fix!
Thanks for confirming! I'll see if it can make 1.73.

Related discussion:
text: // CHECK-LABEL: @swap_rgb48 #[no_mangle] pub fn swap_rgb48(x: &mut RGB48, y: &mut RGB48) { <ins> // FIXME: See #115212 for why this has an alloca again // CHECK: alloca [3 x i16], align 2 // CHECK: call void @llvm.memcpy.p0.p0.i64({{.+}}, i64 6, i1 false) // CHECK: call void @llvm.memcpy.p0.p0.i64({{.+}}, i64 6, i1 false) // CHECK: call void @llvm.memcpy.p0.p0.i64({{.+}}, i64 6, i1 false) swap(x, y) } type RGBA64 = [u16; 4]; // CHECK-LABEL: @swap_rgba64 #[no_mangle] pub fn swap_rgba64(x: &mut RGBA64, y: &mut RGBA64) { </ins> // CHECK-NOT: alloca <del> // CHECK: load <3 x i16> // CHECK: load <3 x i16> // CHECK: store <3 x i16> // CHECK: store <3 x i16> </del> <ins> // CHECK-DAG: %[[XVAL:.+]] = load <4 x i16>, ptr %x, align 2 // CHECK-DAG: %[[YVAL:.+]] = load <4 x i16>, ptr %y, align 2 // CHECK-DAG: store <4 x i16> %[[YVAL]], ptr %x, align 2 // CHECK-DAG: store <4 x i16> %[[XVAL]], ptr %y, align 2 </ins> swap(x, y) }
Code change:
I tried this code: I expected it to compile successfully. Instead, this happened: It most recently worked on 1.72 Regressed in cc Originally reported in cc modify labels: +regression-from-stable-to-beta -regression-untriaged
WG-prioritization assigning priority (). label -I-prioritize +P-high

Related discussion:
text: // needs drop. let adt_has_dtor = |adt_def: ty::AdtDef<'tcx>| adt_def.destructor(tcx).map(|_| DtorType::Significant); <del> let res = drop_tys_helper(tcx, query.value, query.param_env, adt_has_dtor, false).next().is_some(); </del> <ins> let res = drop_tys_helper(tcx, query.value, query.param_env, adt_has_dtor, false) .filter(filter_array_elements(tcx, query.param_env)) .next() .is_some(); </ins> debug!("needs_drop_raw({:?}) = {:?}", query, res); res } <ins> /// HACK: in order to not mistakenly assume that `[PhantomData<T>; N]` requires drop glue /// we check the element type for drop glue. The correct fix would be looking at the /// entirety of the code around `needs_drop_components` and this file and come up with /// logic that is easier to follow while not repeating any checks that may thus diverge. fn filter_array_elements<'tcx>( tcx: TyCtxt<'tcx>, param_env: ty::ParamEnv<'tcx>, ) -> impl Fn(&Result<Ty<'tcx>, AlwaysRequiresDrop>) -> bool { move |ty| match ty { Ok(ty) => match *ty.kind() { ty::Array(elem, _) => tcx.needs_drop_raw(param_env.and(elem)), _ => true, }, Err(AlwaysRequiresDrop) => true, } } </ins> fn has_significant_drop_raw<'tcx>( tcx: TyCtxt<'tcx>, query: ty::ParamEnvAnd<'tcx, Ty<'tcx>>,
Code change:
I tried this code: I expected it to compile successfully. Instead, this happened: It most recently worked on 1.72 Regressed in cc Originally reported in cc modify labels: +regression-from-stable-to-beta -regression-untriaged
WG-prioritization assigning priority (). label -I-prioritize +P-high

Related discussion:
text: adt_consider_insignificant_dtor(tcx), true, ) <ins> .filter(filter_array_elements(tcx, query.param_env)) </ins> .next() .is_some(); debug!("has_significant_drop_raw({:?}) = {:?}", query, res);
Code change:
I tried this code: I expected it to compile successfully. Instead, this happened: It most recently worked on 1.72 Regressed in cc Originally reported in cc modify labels: +regression-from-stable-to-beta -regression-untriaged
WG-prioritization assigning priority (). label -I-prioritize +P-high

Related discussion:
text: <ins> // build-pass pub const fn f<T, const N: usize>(_: [std::mem::MaybeUninit<T>; N]) {} pub struct Blubb<T>(*const T); pub const fn g<T, const N: usize>(_: [Blubb<T>; N]) {} pub struct Blorb<const N: usize>([String; N]); pub const fn h(_: Blorb<0>) {} pub struct Wrap(Blorb<0>); pub const fn i(_: Wrap) {} fn main() {} </ins>
Code change:
I tried this code: I expected to see this happen: The lint is allowed. Instead, this happened: The lint still triggers. (Applying to the entire module works). (I'm assuming that this is unintentional, thus reporting as a "bug". If this behavior is intentional, consider this a feature request to change it). Latest playground nightly:
The problem here is that the lint is associated with the private item, not the item which names it in its bounds:
cc

Related discussion:
text: }; let vis = self.tcx.local_visibility(local_def_id); <del> let hir_id = self.tcx.hir().local_def_id_to_hir_id(local_def_id); </del> let span = self.tcx.def_span(self.item_def_id.to_def_id()); let vis_span = self.tcx.def_span(def_id); if self.in_assoc_ty && !vis.is_at_least(self.required_visibility, self.tcx) { let vis_descr = match vis { ty::Visibility::Public => "public", ty::Visibility::Restricted(vis_def_id) => { <del> if vis_def_id == self.tcx.parent_module(hir_id).to_local_def_id() { </del> <ins> if vis_def_id == self.tcx.parent_module_from_def_id(local_def_id).to_local_def_id() { </ins> "private" } else if vis_def_id.is_top_level_module() { "crate-private"
Code change:
I tried this code: I expected to see this happen: The lint is allowed. Instead, this happened: The lint still triggers. (Applying to the entire module works). (I'm assuming that this is unintentional, thus reporting as a "bug". If this behavior is intentional, consider this a feature request to change it). Latest playground nightly:
The problem here is that the lint is associated with the private item, not the item which names it in its bounds:
cc

Related discussion:
text: }; self.tcx.emit_spanned_lint( lint, <del> hir_id, </del> <ins> self.tcx.hir().local_def_id_to_hir_id(self.item_def_id), </ins> span, PrivateInterfacesOrBoundsLint { item_span: span,
Code change:
I tried this code: I expected to see this happen: The lint is allowed. Instead, this happened: The lint still triggers. (Applying to the entire module works). (I'm assuming that this is unintentional, thus reporting as a "bug". If this behavior is intentional, consider this a feature request to change it). Latest playground nightly:
The problem here is that the lint is associated with the private item, not the item which names it in its bounds:
cc

Related discussion:
text: <ins> // check-pass // compile-flags: --crate-type=lib #[allow(private_bounds)] pub trait Foo: FooImpl {} trait FooImpl {} </ins>
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <details<summary<strongError output</strong</summary<p</p</details<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Regression in nightly-2022-09-05 commit[0] 2022-09-03: Auto merge of - cjgillot:old-no-lt, r=estebank commit[1] 2022-09-04: Auto merge of - matthiaskrgr:rollup-9n0257m, r=matthiaskrgr commit[2] 2022-09-04: Auto merge of - nikic:update-llvm-7, r=cuviper commit[3] 2022-09-04: Auto merge of - jswrenn:transmute, r=oli-obk commit[4] 2022-09-04: Auto merge of - klensy:bump-deps-08-22, r=Dylan-DPC commit[5] 2022-09-04: Auto merge of - compiler-errors:head-span-for-enclosing-scope, r=oli-obk commit[6] 2022-09-04: Auto merge of - matthiaskrgr:rollup-uj24yb5, r=matthiaskrgr commit[7] 2022-09-04: Auto merge of - asquared31415:vec-zero-opts, r=thomcc
Minimal: This has nothing to do with the transmutability feature. Also, it's fixed by , since the above desugars to:
WG-prioritization assigning priority (). label -I-prioritize +P-medium -needs-triage
This is but needs a test. To whoever does it, please commit the example I minimized and not the other one, since we don't need to make the test depend on the transmutability feature.

Related discussion:
text: <ins> // Test for issues/115517 which is fixed by pull/115486 // This should not ice trait Test<const C: usize> {} trait Elide<T> { fn call(); } pub fn test() where (): Test<{ 1 + (<() as Elide(&())>::call) }>, //~^ ERROR cannot capture late-bound lifetime in constant { } 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. --<!-- 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. --: <details<summary<strongError output</strong</summary<p</p</details<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Regression in nightly-2022-09-05 commit[0] 2022-09-03: Auto merge of - cjgillot:old-no-lt, r=estebank commit[1] 2022-09-04: Auto merge of - matthiaskrgr:rollup-9n0257m, r=matthiaskrgr commit[2] 2022-09-04: Auto merge of - nikic:update-llvm-7, r=cuviper commit[3] 2022-09-04: Auto merge of - jswrenn:transmute, r=oli-obk commit[4] 2022-09-04: Auto merge of - klensy:bump-deps-08-22, r=Dylan-DPC commit[5] 2022-09-04: Auto merge of - compiler-errors:head-span-for-enclosing-scope, r=oli-obk commit[6] 2022-09-04: Auto merge of - matthiaskrgr:rollup-uj24yb5, r=matthiaskrgr commit[7] 2022-09-04: Auto merge of - asquared31415:vec-zero-opts, r=thomcc
Minimal: This has nothing to do with the transmutability feature. Also, it's fixed by , since the above desugars to:
WG-prioritization assigning priority (). label -I-prioritize +P-medium -needs-triage
This is but needs a test. To whoever does it, please commit the example I minimized and not the other one, since we don't need to make the test depend on the transmutability feature.

Related discussion:
text: <ins> error: cannot capture late-bound lifetime in constant --> $DIR/escaping_bound_vars.rs:11:35 | LL |     (): Test<{ 1 + (<() as Elide(&())>::call) }>, |                                  -^ |                                  | |                                  lifetime defined here error: aborting due to previous error </ins>
Code change:
() never finishes building the crate (0.11.3) when building with optimizations. Regression is exactly in the LLVM 17 upgrade: <details<summaryBacktrace</summary<p</p</details modify labels: +regression-from-stable-to-nightly -regression-untriaged
WG-prioritization assigning priority (). is it clear by looking at he stacktrace what kind of code is involved that causes the issue? I'm thinking if a smaller reproducible can help. label -I-prioritize +P-high
Can reproduce also with (to skip installing the asm dependency)
Problematic IR: Based on output, it looks like we go into an infinite loop unswitching loop.
Here is a test case for :
I've filed This appears to be related to the new invariant condition injection.

Related discussion:
text: <del> Subproject commit 42263494d29febc26d3c1ebdaa7b63677573ec47 </del> <ins> Subproject commit d404cba4e39df595710869988ded7cbe1104b52f </ins>
Code change:
The documentation of the macro currently does not mention at all that it also accepts optional format arguments, for example: Other macros like at least have the following sentence under "Panics": So maybe it would be good to do the following? [ ] Update the "Panics" section to be similar to [ ] Extend / adjust example to also show usage of custom message <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Any ? I mostly drew from the docs for , and I also took the liberty of cleaning up some of the formatting/typography.
Thanks! To me this looks good, but I don't know what the maintainers think.

Related discussion:
text: /// The difference between `unimplemented!` and [`todo!`] is that while `todo!` /// conveys an intent of implementing the functionality later and the message is "not yet /// implemented", `unimplemented!` makes no such claims. Its message is "not implemented". <del> /// Also some IDEs will mark `todo!`s. </del> <ins> /// /// Also, some IDEs will mark `todo!`s. </ins> /// /// # Panics ///
Code change:
The documentation of the macro currently does not mention at all that it also accepts optional format arguments, for example: Other macros like at least have the following sentence under "Panics": So maybe it would be good to do the following? [ ] Update the "Panics" section to be similar to [ ] Extend / adjust example to also show usage of custom message <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Any ? I mostly drew from the docs for , and I also took the liberty of cleaning up some of the formatting/typography.
Thanks! To me this looks good, but I don't know what the maintainers think.

Related discussion:
text: /// The difference between [`unimplemented!`] and `todo!` is that while `todo!` conveys /// an intent of implementing the functionality later and the message is "not yet /// implemented", `unimplemented!` makes no such claims. Its message is "not implemented". <del> /// Also some IDEs will mark `todo!`s. </del> <ins> /// /// Also, some IDEs will mark `todo!`s. </ins> /// /// # Panics /// <del> /// This will always [`panic!`]. </del> <ins> /// This will always [`panic!`] because `todo!` is just a shorthand for `panic!` with a /// fixed, specific message. /// /// Like `panic!`, this macro has a second form for displaying custom values. </ins> /// /// # Examples ///
Code change:
The documentation of the macro currently does not mention at all that it also accepts optional format arguments, for example: Other macros like at least have the following sentence under "Panics": So maybe it would be good to do the following? [ ] Update the "Panics" section to be similar to [ ] Extend / adjust example to also show usage of custom message <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Any ? I mostly drew from the docs for , and I also took the liberty of cleaning up some of the formatting/typography.
Thanks! To me this looks good, but I don't know what the maintainers think.

Related discussion:
text: /// /// ``` /// trait Foo { <del> ///     fn bar(&self); </del> <ins> ///     fn bar(&self) -> u8; </ins> ///     fn baz(&self); <ins> ///     fn qux(&self) -> Result<u64, ()>; </ins> /// } /// ``` /// /// We want to implement `Foo` on one of our types, but we also want to work on /// just `bar()` first. In order for our code to compile, we need to implement <del> /// `baz()`, so we can use `todo!`: </del> <ins> /// `baz()` and `qux()`, so we can use `todo!`: </ins> /// /// ``` /// # trait Foo { <del> /// #     fn bar(&self); </del> <ins> /// #     fn bar(&self) -> u8; </ins> /// #     fn baz(&self); <ins> /// #     fn qux(&self) -> Result<u64, ()>; </ins> /// # } /// struct MyStruct; /// /// impl Foo for MyStruct { <del> ///     fn bar(&self) { ///         // implementation goes here </del> <ins> ///     fn bar(&self) -> u8 { ///         1 + 1 </ins> ///     } /// ///     fn baz(&self) { <del> ///         // let's not worry about implementing baz() for now </del> <ins> ///         // Let's not worry about implementing baz() for now </ins> ///         todo!(); ///     } <ins> /// ///     fn qux(&self) -> Result<u64, ()> { ///         // We can add a message to todo! to display our omission. ///         // This will display: ///         // "thread 'main' panicked at 'not yet implemented: MyStruct is not yet quxable'". ///         todo!("MyStruct is not yet quxable"); ///     } </ins> /// } /// /// fn main() { ///     let s = MyStruct; ///     s.bar(); /// <del> ///     // we aren't even using baz(), so this is fine. </del> <ins> ///     // We aren't even using baz() or qux(), so this is fine. </ins> /// } /// ``` #[macro_export]