jiebi/CodeConvo huggingface dataset:
Code change:
searched nightlies: from nightly-2023-01-27 to nightly-2023-01-28 regressed nightly: nightly-2023-01-28 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details label +I-ICE +F-typealiasimpltrait
Minimized it further:

Related discussion:
text: <ins> // run-rustfix use std::pin::Pin; fn foo(_: &mut ()) {} fn main() { let mut uwu = (); let mut r = Pin::new(&mut uwu); foo(r.as_mut().get_mut()); foo(r.get_mut()); //~ ERROR use of moved value } </ins>
Code change:
searched nightlies: from nightly-2023-01-27 to nightly-2023-01-28 regressed nightly: nightly-2023-01-28 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details label +I-ICE +F-typealiasimpltrait
Minimized it further:

Related discussion:
text: <ins> // run-rustfix use std::pin::Pin; fn foo(_: &mut ()) {} fn main() { let mut uwu = (); let mut r = Pin::new(&mut uwu); foo(r.get_mut()); foo(r.get_mut()); //~ ERROR use of moved value } </ins>
Code change:
searched nightlies: from nightly-2023-01-27 to nightly-2023-01-28 regressed nightly: nightly-2023-01-28 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details label +I-ICE +F-typealiasimpltrait
Minimized it further:

Related discussion:
text: <ins> error[E0382]: use of moved value: `r` --> $DIR/pin-mut-reborrow-infer-var-issue-107419.rs:10:9 | LL |     let mut r = Pin::new(&mut uwu); |         ----- move occurs because `r` has type `Pin<&mut ()>`, which does not implement the `Copy` trait LL |     foo(r.get_mut()); |           --------- `r` moved due to this method call LL |     foo(r.get_mut()); |         ^ value used here after move | note: `Pin::<&'a mut T>::get_mut` takes ownership of the receiver `self`, which moves `r` --> $SRC_DIR/core/src/pin.rs:LL:COL help: consider reborrowing the `Pin` instead of moving it | LL |     foo(r.as_mut().get_mut()); |           +++++++++ error: aborting due to previous error For more information about this error, try `rustc --explain E0382`. </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. --Example code: In rustc 1.67 stable this generates a number of moves (I suppose for calling convention?) that I don't think need to be there, especially when inlining: See While this is a pretty pointless example, this comes up in situations where you might want to convert a tuple of slices into a struct of slices in order to assign names to the tuple members.
LLVM should probably be able to elide the below and pass the original pointer. label +A-llvm +I-slow
This seems to be resolved on current nightly by & Thanks :tada: (I'm not so sure about an incoming inherent problem on alignment attribute)
Fixed as part of the LLVM 17 update (), needs codegen test.
Making the sum a little more vague than the above code prevents the removal of memcpy. Edit: It seems like not so, precisely, the above argument is a function pointer, not a closure, and I now think function pointers never capture any variables (because of ?, ). So is this another missing opportunity?
Yes, the removal is only allowed in the original example, because the called function is known. It does not work with an unknown function due to missing . Note that the is on the by-value argument of , not the by-reference argument of the function pointer .
That sounds reasonable. Thanks! So, in this case, if the assumption that the function pointer never captures the argument was correct, missing attribution opportunities for the callbase?
I don't think there is any missing attribution opportunity here. In your example, if is nocapture, then that does not imply anything about being nocapture (it's a completely different object). Even if you directly passed through the argument to the call (without intermediate memcpy to alloca), inferring nocapture is still not straightforward, because allows interior captures (i.e. it's possible to capture the pointer within the function, as long as it does not stay captured after the function returns).
(Edit: Now I think that on case, capturing in LLVM might happen. Thanks!

Related discussion:
text: <ins> // Verify that move before the call of the function with noalias, nocapture, readonly. // #107436 // compile-flags: -O // min-llvm-version: 17 #![crate_type = "lib"] #[repr(C)] pub struct ThreeSlices<'a>(&'a [u32], &'a [u32], &'a [u32]); #[no_mangle] pub fn sum_slices(val: ThreeSlices) -> u32 { // CHECK-NOT: memcpy let val = val; sum(&val) } #[no_mangle] #[inline(never)] pub fn sum(val: &ThreeSlices) -> u32 { val.0.iter().sum::<u32>() + val.1.iter().sum::<u32>() + val.2.iter().sum::<u32>() } </ins>
Code change:
I tried this code: I expected to see the warning: Instead no warning was reported by the compiler. Observed in nightly, 1.67. Seems like the warning was shown in 1.63 and stopped showing in 1.64.
Bisected to CI has expired so I couldn't automatically bisect further, but looks like a likely candidate
It looks like the issue is that dead code detection doesn't work inside closures and generators (which async functions use in their desugaring) This is denied by 1.63 but allowed on 1.64+. label +regression-from-stable-to-stable Here, the parent of the closure is so checking dead code is skipped.
WG-prioritization assigning priority (). label -I-prioritize +P-medium

Related discussion:
text: self.mark_as_used_if_union(*adt, fields); } } <ins> hir::ExprKind::Closure(cls) => { self.insert_def_id(cls.def_id.to_def_id()); } </ins> _ => (), }
Code change:
I tried this code: I expected to see the warning: Instead no warning was reported by the compiler. Observed in nightly, 1.67. Seems like the warning was shown in 1.63 and stopped showing in 1.64.
Bisected to CI has expired so I couldn't automatically bisect further, but looks like a likely candidate
It looks like the issue is that dead code detection doesn't work inside closures and generators (which async functions use in their desugaring) This is denied by 1.63 but allowed on 1.64+. label +regression-from-stable-to-stable Here, the parent of the closure is so checking dead code is skipped.
WG-prioritization assigning priority (). label -I-prioritize +P-medium

Related discussion:
text: <ins> // edition: 2021 #![deny(dead_code)] pub fn foo() { let closure = || { fn a() {}   //~ ERROR function `a` is never used }; closure() } pub async fn async_foo() { const A: usize = 1; //~ ERROR constant `A` is never used } fn main() {} </ins>
Code change:
I tried this code: I expected to see the warning: Instead no warning was reported by the compiler. Observed in nightly, 1.67. Seems like the warning was shown in 1.63 and stopped showing in 1.64.
Bisected to CI has expired so I couldn't automatically bisect further, but looks like a likely candidate
It looks like the issue is that dead code detection doesn't work inside closures and generators (which async functions use in their desugaring) This is denied by 1.63 but allowed on 1.64+. label +regression-from-stable-to-stable Here, the parent of the closure is so checking dead code is skipped.
WG-prioritization assigning priority (). label -I-prioritize +P-medium

Related discussion:
text: <ins> error: function `a` is never used --> $DIR/in-closure.rs:7:12 | LL |         fn a() {} |            ^ | note: the lint level is defined here --> $DIR/in-closure.rs:3:9 | LL | #![deny(dead_code)] |         ^^^^^^^^^ error: constant `A` is never used --> $DIR/in-closure.rs:13:11 | LL |     const A: usize = 1; |           ^ error: aborting due to 2 previous errors </ins>
Code change:
Some regressions of that I previously reported in , but they were missed: I guess the way to fix this is to ignore non-captured lifetimes of opaque types here cc label C-bug regression-from-stable-to-stable T-types T-compiler A-impl-trait
WG-prioritization assigning priority (). label -I-prioritize +P-high

Related discussion:
text: // through and constrain Pi. let mut subcomponents = smallvec![]; let mut subvisited = SsoHashSet::new(); <del> compute_components_recursive(tcx, ty.into(), &mut subcomponents, &mut subvisited); </del> <ins> compute_alias_components_recursive(tcx, ty, &mut subcomponents, &mut subvisited); </ins> out.push(Component::EscapingAlias(subcomponents.into_iter().collect())); } }
Code change:
Some regressions of that I previously reported in , but they were missed: I guess the way to fix this is to ignore non-captured lifetimes of opaque types here cc label C-bug regression-from-stable-to-stable T-types T-compiler A-impl-trait
WG-prioritization assigning priority (). label -I-prioritize +P-high

Related discussion:
text: /// /// This should not be used to get the components of `parent` itself. /// Use [push_outlives_components] instead. <del> pub(super) fn compute_components_recursive<'tcx>( </del> <ins> pub(super) fn compute_alias_components_recursive<'tcx>( tcx: TyCtxt<'tcx>, alias_ty: Ty<'tcx>, out: &mut SmallVec<[Component<'tcx>; 4]>, visited: &mut SsoHashSet<GenericArg<'tcx>>, ) { let ty::Alias(kind, alias_ty) = alias_ty.kind() else { bug!() }; let opt_variances = if *kind == ty::Opaque { tcx.variances_of(alias_ty.def_id) } else { &[] }; for (index, child) in alias_ty.substs.iter().enumerate() { if opt_variances.get(index) == Some(&ty::Bivariant) { continue; } if !visited.insert(child) { continue; } match child.unpack() { GenericArgKind::Type(ty) => { compute_components(tcx, ty, out, visited); } GenericArgKind::Lifetime(lt) => { // Ignore late-bound regions. if !lt.is_late_bound() { out.push(Component::Region(lt)); } } GenericArgKind::Const(_) => { compute_components_recursive(tcx, child, out, visited); } } } } /// Collect [Component]s for *all* the substs of `parent`. /// /// This should not be used to get the components of `parent` itself. /// Use [push_outlives_components] instead. fn compute_components_recursive<'tcx>( </ins> tcx: TyCtxt<'tcx>, parent: GenericArg<'tcx>, out: &mut SmallVec<[Component<'tcx>; 4]>,
Code change:
Some regressions of that I previously reported in , but they were missed: I guess the way to fix this is to ignore non-captured lifetimes of opaque types here cc label C-bug regression-from-stable-to-stable T-types T-compiler A-impl-trait
WG-prioritization assigning priority (). label -I-prioritize +P-high

Related discussion:
text: // the problem is to add `T: 'r`, which isn't true. So, if there are no // inference variables, we use a verify constraint instead of adding // edges, which winds up enforcing the same condition. <ins> let is_opaque = alias_ty.kind(self.tcx) == ty::Opaque; </ins> if approx_env_bounds.is_empty() && trait_bounds.is_empty() <del> && (alias_ty.needs_infer() || alias_ty.kind(self.tcx) == ty::Opaque) </del> <ins> && (alias_ty.needs_infer() || is_opaque) </ins> { debug!("no declared bounds"); <del> self.substs_must_outlive(alias_ty.substs, origin, region); </del> <ins> let opt_variances = is_opaque.then(|| self.tcx.variances_of(alias_ty.def_id)); self.substs_must_outlive(alias_ty.substs, origin, region, opt_variances); </ins> return; }
Code change:
Some regressions of that I previously reported in , but they were missed: I guess the way to fix this is to ignore non-captured lifetimes of opaque types here cc label C-bug regression-from-stable-to-stable T-types T-compiler A-impl-trait
WG-prioritization assigning priority (). label -I-prioritize +P-high

Related discussion:
text: self.delegate.push_verify(origin, GenericKind::Alias(alias_ty), region, verify_bound); } <ins> #[instrument(level = "debug", skip(self))] </ins> fn substs_must_outlive( &mut self, substs: SubstsRef<'tcx>, origin: infer::SubregionOrigin<'tcx>, region: ty::Region<'tcx>, <ins> opt_variances: Option<&[ty::Variance]>, </ins> ) { let constraint = origin.to_constraint_category(); <del> for k in substs { </del> <ins> for (index, k) in substs.iter().enumerate() { </ins> match k.unpack() { GenericArgKind::Lifetime(lt) => { <del> self.delegate.push_sub_region_constraint( origin.clone(), region, lt, constraint, ); </del> <ins> let variance = if let Some(variances) = opt_variances { variances[index] } else { ty::Invariant }; if variance == ty::Invariant { self.delegate.push_sub_region_constraint( origin.clone(), region, lt, constraint, ); } </ins> } GenericArgKind::Type(ty) => { self.type_must_outlive(origin.clone(), ty, region, constraint);
Code change:
Some regressions of that I previously reported in , but they were missed: I guess the way to fix this is to ignore non-captured lifetimes of opaque types here cc label C-bug regression-from-stable-to-stable T-types T-compiler A-impl-trait
WG-prioritization assigning priority (). label -I-prioritize +P-high

Related discussion:
text: <del> use crate::infer::outlives::components::{compute_components_recursive, Component}; </del> <ins> use crate::infer::outlives::components::{compute_alias_components_recursive, Component}; </ins> use crate::infer::outlives::env::RegionBoundPairs; use crate::infer::region_constraints::VerifyIfEq; use crate::infer::VerifyBound;
Code change:
Some regressions of that I previously reported in , but they were missed: I guess the way to fix this is to ignore non-captured lifetimes of opaque types here cc label C-bug regression-from-stable-to-stable T-types T-compiler A-impl-trait
WG-prioritization assigning priority (). label -I-prioritize +P-high

Related discussion:
text: // see the extensive comment in projection_must_outlive let recursive_bound = { let mut components = smallvec![]; <del> compute_components_recursive(self.tcx, alias_ty_as_ty.into(), &mut components, visited); </del> <ins> compute_alias_components_recursive( self.tcx, alias_ty_as_ty.into(), &mut components, visited, ); </ins> self.bound_from_components(&components, visited) };
Code change:
Some regressions of that I previously reported in , but they were missed: I guess the way to fix this is to ignore non-captured lifetimes of opaque types here cc label C-bug regression-from-stable-to-stable T-types T-compiler A-impl-trait
WG-prioritization assigning priority (). label -I-prioritize +P-high

Related discussion:
text: <ins> // check-pass #![feature(type_alias_impl_trait)] struct MyTy<'a>(Vec<u8>, &'a ()); impl MyTy<'_> { fn one(&mut self) -> &mut impl Sized { &mut self.0 } fn two(&mut self) -> &mut (impl Sized + 'static) { self.one() } } type Opaque<'a> = impl Sized; fn define<'a>() -> Opaque<'a> {} fn test<'a>() { None::<&'static Opaque<'a>>; } fn one<'a, 'b: 'b>() -> &'a impl Sized { &() } fn two<'a, 'b>() { one::<'a, 'b>(); } fn main() {} </ins>
Code change:
Some regressions of that I previously reported in , but they were missed: I guess the way to fix this is to ignore non-captured lifetimes of opaque types here cc label C-bug regression-from-stable-to-stable T-types T-compiler A-impl-trait
WG-prioritization assigning priority (). label -I-prioritize +P-high

Related discussion:
text: <ins> // check-pass #![feature(type_alias_impl_trait)] fn opaque<'a: 'a>() -> impl Sized {} fn assert_static<T: 'static>(_: T) {} fn test_closure() { let closure = |_| { assert_static(opaque()); }; closure(&opaque()); } type Opaque<'a> = impl Sized; fn define<'a>() -> Opaque<'a> {} fn test_tait(_: &Opaque<'_>) { None::<&'static Opaque<'_>>; } fn main() {} </ins>
Code change:
The compiler currently allows safe default method implementations to be marked with : which I don't think is allowed in . For reference, is not allowed on trait implementations: From my limited testing, this doesn't seem to be unsound however, as the compiler seems to consider all implementations of as having . cc label T-lang T-compiler C-bug F-targetfeature11 <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
A good resolution to this would be to move it into a separate feature gate I guess?
claim

Related discussion:
text: pub fn check_target_feature_trait_unsafe(tcx: TyCtxt<'_>, id: LocalDefId, attr_span: Span) { if let DefKind::AssocFn = tcx.def_kind(id) { let parent_id = tcx.local_parent(id); <del> if let DefKind::Impl { of_trait: true } = tcx.def_kind(parent_id) { </del> <ins> if let DefKind::Trait | DefKind::Impl { of_trait: true } = tcx.def_kind(parent_id) { </ins> tcx.sess .struct_span_err( attr_span,
Code change:
The compiler currently allows safe default method implementations to be marked with : which I don't think is allowed in . For reference, is not allowed on trait implementations: From my limited testing, this doesn't seem to be unsound however, as the compiler seems to consider all implementations of as having . cc label T-lang T-compiler C-bug F-targetfeature11 <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
A good resolution to this would be to move it into a separate feature gate I guess?
claim

Related discussion:
text: unsafe fn unsf_foo(&self) {} } <ins> trait Qux { #[target_feature(enable = "sse2")] //~^ ERROR cannot be applied to safe trait method fn foo(&self) {} } </ins> fn main() {}
Code change:
The compiler currently allows safe default method implementations to be marked with : which I don't think is allowed in . For reference, is not allowed on trait implementations: From my limited testing, this doesn't seem to be unsound however, as the compiler seems to consider all implementations of as having . cc label T-lang T-compiler C-bug F-targetfeature11 <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
A good resolution to this would be to move it into a separate feature gate I guess?
claim

Related discussion:
text: error: `#[target_feature(..)]` cannot be applied to safe trait method <ins> --> $DIR/trait-impl.rs:22:5 | LL |     #[target_feature(enable = "sse2")] |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot be applied to safe trait method LL | LL |     fn foo(&self) {} |     ------------- not an `unsafe` function error: `#[target_feature(..)]` cannot be applied to safe trait method </ins> --> $DIR/trait-impl.rs:13:5 | LL |     #[target_feature(enable = "sse2")]
Code change:
The compiler currently allows safe default method implementations to be marked with : which I don't think is allowed in . For reference, is not allowed on trait implementations: From my limited testing, this doesn't seem to be unsound however, as the compiler seems to consider all implementations of as having . cc label T-lang T-compiler C-bug F-targetfeature11 <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
A good resolution to this would be to move it into a separate feature gate I guess?
claim

Related discussion:
text: LL |     fn foo(&self) {} |     ------------- not an `unsafe` function <del> error: aborting due to previous error </del> <ins> error: aborting due to 2 previous errors </ins>
Code change:
cc I tried this: I expected to see this happen: The tests pass. Instead, this happened: The tests fail: These tests are pretty complicated but the error message looks correct: I'm not sure why both files are there and particularly why they have different hashes. shows that is being downloaded from CI, and I guess the is coming from somewhere - maybe we should clear the directory before doing that? <!-- 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. --HEAD is <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Ok, it turns out both versions are coming from CI: I am ... surprised this hasn't broken anything else? I don't know why only this specific test would be failing.
The difference between this test and others is that somehow in other tests knows ahead of time which hash it should use: for the allocator tests, it doesn't know, and gives an ambiguity error:
ok, here's a minimal reproducer: I think what's going on is for the working tests, the implicit injected by the compiler also loads libc, because std depends on libc: Then, when the compiler sees , it's already seen the version depends on and resolves the ambiguity by reusing that crate. But for the failing test, we never load std, so we don't have a pre-existing hash to default to, so it gives a hard ambiguity error.

Related discussion:
text: false, ); <del> // HACK: This avoids putting the newly built artifacts in the sysroot if we're using // `download-rustc`, to avoid "multiple candidates for `rmeta`" errors. Technically, that's // not quite right: people can set `download-rustc = true` to download even if there are // changes to the compiler, and in that case ideally we would put the *new* artifacts in the // sysroot, in case there are API changes that should be used by tools.  In practice, // though, that should be very uncommon, and people can still disable download-rustc. if !builder.download_rustc() { let libdir = builder.sysroot_libdir(compiler, target); let hostdir = builder.sysroot_libdir(compiler, compiler.host); add_to_sysroot(&builder, &libdir, &hostdir, &librustc_stamp(builder, compiler, target)); } </del> <ins> let libdir = builder.sysroot_libdir(compiler, target); let hostdir = builder.sysroot_libdir(compiler, compiler.host); add_to_sysroot(&builder, &libdir, &hostdir, &librustc_stamp(builder, compiler, target)); </ins> } }
Code change:
cc I tried this: I expected to see this happen: The tests pass. Instead, this happened: The tests fail: These tests are pretty complicated but the error message looks correct: I'm not sure why both files are there and particularly why they have different hashes. shows that is being downloaded from CI, and I guess the is coming from somewhere - maybe we should clear the directory before doing that? <!-- 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. --HEAD is <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Ok, it turns out both versions are coming from CI: I am ... surprised this hasn't broken anything else? I don't know why only this specific test would be failing.
The difference between this test and others is that somehow in other tests knows ahead of time which hash it should use: for the allocator tests, it doesn't know, and gives an ambiguity error:
ok, here's a minimal reproducer: I think what's going on is for the working tests, the implicit injected by the compiler also loads libc, because std depends on libc: Then, when the compiler sees , it's already seen the version depends on and resolves the ambiguity by reusing that crate. But for the failing test, we never load std, so we don't have a pre-existing hash to default to, so it gives a hard ambiguity error.

Related discussion:
text: use std::borrow::Cow; use std::collections::HashSet; use std::env; <ins> use std::ffi::OsStr; </ins> use std::fs; use std::io::prelude::*; use std::io::BufReader;