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. -- <!-- 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
further minimized: Looks like the generator code incorrectly handles somewhere :thinking:
PR is up. I noticed that an old stable rustc doesn't ICE, so marking as such and nominating the PR for beta backport.

Discussion:
debug!("{}.super_relate_consts(a = {:?}, b = {:?})", relation.tag(), a, b); let tcx = relation.tcx(); <del> let eagerly_eval = |x: &'tcx ty::Const<'tcx>| { // FIXME(eddyb) this doesn't account for lifetime inference variables // being erased by `eval`, *nor* for the polymorphic aspect of `eval`. // That is, we could always use `eval` and it will just return the // old value back if it doesn't succeed. if !x.val.needs_infer() { return x.eval(tcx, relation.param_env()).val; } x.val }; </del> <ins> let eagerly_eval = |x: &'tcx ty::Const<'tcx>| x.eval(tcx, relation.param_env()).val; </ins> // FIXME(eddyb) doesn't look like everything below checks that `a.ty == b.ty`. // We could probably always assert it early, as `const` generic parameters

<ins> // check-pass // edition:2018 #[allow(unused)] async fn foo<'a>() { let _data = &mut [0u8; { 1 + 4 }]; bar().await } async fn bar() {} 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
could you share your code that caused the issue or a list of steps to reproduce the crash?
I try, but it may take some time.
this issue should no longer happen, could you verify it?

Discussion:
saved_locals: &GeneratorSavedLocals, ) { let did = body.source.def_id(); <del> let allowed_upvars = tcx.erase_regions(upvars); </del> <ins> let param_env = tcx.param_env(did); let allowed_upvars = tcx.normalize_erasing_regions(param_env, upvars); </ins> let allowed = match witness.kind() { <del> &ty::GeneratorWitness(s) => tcx.erase_late_bound_regions(s), </del> <ins> &ty::GeneratorWitness(interior_tys) => { tcx.normalize_erasing_late_bound_regions(param_env, interior_tys) } </ins> _ => { tcx.sess.delay_span_bug( body.span,

} }; <del> let param_env = tcx.param_env(did); </del> for (local, decl) in body.local_decls.iter_enumerated() { // Ignore locals which are internal or not saved between yields. if !saved_locals.contains(local) || decl.internal {

<ins> // edition:2018 // run-pass #![allow(incomplete_features)] #![feature(generic_const_exprs)] #![allow(unused)] fn main() { let x = test(); } fn concat<const A: usize, const B: usize>(a: [f32; A], b: [f32; B]) -> [f32; A + B] { todo!() } async fn reverse<const A: usize>(x: [f32; A]) -> [f32; A] { todo!() } async fn test() { let a = [0.0]; let b = [1.0, 2.0]; let ab = concat(a,b); let ba = reverse(ab).await; println!("{:?}", ba); } </ins>
Change:
The test is failing on AArch64. We should avoid having x8664-specific registers in that test. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc this is one of the tests that are failing on AArch64.
cc
I think it's just a matter of marking the test as
claim

Discussion:
// pretty-mode:expanded // pp-exact:asm.pp <ins> // only-x86_64 </ins> pub fn main() { let a: i32;
Change:
In the documentation for [][1], you will find the following: The link on this page is not actually a link to the trait, but a link to the method on the same page. The link is written as [] with an []: PartialEq::eq in the same doc-comment, so I am unsure whether this should be considered an issue in the documentation, or in rustdoc. [1]: [2]: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

Discussion:
/// /// This trait allows for partial equality, for types that do not have a full /// equivalence relation. For example, in floating point numbers `NaN != NaN`, <del> /// so floating point types implement `PartialEq` but not [`Eq`]. </del> <ins> /// so floating point types implement `PartialEq` but not [`Eq`](Eq). </ins> /// /// Formally, the equality must be (for all `a`, `b` and `c`): ///

/// assert_eq!(x.eq(&y), false); /// ``` /// <del> /// [`Eq`]: Eq </del> /// [`eq`]: PartialEq::eq /// [`ne`]: PartialEq::ne #[lang = "eq"]
Change:
as a minimal example. Unclear whether this is a new trait impl or some regression elsewhere.
has been in 1.45 which would explain this:
There were roughly ~15-20 crates that failed in the crater run due to this, mostly in tests. I'm not sure whether we think that's sufficient reasoning to drop the impl, I get that it can be useful... cc (and relabeling as this is not an inference regression)
Can we add to the types? That would provide a path to patch the regression. Being able to easily compare a socketaddr to a string seems pretty valuable for testing, I'd rather see we make it easier than require the turbofish. for the PR that these impls
I’m not in favor since this would blur the difference between "this string does not parse as a valid socket address" v.s. "it does, but one not equal to that one". Code that doesn’t care about that difference can already use and compare strings.
mostly cared about PartialOrd and Ord impls (as you can tell from the PR title). Unlike PartialEq, none existed before on SocketAddr so they won't be problematic. I think the PR included new PartialEq impls only in support of heterogeneous PartialOrd (see ) which was ultimately removed from the PR anyway. I opened to revert the new PartialEq impls, leaving the PartialOrd and Ord impls from .

Discussion:
&& self.inner.sin6_scope_id == other.inner.sin6_scope_id } } <del> #[stable(feature = "socketaddr_ordering", since = "1.45.0")] impl PartialEq<SocketAddrV4> for SocketAddr { fn eq(&self, other: &SocketAddrV4) -> bool { match self { SocketAddr::V4(v4) => v4 == other, SocketAddr::V6(_) => false, } } } #[stable(feature = "socketaddr_ordering", since = "1.45.0")] impl PartialEq<SocketAddrV6> for SocketAddr { fn eq(&self, other: &SocketAddrV6) -> bool { match self { SocketAddr::V4(_) => false, SocketAddr::V6(v6) => v6 == other, } } } #[stable(feature = "socketaddr_ordering", since = "1.45.0")] impl PartialEq<SocketAddr> for SocketAddrV4 { fn eq(&self, other: &SocketAddr) -> bool { match other { SocketAddr::V4(v4) => self == v4, SocketAddr::V6(_) => false, } } } #[stable(feature = "socketaddr_ordering", since = "1.45.0")] impl PartialEq<SocketAddr> for SocketAddrV6 { fn eq(&self, other: &SocketAddr) -> bool { match other { SocketAddr::V4(_) => false, SocketAddr::V6(v6) => self == v6, } } } </del> #[stable(feature = "rust1", since = "1.0.0")] impl Eq for SocketAddrV4 {} #[stable(feature = "rust1", since = "1.0.0")]

// equality assert_eq!(v4_1, v4_1); assert_eq!(v6_1, v6_1); <del> assert_eq!(v4_1, SocketAddr::V4(v4_1)); assert_eq!(v6_1, SocketAddr::V6(v6_1)); </del> assert_eq!(SocketAddr::V4(v4_1), SocketAddr::V4(v4_1)); assert_eq!(SocketAddr::V6(v6_1), SocketAddr::V6(v6_1)); <del> assert!(v4_1 != SocketAddr::V6(v6_1)); assert!(v6_1 != SocketAddr::V4(v4_1)); </del> assert!(v4_1 != v4_2); assert!(v6_1 != v6_2);

assert!(v6_1 < v6_3); assert!(v4_3 > v4_1); assert!(v6_3 > v6_1); <ins> // compare with an inferred right-hand side assert_eq!(v4_1, "224.120.45.1:23456".parse().unwrap()); assert_eq!(v6_1, "[2001:db8:f00::1002]:23456".parse().unwrap()); assert_eq!(SocketAddr::V4(v4_1), "224.120.45.1:23456".parse().unwrap()); </ins> } }
Change:
fails currently due to However, the toolstate is green nevertheless. Looks like somehow toolstate tracking is broken. Due to this, we currently ship a broken Miri via rustup. Cc
I can't make heads or tails of the log in It looks to me like tests weren't run at all?
Yeah that's expected, the dist builders only build the tools and do not test them. The tools builder tests them. Manifest creation (when the final toolchain is to rustup, as part of auto -master promotion) reads the toolstate JSON files and omits Miri if its tests failed. (So far, no other tool opted into using that system, as far as I know.)
But for some reason, the tools builder doesn't even seem to build Miri?!?
It runs the miri tests and shows that they fail. The toolstate processing after that is just not verbose enough to tell us what's up
It says But that did not even get to Miri. It stopped after another test failure: I think that's a clippy test. So what likely happened is that a clippy test failed, but for some reason, instead of aborting CI, that lead to all tools being marked as test-pass...
That line says ? And above some tests fail, but those are not Miri's tests.
Oh... right... maybe clippy tests failing cause all other tools not to get tested at all, thus leading to "successful" test results
And, notably, clippy tests failing do not block the PR from landing!
oh... right :facepalm: so... let's do this PR and figure out things in another try? rollup-
You did this in an issue, not sure what that is going to accomplish. :D
oops. I thought we were on the PR

Discussion:
builder.add_rustc_lib_path(compiler, &mut cargo); <del> builder.run(&mut cargo.into()); </del> <ins> // FIXME: Disable clippy tests for now, they're failing on master // (generally this would mean a toolstate failure but we don't have // toolstate for clippy anymore). // builder.run(&mut cargo.into()); </ins> } }

/// `rust.save-toolstates` in `config.toml`. If unspecified, nothing will be /// done. The file is updated immediately after this function completes. pub fn save_toolstate(&self, tool: &str, state: ToolState) { <ins> // If we're in a dry run setting we don't want to save toolstates as // that means if we e.g. panic down the line it'll look like we tested // everything (but we actually haven't). if self.config.dry_run { return; } // Toolstate isn't tracked for clippy, but since most tools do, we avoid // checking in all the places we could save toolstate and just do so // here. if tool == "clippy-driver" { return; } </ins> if let Some(ref path) = self.config.save_toolstates { if let Some(parent) = path.parent() { // Ensure the parent directory always exists

src/doc/rust-by-example  src/doc/embedded-book  src/doc/edition-guide  <del> src/tools/clippy  </del> src/tools/rls  src/tools/rustfmt  src/tools/miri  set -e <ins> # debugging: print out the saved toolstates cat /tmp/toolstate/toolstates.json </ins> python3 "$X_PY" test check-tools <ins> python3 "$X_PY" test src/tools/clippy </ins>
Change:
I would expect the following command to run the libcore doc tests: This used to work, but now all it does it build libcore and its test binaries. No tests are actually being run (which I verified by breaking one of them deliberately). any idea what is happening?
I can confirm, doctests are not being run for std. I think a bigger question is, have they ever worked? Cargo will skip doctests whenever is used, which AFAIK is how std is always built/tested.
I am pretty sure that have used this command before and got test failures when I had screwed up. If you want, I can go back to older versions and verify.
I'll try to figure out what's going on. I tried running with and fortunately nothing looks broken. It's also very possible I am missing something, but I edited some doctests with errors, and a bare doesn't fail.
This was wrong, see below. I'll try to put together a fix.
Ouch. Is there a way we can ensure this does not happen again in the future? Looks like our test suite needs a test suite...
It's pretty hard :/ I guess we can add a dummy doc test that writes some "well known" file and we can assert that the file is present -- perhaps do this per-crate.
OK, it wasn't as bad as I originally reported. This regressed via which is only in 1.45 (beta). I have a fix started at This will require various steps: cargo. to beta. cargo on beta. for new beta release. bootstrap on nightly.
Well, but it does mean that currently on CI we do not run doctests, right? does not change this.
Right, I just mean it hasn't been that long (only about a week).

Discussion:
/// # Examples /// /// ``` <ins> /// #![feature(inner_deref)] </ins> /// let x: Result<String, u32> = Ok("hello".to_string()); /// let y: Result<&str, &u32> = Ok("hello"); /// assert_eq!(x.as_deref(), y);

/// # Examples /// /// ``` <ins> /// #![feature(inner_deref)] /// let mut s = "HELLO".to_string(); </ins> /// let mut x: Result<String, u32> = Ok("hello".to_string()); <del> /// let y: Result<&mut str, &mut u32> = Ok("HELLO"); </del> <ins> /// let y: Result<&mut str, &mut u32> = Ok(&mut s); </ins> /// assert_eq!(x.as_deref_mut().map(|x| { x.make_ascii_uppercase(); x }), y); /// <ins> /// let mut i = 42; </ins> /// let mut x: Result<String, u32> = Err(42); <del> /// let y: Result<&mut str, &mut u32> = Err(&42); </del> <ins> /// let y: Result<&mut str, &mut u32> = Err(&mut i); </ins> /// assert_eq!(x.as_deref_mut().map(|x| { x.make_ascii_uppercase(); x }), y); /// ``` pub fn as_deref_mut(&mut self) -> Result<&mut T::Target, &mut E> {

# source tarball for a stable release you'll likely see `1.x.0` for rustc and # `0.(x+1).0` for Cargo where they were released on `date`. <del> date: 2020-06-03 </del> <ins> date: 2020-06-16 </ins> rustc: beta cargo: beta
Change:
The manual version: The manual version ASM: The derived version: The derived version ASM: The diff is that while the manual version does: derived version does: All the other operators are optimized properly.
LLVM can't properly optimize the match against Some(Less Some(Greater) and negate the result, LLVM does find a way to optimize the code, because the IR we generate is somewhat simpler having to handle only one of the Some() cases. I didn't really look into how to maybe teach LLVM to handle this case, and didn't see anything obvious in the way we generate IR that could be improved here either. Should I prepare a PR to adjust the default impl of with a comment that explains why it's written that way, or should we investigate more here?
I wonder if this issue is related to
We could test it in next nightly.
Well, this issue doesn't fixed by it (which is expected because we changed MIR of && and , not match) so we need to make changes in LLVM or change our generated code.
Created PR with fix.
Upstream fix for LLVM:

Discussion:
#[must_use] #[stable(feature = "rust1", since = "1.0.0")] fn le(&self, other: &Rhs) -> bool { <del> matches!(self.partial_cmp(other), Some(Less | Equal)) </del> <ins> // Pattern `Some(Less | Eq)` optimizes worse than negating `None | Some(Greater)`. !matches!(self.partial_cmp(other), None | Some(Greater)) </ins> } /// This method tests greater than (for `self` and `other`) and is used by the `>` operator.

<ins> // This test checks that comparison operation // generated by #[derive(PartialOrd)] // doesn't contain jumps for C enums // compile-flags: -Copt-level=3 #![crate_type="lib"] #[repr(u32)] #[derive(Copy, Clone, Eq, PartialEq, PartialOrd)] pub enum Foo { Zero, One, Two, } #[no_mangle] pub fn compare_less(a: Foo, b: Foo)->bool{ // CHECK-NOT: br {{.*}} a < b } #[no_mangle] pub fn compare_le(a: Foo, b: Foo)->bool{ // CHECK-NOT: br {{.*}} a <= b } #[no_mangle] pub fn compare_ge(a: Foo, b: Foo)->bool{ // CHECK-NOT: br {{.*}} a >= b } #[no_mangle] pub fn compare_greater(a: Foo, b: Foo)->bool{ // CHECK-NOT: br {{.*}} a > b } </ins>
Change:
between and linking behavior changes which broke my cross compilation from linux to macos. It now adds the which is unknown by my compiler. leaving it out would probably fix the error. Below are detailed informations about my project and the cross compilation setup in order to reproduce. We for the veloren project we have a CI docker container. i tried to update the toolchain. with docker the error is reproduceable quite easy, however if you are familar with docker you can skip some steps in order to save you a hour of compilation I expected to see this happen: we successfully build the osxcross enviorment with the first docker container, based on this: the code compiles for macos after compilation it starts linking using the '/dockercache/osxcross/target/bin/x86_64-apple-darwin17-clang' linker we build in osxcross the linking suceeds Instead, this happened: the linking fails as it tries to use a flag which isn't supported. Interestingly when you search in the rust code for this flag, you'll find a refactor about a month ago changing behavior here: however i personally dont know how that caused the change. :
This is a regression from
Looks like the condition was lost, and clang for macos is apparently not "linkerisgnu".
I'll fix this today.
Assigning .
Fixed in
awesome, i will confirm it, once it's in a good nightly build :)
Just wanted to confirm that with this error no longer occurs, so it is fixed now, thank you!

Discussion:
fn set_output_kind(&mut self, output_kind: LinkOutputKind, out_filename: &Path) { match output_kind { LinkOutputKind::DynamicNoPicExe => { <del> if !self.is_ld { </del> <ins> if !self.is_ld && self.sess.target.target.options.linker_is_gnu { </ins> self.cmd.arg("-no-pie"); } }

LinkOutputKind::StaticNoPicExe => { // `-static` works for both gcc wrapper and ld. self.cmd.arg("-static"); <del> if !self.is_ld { </del> <ins> if !self.is_ld && self.sess.target.target.options.linker_is_gnu { </ins> self.cmd.arg("-no-pie"); } }
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. --Requirement: Create an empty file called '', i.e. using <!-- 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
Hmm, we should only disallow (since that's what we use for non-real "files") although I guess or even just might be a valid path itself? Internally we can tell apart between the two, I'm guessing this is to avoid tools seeing something with or in it and misinterpreting it as not a real file? But in that case we'd want a real error not an assert. cc
Marked as p-medium based on the discussion on the
PR with fix:

Discussion:
impl From<PathBuf> for FileName { fn from(p: PathBuf) -> Self { <del> assert!(!p.to_string_lossy().ends_with('>')); </del> FileName::Real(RealFileName::LocalPath(p)) } }

<ins> # ignore-cross-compile we need to execute the binary # ignore-windows we create files with < and > in their names include ../tools.mk ifdef RUSTC_BLESS_TEST RUSTC_TEST_OP = cp else RUSTC_TEST_OP = $(DIFF) endif all: echo '"comes from a file with a name that begins with <"' > "$(TMPDIR)/<leading-lt" echo '"comes from a file with a name that ends with >"' > "$(TMPDIR)/trailing-gt>" cp silly-file-names.rs "$(TMPDIR)/silly-file-names.rs" $(RUSTC) "$(TMPDIR)/silly-file-names.rs" -o "$(TMPDIR)/silly-file-names" "$(TMPDIR)/silly-file-names" > "$(TMPDIR)/silly-file-names.run.stdout" $(RUSTC_TEST_OP) "$(TMPDIR)/silly-file-names.run.stdout" silly-file-names.run.stdout </ins>

<ins> fn main() { println!(include!("<leading-lt")); println!(include!("trailing-gt>")); } </ins>

<ins> comes from a file with a name that begins with < comes from a file with a name that ends with > </ins>
Change:
we currently output The suggestion is incomplete and will not result in compilable code. Because the lifetime is coming from an argument of type , which is an unconstrained type parameter, itself will not have the needed lifetime and causes the obligation that we're trying to reverse by suggesting . The appropriate changes to the code would be either or , depending on whether appears in any other argument or not.
The suggested code .

Discussion:
const ENTRY_LIMIT: usize = 900; // FIXME: The following limits should be reduced eventually. <del> const ISSUES_ENTRY_LIMIT: usize = 1854; </del> <ins> const ISSUES_ENTRY_LIMIT: usize = 1852; </ins> const ROOT_ENTRY_LIMIT: usize = 867; const EXPECTED_TEST_FILE_EXTENSIONS: &[&str] = &[

<del> use std::any::Any; fn foo<T: Any>(value: &T) -> Box<dyn Any> { Box::new(value) as Box<dyn Any> //~^ ERROR lifetime may not live long enough } fn main() { let _ = foo(&5); } </del>

<del> error: lifetime may not live long enough --> $DIR/issue-16922.rs:4:5 | LL | fn foo<T: Any>(value: &T) -> Box<dyn Any> { |                       - let's call the lifetime of this reference `'1` LL |     Box::new(value) as Box<dyn Any> |     ^^^^^^^^^^^^^^^ cast requires that `'1` must outlive `'static` | help: to declare that the trait object captures data from argument `value`, you can add an explicit `'_` lifetime bound | LL | fn foo<T: Any>(value: &T) -> Box<dyn Any + '_> { |                                          ++++ error: aborting due to previous error </del>

<ins> // run-rustfix use std::any::Any; fn foo<T: Any>(value: &T) -> Box<dyn Any + '_> { Box::new(value) as Box<dyn Any> //~^ ERROR lifetime may not live long enough } fn main() { let _ = foo(&5); } </ins>

<ins> // run-rustfix use std::any::Any; fn foo<T: Any>(value: &T) -> Box<dyn Any> { Box::new(value) as Box<dyn Any> //~^ ERROR lifetime may not live long enough } fn main() { let _ = foo(&5); } </ins>

<ins> error: lifetime may not live long enough --> $DIR/suggest-using-tick-underscore-lifetime-in-return-trait-object.rs:5:5 | LL | fn foo<T: Any>(value: &T) -> Box<dyn Any> { |                       - let's call the lifetime of this reference `'1` LL |     Box::new(value) as Box<dyn Any> |     ^^^^^^^^^^^^^^^ cast requires that `'1` must outlive `'static` | help: to declare that the trait object captures data from argument `value`, you can add an explicit `'_` lifetime bound | LL | fn foo<T: Any>(value: &T) -> Box<dyn Any + '_> { |                                          ++++ error: aborting due to previous error </ins>