jiebi/CodeConvo huggingface dataset:
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. --Run It works if the order of and is swapped. (e.i., ) <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: The backtrace points to in cc label +requires-nightly <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Sorry about that. Will fix it. claim

Discussion:
let expected_values = check_cfg .expecteds .entry(ident.name.to_string()) <ins> .and_modify(|expected_values| match expected_values { ExpectedValues::Some(_) => {} ExpectedValues::Any => { // handle the case where names(...) was done // before values by changing to a list *expected_values = ExpectedValues::Some(FxHashSet::default()); } }) </ins> .or_insert_with(|| { ExpectedValues::Some(FxHashSet::default()) }); let ExpectedValues::Some(expected_values) = expected_values else { <del> bug!("shoudn't be possible") </del> <ins> bug!("`expected_values` should be a list a values") </ins> }; for val in values {

<ins> warning: unexpected `cfg` condition value --> $DIR/order-independant.rs:8:7 | LL | #[cfg(a)] |       ^- help: specify a config value: `= "b"` | = note: expected values for `a` are: `b` = note: `#[warn(unexpected_cfgs)]` on by default warning: unexpected `cfg` condition value --> $DIR/order-independant.rs:12:7 | LL | #[cfg(a = "unk")] |       ^^^^^^^^^ | = note: expected values for `a` are: `b` warning: 2 warnings emitted </ins>

<ins> // check-pass // revisions: names_before names_after // compile-flags: -Z unstable-options // compile-flags: --check-cfg=names(names_before,names_after) // [names_before]compile-flags: --check-cfg=names(a) --check-cfg=values(a,"b") // [names_after]compile-flags: --check-cfg=values(a,"b") --check-cfg=names(a) #[cfg(a)] //~^ WARNING unexpected `cfg` condition value fn my_cfg() {} #[cfg(a = "unk")] //~^ WARNING unexpected `cfg` condition value fn my_cfg() {} fn main() {} </ins>
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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Another regression of cc
Before I create a fix: is an expected/reasonable value in this ? I.e. is the right fix here just to allow ?
I don't think so. Actually just looked, think it's because we're not erasing properly. Let me put up a quick fix.

Discussion:
ty::ReErased => { flags = flags | TypeFlags::HAS_RE_ERASED; } <del> ty::ReError(_) => {} </del> <ins> ty::ReError(_) => { flags = flags | TypeFlags::HAS_FREE_REGIONS; } </ins> } debug!("type_flags({:?}) = {:?}", self, flags);

<ins> // compile-flags: -Zdrop-tracking-mir // edition:2021 use std::future::Future; trait Client { type Connecting<'a>: Future + Send where Self: 'a; fn connect(&'_ self) -> Self::Connecting<'a>; //~^ ERROR use of undeclared lifetime name `'a` } fn call_connect<C>(c: &'_ C) -> impl '_ + Future + Send where C: Client + Send + Sync, { async move { c.connect().await } //~^ ERROR `C` does not live long enough } fn main() {} </ins>

<ins> error[E0261]: use of undeclared lifetime name `'a` --> $DIR/erase-error-in-mir-drop-tracking.rs:11:46 | LL |     fn connect(&'_ self) -> Self::Connecting<'a>; |                                              ^^ undeclared lifetime | help: consider introducing lifetime `'a` here | LL |     fn connect<'a>(&'_ self) -> Self::Connecting<'a>; |               ++++ help: consider introducing lifetime `'a` here | LL | trait Client<'a> { |             ++++ error: `C` does not live long enough --> $DIR/erase-error-in-mir-drop-tracking.rs:19:5 | LL |     async move { c.connect().await } |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0261`. </ins>
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: explanation suggestion compiles: Instead, this happened: explanation Suggestion does not compile: ` <!-- 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. --:

Discussion:
if let Some(&(_, res)) = rib.bindings.get(&normalized_ident) { self.record_lifetime_res(lifetime.id, res, LifetimeElisionCandidate::Named); <del> if let LifetimeRes::Param { param, .. } = res { </del> <ins> if let LifetimeRes::Param { param, binder } = res { </ins> match self.lifetime_uses.entry(param) { Entry::Vacant(v) => { debug!("First use of {:?} at {:?}", res, ident.span);

LifetimeRibKind::Item | LifetimeRibKind::AnonymousReportError | LifetimeRibKind::ElisionFailure => Some(LifetimeUseSet::Many), <del> // An anonymous lifetime is legal here, go ahead. LifetimeRibKind::AnonymousCreateParameter { .. } => { Some(LifetimeUseSet::One { use_span: ident.span, use_ctxt }) } </del> <ins> // An anonymous lifetime is legal here, and bound to the right // place, go ahead. LifetimeRibKind::AnonymousCreateParameter { binder: anon_binder, .. } => Some(if binder == anon_binder { LifetimeUseSet::One { use_span: ident.span, use_ctxt } } else { LifetimeUseSet::Many }), </ins> // Only report if eliding the lifetime would have the same // semantics. LifetimeRibKind::Elided(r) => Some(if res == r {

#![feature(inherent_associated_types)] #![allow(incomplete_features)] <ins> #![deny(single_use_lifetimes)] </ins> struct Foo<T>(T);
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. --Hey! I was trying to make it work somehow with , when the function depends on the other generic parameters. I came to this approach and encountered an ICE. <!-- 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<strongOutput</strong</summary<p</p</details
label requires-nightly F-typealiasimpl_trait
Regression in nightly-2023-02-22 Regression in cc
still crashing, rustc 1.77.0-nightly ( 2024-01-08)

Discussion:
debug!(?cache_projection, ?obligation_projection); match infcx.at(cause, param_env).eq( <del> DefineOpaqueTypes::No, </del> <ins> DefineOpaqueTypes::Yes, </ins> cache_projection, obligation_projection, ) {

<ins> // check-pass // revisions: new old //[new] compile-flags: -Znext-solver //! This test checks that we can successfully infer //! the hidden type of `FooImpl` to be `Foo<i32, {closure}>` //! and `ImplT` to be `i32`. This test used to fail, because //! we were unable to make the connection that the closure //! argument is the same as the first argument of `Foo`. #![feature(type_alias_impl_trait)] use std::fmt::Debug; use std::marker::PhantomData; struct Foo<T: Debug, F: FnOnce(T)> { f: F, _phantom: PhantomData<T>, } type ImplT = impl Debug; type FooImpl = Foo<ImplT, impl FnOnce(ImplT)>; fn bar() -> FooImpl { Foo::<i32, _> { f: |_| (), _phantom: PhantomData } } fn main() {} </ins>
Change:
I'm having trouble building rust on master lately. Here's the entire error: I tracked it down to this pull request: Commenting out the attribute makes rust compile successfully for me. I am on OSX 10.8.4, x86_64
told me on IRC that I should ping you on this.
I find it very odd that commenting out an attribute would fix this. I've seen this problem before, but it's totally unrelated to finalizers in . I have seen this in the past trip up because we're adding files to archives that aren't object files, but I've also heard that this was all previously fixed... I wish I could research more into this, but I can't reproduce this at all on any machine I have.
Yes, it does seem pretty inexplicable, but I thought you might have a clue. I am content with the commenting out the attribute for the time being, so I can at least track master. But I could try to debug this myself if I knew where to start..
Editing title to reflect the real problem here as found out by
Also, hints that uninstalling the system LLVM is a workaround for this.
Seems to be non-trivial to remove LLVM on OSX, after having installed it. I tried moving all llvm-related libs I could fine out of my , but that didn't seem to make a difference.
We may be able to just not run on OSX because it appeared to bootstrap just fine. I think maybe the linkers on linux may need this, but perhaps the ones on OSX are more controlled such that we may not need it. I haven't investigated it much, but it's one possible solution for this.
I'm having this issue as well. I'm not sure I want to try to uninstall my system LLVM, given that it's very likely to break Xcode.
Any idea how I can try disabling the "ar s" execution? I can't seem to find it. It's very hard to grep for. :P
+1, I'm also having this problem (and can't build on OSX 10.9 because of it)
Just wanted to point out that this is still failing with the same error on my machine, which I assume is because the stage0 snapshot is from 3 days before this commit went in. I'll check back when this makes it into the stage0 snapshot.
Yep, still fails to compile on OSX 10.9 with LLVM 3.3 installed. How often are snapshots updated?
A new snapshot is scheduled in (currently third in the queue).
This error was resolved for me with the new snapshot .
This is resolved for me as well.

Discussion:
fs::unlink(&bc); } <del> // Now that we've added files, some platforms need us to now update // the symbol table in the archive (because some platforms die when // adding files to the archive without symbols). a.update_symbols(); </del> <ins> // After adding all files to the archive, we need to update the // symbol table of the archive. This currently dies on OSX (see // #11162), and isn't necessary there anyway match sess.targ_cfg.os { abi::OsMacos => {} _ => { a.update_symbols(); } } </ins> } None => {}
Change:
Introduced by . This is because we now use to build but it defaults to soft float for all arm which is wrong for gnueabihf/eabihf. This is fixed in upstream llvm to choose the right float abi based on the target. This will no longer be an issue once we update llvm.

Discussion:
[submodule "src/llvm"] path = src/llvm <del> url = https://github.com/alexcrichton/llvm.git </del> <ins> url = https://github.com/luqmana/llvm.git </ins> branch = master [submodule "src/libuv"] path = src/libuv

<del> Subproject commit eac6ff795c40778683e42b0c6ab6f6adaceb391d </del> <ins> Subproject commit 8841dcef357e051c34a46030db7c7b1a83f9b1d8 </ins>

TargetOptions Options; Options.NoFramePointerElim = true; Options.EnableSegmentedStacks = EnableSegmentedStacks; <del> Options.FloatABIType = (Trip.getEnvironment() == Triple::GNUEABIHF) ? FloatABI::Hard : FloatABI::Default; </del> <ins> Options.FloatABIType = FloatABI::Default; </ins> Options.UseSoftFloat = UseSoftFloat; if (UseSoftFloat) { Options.FloatABIType = FloatABI::Soft;

# If this file is modified, then llvm will be forcibly cleaned and then rebuilt. # The actual contents of this file do not matter, but to trigger a change on the # build bots then the contents should be changed so git updates the mtime. <del> 2013-12-18 </del> <ins> 2013-12-29 </ins>
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, due to installing from source: with the installation commands: ./configure --prefix=/path/to/installation/using/a/non/root/user/rust-1.69.0 --enable-extended python3 build python3 install I expected to see the installation succeed. Instead, the installation failed when processing the cargo installation. Only the cargo installation uses the function, so the problem appears isolated to that single function call, due to the implementation of . <!-- 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<summaryBacktrace</summary<p</p</details
Seems related to
Thank you for pointing-out ! It is the same problem. Closing this as a duplicate.
It is not an issue, but this PR will fix this issue. Reopening to keep track of progress.
Does the PR fix the issue?
When is combined with , the rustc release is able to compile and install successfully (from linked at ) as shown below:

Discussion:
tarball.add_file(&cargo, "bin", 0o755); tarball.add_file(etc.join("_cargo"), "share/zsh/site-functions", 0o644); <del> tarball.add_renamed_file(etc.join("cargo.bashcomp.sh"), "etc/bash_completion.d", "cargo"); </del> <ins> tarball.add_renamed_file( etc.join("cargo.bashcomp.sh"), "src/etc/bash_completion.d", "cargo", ); </ins> tarball.add_dir(etc.join("man"), "share/man/man1"); tarball.add_legal_and_readme_to("share/doc/cargo");
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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailsAdding an suffix fixes the issue: The error first appears with the toolchain. It works fine with .
The offset intrinsic does not support doing this, it requires isize or usize. ICEs using intrinsics wrongly are expected and not a bug. Thanks for the report anyways.
Shouldn't a occur for the argument?
There is nothing to be coerced to, since the intrinsics accept any type on the type level.
Is this specific to the intrinsic? I tried a couple of other intrinsics, and the compiler complained about mismatched types: : : Doing the same for results in an ICE, e.g.:
the intrinsic is generic, that's why it passes type checking
It's only generic in the first parameter. And has the exact same signature, but the issue doesn't occur for it.
Hi what is the motivation to keep this check as an ICE instead of a user friendly error since the error arises from misusage of the API?
Giving better errors for intrinsics and other internal-only features increases maintenance burden, so decided to not support it. Invalid usage of intrinsics may lead to ICEs (since intrinsics should not be used - I see for your case here it makes sense to use them in the tests, but I think you can live with ICEs). I guess it's not ideal that the ICE message says to report it - but fixing that is hard.

Discussion:
<del> //@ known-bug: #101962 #![feature(core_intrinsics)] pub fn wrapping<T: Copy>(a: T, b: T) { let _z = core::intrinsics::wrapping_mul(a, b); } fn main() { wrapping(1,2); } </del>

<del> //@ known-bug: #111699 //@ edition:2021 //@ compile-flags: -Copt-level=0 #![feature(core_intrinsics)] use std::intrinsics::offset; fn main() { let a = [1u8, 2, 3]; let ptr: *const u8 = a.as_ptr(); unsafe { assert_eq!(*offset(ptr, 0), 1); } } </del>

<del> //@ known-bug: #97501 #![feature(core_intrinsics)] use std::intrinsics::wrapping_add; #[derive(Clone, Copy)] struct WrapInt8 { value: u8 } impl std::ops::Add for WrapInt8 { type Output = WrapInt8; fn add(self, other: WrapInt8) -> WrapInt8 { wrapping_add(self, other) } } fn main() { let p = WrapInt8 { value: 123 }; let q = WrapInt8 { value: 234 }; println!("{}", (p + q).value); } </del>
Change:
: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Note that this doesn't seem to be rustc's fault: , so an LLVM issue would probably also be good. Interestingly, it compiles just fine on aarch64, and it also compiles on x86 when you change the third argument of the LLVM intrinsic from 0 (icache) to 1 (dcache).
I've submitted it to LLVM. Much nicer now that they use GitHub instead of bugzilla.
assign Assigning it for closing the issue on the next LLVM upgrade that includes the patch.
Seems similar to which also causes llvm errors by default.

Discussion:
[submodule "src/llvm-project"] path = src/llvm-project url = https://github.com/rust-lang/llvm-project.git <del> branch = rustc/16.0-2023-04-05 </del> <ins> branch = rustc/16.0-2023-06-05 </ins> [submodule "src/doc/embedded-book"] path = src/doc/embedded-book url = https://github.com/rust-embedded/book.git

<del> Subproject commit 533d3f338b804d54e5d0ac4fba6276af23002d9c </del> <ins> Subproject commit 22897bce7bfedc9cd3953a33419b346936263500 </ins>
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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
label +F-arbitraryselftypes

Discussion:
self_ty, method_self_ty, self.span, pick ); let cause = self.cause( <del> self.span, </del> <ins> self.self_expr.span, </ins> ObligationCauseCode::UnifyReceiver(Box::new(UnifyReceiverContext { assoc_item: pick.item, param_env: self.param_env,

Ok(InferOk { obligations, value: () }) => { self.register_predicates(obligations); } <del> Err(_) => { span_bug!( self.span, "{} was a subtype of {} but now is not?", self_ty, method_self_ty ); </del> <ins> Err(terr) => { // FIXME(arbitrary_self_types): We probably should limit the // situations where this can occur by adding additional restrictions // to the feature, like the self type can't reference method substs. if self.tcx.features().arbitrary_self_types { self.err_ctxt() .report_mismatched_types(&cause, method_self_ty, self_ty, terr) .emit(); } else { span_bug!( self.span, "{} was a subtype of {} but now is not?", self_ty, method_self_ty ); } </ins> } } }

<ins> #![feature(arbitrary_self_types)] use std::ops::Deref; struct Foo(u32); impl Foo { fn get<R: Deref<Target=Self>>(self: R) -> u32 { self.0 } } fn main() { let mut foo = Foo(1); foo.get::<&Foo>(); //~^ ERROR mismatched types } </ins>

<ins> error[E0308]: mismatched types --> $DIR/arbitrary-self-from-method-substs.rs:14:5 | LL |     foo.get::<&Foo>(); |     ^^^ expected `&Foo`, found `Foo` error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>
Change:
The following code: used to incorrectly compile but now correctly errors, we should add a test to ensure this doesn't regress. cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

Discussion:
<ins> trait Trait {} impl Trait for () {} fn foo<T: Trait, U: Trait>() -> impl Trait { //~^ WARN function cannot return without recursing [unconditional_recursion] let a: T = foo::<T, U>(); //~^ ERROR concrete type differs from previous defining opaque type use loop {} let _: T = foo::<U, T>(); } fn main() {} </ins>

<ins> warning: function cannot return without recursing --> $DIR/multiple-defining-usages-in-body.rs:4:1 | LL | fn foo<T: Trait, U: Trait>() -> impl Trait { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot return without recursing LL | LL |     let a: T = foo::<T, U>(); |                ------------- recursive call site | = help: a `loop` may express intention better if this is on purpose = note: `#[warn(unconditional_recursion)]` on by default error: concrete type differs from previous defining opaque type use --> $DIR/multiple-defining-usages-in-body.rs:6:16 | LL |     let a: T = foo::<T, U>(); |                ^^^^^^^^^^^^^ expected `U`, got `T` | note: previous use here --> $DIR/multiple-defining-usages-in-body.rs:9:16 | LL |     let _: T = foo::<U, T>(); |                ^^^^^^^^^^^^^ error: aborting due to previous error; 1 warning emitted </ins>
Change:
currently says: "users" is so ambiguous as to be meaningless. What I originally intended was something like "people building from source once and installing it locally", like Gentoo users or something. I think "dist" is a much better name for this profile: it makes it more clear why CI uses the profile and it hopefully will make it easier for distros to find and understand. cc - you said in https://rust- this would be helpful, do you still think that? The only other name I can think of is something like but I'm not sure that's a good description of what CI is doing with the profile. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Mentoring instructions: I want to do this in a backwards compatible way, so that old config files keep working seamlessly. To do this you'll need to add a way to add aliases to profiles. Take a look around and change it to treat the same as . Then rename the relevant places around Please add a test in once you're done.
can i work on this
you should talk to - they have open but it's broken, I'm not sure of the status.
oh okay
claim
this wasn't done properly
Hi! Are you planning to continue working on this issue?

Discussion:
Codegen, Library, Tools, <del> User, </del> <ins> Dist, </ins> None, }

pub fn all() -> impl Iterator<Item = Self> { use Profile::*; // N.B. these are ordered by how they are displayed, not alphabetically <del> [Library, Compiler, Codegen, Tools, User, None].iter().copied() </del> <ins> [Library, Compiler, Codegen, Tools, Dist, None].iter().copied() </ins> } pub fn purpose(&self) -> String {

Compiler => "Contribute to the compiler itself", Codegen => "Contribute to the compiler, and also modify LLVM or codegen", Tools => "Contribute to tools which depend on the compiler, but do not modify it directly (e.g. rustdoc, clippy, miri)", <del> User => "Install Rust from source", </del> <ins> Dist => "Install Rust from source", </ins> None => "Do not modify `config.toml`" } .to_string()

Profile::Codegen => "codegen", Profile::Library => "library", Profile::Tools => "tools", <del> Profile::User => "user", </del> <ins> Profile::Dist => "dist", </ins> Profile::None => "none", } }

"lib" | "library" => Ok(Profile::Library), "compiler" => Ok(Profile::Compiler), "llvm" | "codegen" => Ok(Profile::Codegen), <del> "maintainer" | "user" => Ok(Profile::User), </del> <ins> "maintainer" | "dist" => Ok(Profile::Dist), </ins> "tools" | "tool" | "rustdoc" | "clippy" | "miri" | "rustfmt" | "rls" => { Ok(Profile::Tools) }

"test src/tools/rustfmt", ], Profile::Library => &["check", "build", "test library/std", "doc"], <del> Profile::User => &["dist", "build"], </del> <ins> Profile::Dist => &["dist", "build"], </ins> }; println!();

println!("- `x.py {}`", cmd); } <del> if profile != Profile::User { </del> <ins> if profile != Profile::Dist { </ins> println!( "For more suggestions, see https://rustc-dev-guide.rust-lang.org/building/suggested.html" );