jiebi/CodeConvo huggingface dataset:
Code change:
I was in the middle of bisecting on system llvm and running when I noticed that, in fact, while each step was rebuilding the compiler with the changed llvm correctly, the test that was being run was never recompiled, such that the same one was always running, and my bisect was guided by wrong results. STR: Run once Touch anything that is part of e.g. , e.g. Run again Expected result: Both and the test are rebuilt, and the rebuilt test executed. Actual result: is rebuilt, the test is not, and the test built before the codegen changes is executed.

Related discussion:
text: deps.push((path_to_add.into(), false)); } <del> // Now we want to update the contents of the stamp file, if necessary. First // we read off the previous contents along with its mtime. If our new // contents (the list of files to copy) is different or if any dep's mtime // is newer then we rewrite the stamp file. </del> deps.sort(); <del> let stamp_contents = fs::read(stamp); let stamp_mtime = mtime(&stamp); </del> let mut new_contents = Vec::new(); <del> let mut max = None; let mut max_path = None; </del> for (dep, proc_macro) in deps.iter() { <del> let mtime = mtime(dep); if Some(mtime) > max { max = Some(mtime); max_path = Some(dep.clone()); } </del> new_contents.extend(if *proc_macro { b"h" } else { b"t" }); new_contents.extend(dep.to_str().unwrap().as_bytes()); new_contents.extend(b"0"); } <del> let max = max.unwrap(); let max_path = max_path.unwrap(); let contents_equal = stamp_contents .map(|contents| contents == new_contents) .unwrap_or_default(); if contents_equal && max <= stamp_mtime { builder.verbose(&format!("not updating {:?}; contents equal and {:?} <= {:?}", stamp, max, stamp_mtime)); return deps.into_iter().map(|(d, _)| d).collect() } if max > stamp_mtime { builder.verbose(&format!("updating {:?} as {:?} changed", stamp, max_path)); } else { builder.verbose(&format!("updating {:?} as deps changed", stamp)); } </del> t!(fs::write(&stamp, &new_contents)); deps.into_iter().map(|(d, _)| d).collect() }
Code change:
Playing with the nighly's existential types, I stumbled upon a compiler stack overflow: Error message:
A better example might be this: removing the from the existential type decleration just compiles fine
Can you try running the compiler inside gdb and produce a backtrace?
<details<summaryBacktrace:</summary</details
It's recursing in Ideally this should cause cycle errors. But I'm assuming Manually computes this without a query. Maybe we should just make a query? This would solve both the FIXME and this issue.
Both examples now produce a cycle error. So we just need to add the two examples to (if there aren't already tests for these situations)

Related discussion:
text: <ins> #![feature(existential_type)] existential type Foo: Fn() -> Foo; //~^ ERROR: cycle detected when processing `Foo` fn crash(x: Foo) -> Foo { x } fn main() { } </ins>
Code change:
Playing with the nighly's existential types, I stumbled upon a compiler stack overflow: Error message:
A better example might be this: removing the from the existential type decleration just compiles fine
Can you try running the compiler inside gdb and produce a backtrace?
<details<summaryBacktrace:</summary</details
It's recursing in Ideally this should cause cycle errors. But I'm assuming Manually computes this without a query. Maybe we should just make a query? This would solve both the FIXME and this issue.
Both examples now produce a cycle error. So we just need to add the two examples to (if there aren't already tests for these situations)

Related discussion:
text: <ins> error[E0391]: cycle detected when processing `Foo` --> $DIR/existential-types-with-cycle-error.rs:3:1 | LL | existential type Foo: Fn() -> Foo; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | note: ...which requires processing `crash`... --> $DIR/existential-types-with-cycle-error.rs:6:25 | LL |   fn crash(x: Foo) -> Foo { |  _________________________^ LL | |     x LL | | } | |_^ = note: ...which again requires processing `Foo`, completing the cycle note: cycle used when collecting item types in top-level module --> $DIR/existential-types-with-cycle-error.rs:1:1 | LL | / #![feature(existential_type)] LL | | LL | | existential type Foo: Fn() -> Foo; LL | | ...  | LL | | LL | | } | |_^ error: aborting due to previous error For more information about this error, try `rustc --explain E0391`. </ins>
Code change:
Playing with the nighly's existential types, I stumbled upon a compiler stack overflow: Error message:
A better example might be this: removing the from the existential type decleration just compiles fine
Can you try running the compiler inside gdb and produce a backtrace?
<details<summaryBacktrace:</summary</details
It's recursing in Ideally this should cause cycle errors. But I'm assuming Manually computes this without a query. Maybe we should just make a query? This would solve both the FIXME and this issue.
Both examples now produce a cycle error. So we just need to add the two examples to (if there aren't already tests for these situations)

Related discussion:
text: <ins> #![feature(existential_type)] pub trait Bar<T> { type Item; } existential type Foo: Bar<Foo, Item = Foo>; //~^ ERROR: cycle detected when processing `Foo` fn crash(x: Foo) -> Foo { x } fn main() { } </ins>
Code change:
Playing with the nighly's existential types, I stumbled upon a compiler stack overflow: Error message:
A better example might be this: removing the from the existential type decleration just compiles fine
Can you try running the compiler inside gdb and produce a backtrace?
<details<summaryBacktrace:</summary</details
It's recursing in Ideally this should cause cycle errors. But I'm assuming Manually computes this without a query. Maybe we should just make a query? This would solve both the FIXME and this issue.
Both examples now produce a cycle error. So we just need to add the two examples to (if there aren't already tests for these situations)

Related discussion:
text: <ins> error[E0391]: cycle detected when processing `Foo` --> $DIR/existential-types-with-cycle-error2.rs:7:1 | LL | existential type Foo: Bar<Foo, Item = Foo>; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | note: ...which requires processing `crash`... --> $DIR/existential-types-with-cycle-error2.rs:10:25 | LL |   fn crash(x: Foo) -> Foo { |  _________________________^ LL | |     x LL | | } | |_^ = note: ...which again requires processing `Foo`, completing the cycle note: cycle used when collecting item types in top-level module --> $DIR/existential-types-with-cycle-error2.rs:1:1 | LL | / #![feature(existential_type)] LL | | LL | | pub trait Bar<T> { LL | |     type Item; ...  | LL | | LL | | } | |_^ error: aborting due to previous error For more information about this error, try `rustc --explain E0391`. </ins>
Code change:
These are the most common tools for concurrency in Rust. They should always be at hand.
Also
If we add we should also add and .
Agreed
Fixed by brson's commit.

Related discussion:
text: pub use vec::{ImmutableEqVector, ImmutableCopyableVector}; pub use vec::{OwnedVector, OwnedCopyableVector}; <ins> /* Reexported runtime types */ pub use comm::{stream, Port, Chan, GenericChan, GenericSmartChan, GenericPort, Peekable}; pub use task::spawn; </ins> /* Reexported modules */ pub use at_vec;
Code change:
As of we'll be updating to a version of the RLS which depends on racer which depends on . Unfortunately we're bringing in two different versions of , 209 and 211, right now. These should be deduplicated as they take a good deal of time to build on CI, and then we should also add a check which ensures that there's only one version of in our workspace. cc
I've sent a PR to update racer as part of
This is fixed by

Related discussion:
text: // versions of them accidentally sneak into our dependency graph to // ensure we keep our CI times under control // "cargo", // FIXME(#53005) <del> // "rustc-ap-syntax", // FIXME(#53006) </del> <ins> "rustc-ap-syntax", </ins> ]; let mut name_to_id = HashMap::new(); for node in resolve.nodes.iter() {
Code change:
(edit: much simpler reproducer at second post) (see edit history for the initial issue text) Potential duplicate of and cc
(edit: updated to nightly from 2018-08-14, as the error message changed) Another simpler reproducer: Backtrace: The backtrace looks quite different though, so I guess a fix for this one should also be checked to fix the first example.
Latest nightly appears to have fixed the ICE, however it's still making unbounded recursion :)
Async-await traige: Marking as blocking pending investigation to understand what is happening.
Alright, so here's what I've worked out so far: I was able to reproduce the ICE from the original code snippet using the compiler version and library versions from when the issue was reported ( was the closest version I could find and I had to use patch to make Cargo download versions of libraries that worked). I was then able to confirm that the reproduction supplied in the next comment also triggered the ICE. I was then able to get rid of the external dependencies (mostly by copying in parts of that version of futures) and still get the ICE - . After that, I upgraded to as mentioned in the next comment and confirmed that the ICE had been fixed and the unbounded recursion was happening with that same test case. Then, I took that test case that was confirmed to have the problem and tried to run it on the latest nightly - I had to make some minor adjustments as the pin module had changed since August, but I couldn't get the recursion error to happen. I'm inclined to say that this has been fixed at some point - .
I've submitted with a regression test for this issue. if you are able to reproduce this failure on a more recent nightly then feel free to re-open or file a new issue.
Sounds good to me, thanks!

Related discussion:
text: <ins> // compile-pass // edition:2018 #![feature(arbitrary_self_types, async_await, await_macro)] use std::task::{self, Poll}; use std::future::Future; use std::marker::Unpin; use std::pin::Pin; // This is a regression test for a ICE/unbounded recursion issue relating to async-await. #[derive(Debug)] #[must_use = "futures do nothing unless polled"] pub struct Lazy<F> { f: Option<F> } impl<F> Unpin for Lazy<F> {} pub fn lazy<F, R>(f: F) -> Lazy<F> where F: FnOnce(&mut task::Context) -> R, { Lazy { f: Some(f) } } impl<R, F> Future for Lazy<F> where F: FnOnce(&mut task::Context) -> R, { type Output = R; fn poll(mut self: Pin<&mut Self>, cx: &mut task::Context) -> Poll<R> { Poll::Ready((self.f.take().unwrap())(cx)) } } async fn __receive<WantFn, Fut>(want: WantFn) -> () where Fut: Future<Output = ()>, WantFn: Fn(&Box<Send + 'static>) -> Fut, { await!(lazy(|_| ())); } pub fn basic_spawn_receive() { async { await!(__receive(|_| async { () })) }; } fn main() {} </ins>
Code change:
The following code: Produces the following error message: This error message tells you that the types are mismatched, but doesn't fully explain why. To fix it, you need to use a floating point literal instead of an integer literal. This isn't clear from the error message. If you're new to programming or if you come from a language that doesn't draw the same distinction between integer and floating point literals, it may not be clear why the literal is not the same as . It would be great if we could add something in our error message that would suggest one or more of the valid ways to fix this: - - type could be in another context

Related discussion:
text: use std::fmt; use rustc_target::spec::abi; use syntax::ast; <del> use errors::DiagnosticBuilder; </del> <ins> use errors::{Applicability, DiagnosticBuilder}; </ins> use syntax_pos::Span; use hir;
Code change:
The following code: Produces the following error message: This error message tells you that the types are mismatched, but doesn't fully explain why. To fix it, you need to use a floating point literal instead of an integer literal. This isn't clear from the error message. If you're new to programming or if you come from a language that doesn't draw the same distinction between integer and floating point literals, it may not be clear why the literal is not the same as . It would be great if we could add something in our error message that would suggest one or more of the valid ways to fix this: - - type could be in another context

Related discussion:
text: db.note("no two closures, even if identical, have the same type"); db.help("consider boxing your closure and/or using it as a trait object"); } <ins> match (&values.found.sty, &values.expected.sty) { // Issue #53280 (ty::TyInfer(ty::IntVar(_)), ty::TyFloat(_)) => { if let Ok(snippet) = self.sess.codemap().span_to_snippet(sp) { if snippet.chars().all(|c| c.is_digit(10) || c == '-' || c == '_') { db.span_suggestion_with_applicability( sp, "use a float literal", format!("{}.0", snippet), Applicability::MachineApplicable ); } } }, _ => {} } </ins> }, OldStyleLUB(err) => { db.note("this was previously accepted by the compiler but has been phased out");
Code change:
The following code: Produces the following error message: This error message tells you that the types are mismatched, but doesn't fully explain why. To fix it, you need to use a floating point literal instead of an integer literal. This isn't clear from the error message. If you're new to programming or if you come from a language that doesn't draw the same distinction between integer and floating point literals, it may not be clear why the literal is not the same as . It would be great if we could add something in our error message that would suggest one or more of the valid ways to fix this: - - type could be in another context

Related discussion:
text: --> $DIR/catch-block-type-error.rs:18:9 | LL |         42 <del> |         ^^ expected f32, found integral variable </del> <ins> |         ^^ |         | |         expected f32, found integral variable |         help: use a float literal: `42.0` </ins> | = note: expected type `f32` found type `{integer}`
Code change:
The following code: Produces the following error message: This error message tells you that the types are mismatched, but doesn't fully explain why. To fix it, you need to use a floating point literal instead of an integer literal. This isn't clear from the error message. If you're new to programming or if you come from a language that doesn't draw the same distinction between integer and floating point literals, it may not be clear why the literal is not the same as . It would be great if we could add something in our error message that would suggest one or more of the valid ways to fix this: - - type could be in another context

Related discussion:
text: <ins> // Copyright 2018 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { let sixteen: f32 = 16; //~^ ERROR mismatched types //~| HELP use a float literal let a_million_and_seventy: f64 = 1_000_070; //~^ ERROR mismatched types //~| HELP use a float literal let negative_nine: f32 = -9; //~^ ERROR mismatched types //~| HELP use a float literal // only base-10 literals get the suggestion let sixteen_again: f64 = 0x10; //~^ ERROR mismatched types let and_once_more: f32 = 0o20; //~^ ERROR mismatched types } </ins>
Code change:
The following code: Produces the following error message: This error message tells you that the types are mismatched, but doesn't fully explain why. To fix it, you need to use a floating point literal instead of an integer literal. This isn't clear from the error message. If you're new to programming or if you come from a language that doesn't draw the same distinction between integer and floating point literals, it may not be clear why the literal is not the same as . It would be great if we could add something in our error message that would suggest one or more of the valid ways to fix this: - - type could be in another context

Related discussion:
text: <ins> error[E0308]: mismatched types --> $DIR/issue-53280-expected-float-found-integer-literal.rs:12:24 | LL |     let sixteen: f32 = 16; |                        ^^ |                        | |                        expected f32, found integral variable |                        help: use a float literal: `16.0` | = note: expected type `f32` found type `{integer}` error[E0308]: mismatched types --> $DIR/issue-53280-expected-float-found-integer-literal.rs:15:38 | LL |     let a_million_and_seventy: f64 = 1_000_070; |                                      ^^^^^^^^^ |                                      | |                                      expected f64, found integral variable |                                      help: use a float literal: `1_000_070.0` | = note: expected type `f64` found type `{integer}` error[E0308]: mismatched types --> $DIR/issue-53280-expected-float-found-integer-literal.rs:18:30 | LL |     let negative_nine: f32 = -9; |                              ^^ |                              | |                              expected f32, found integral variable |                              help: use a float literal: `-9.0` | = note: expected type `f32` found type `{integer}` error[E0308]: mismatched types --> $DIR/issue-53280-expected-float-found-integer-literal.rs:25:30 | LL |     let sixteen_again: f64 = 0x10; |                              ^^^^ expected f64, found integral variable | = note: expected type `f64` found type `{integer}` error[E0308]: mismatched types --> $DIR/issue-53280-expected-float-found-integer-literal.rs:27:30 | LL |     let and_once_more: f32 = 0o20; |                              ^^^^ expected f32, found integral variable | = note: expected type `f32` found type `{integer}` error: aborting due to 5 previous errors For more information about this error, try `rustc --explain E0308`. </ins>
Code change:
We should only pass stage0 in general, should be sufficient for all use cases. cc for awareness and in case there's any concerns

Related discussion:
text: let mut cmd = Command::new(rustc); cmd.args(&args) <del> .arg("--cfg") .arg(format!("stage{}", stage)) </del> .env(bootstrap::util::dylib_path_var(), env::join_paths(&dylib_path).unwrap()); let mut maybe_crate = None; <ins> // Non-zero stages must all be treated uniformly to avoid problems when attempting to uplift // compiler libraries and such from stage 1 to 2. if stage == "0" { cmd.arg("--cfg").arg("bootstrap"); } </ins> // Print backtrace in case of ICE if env::var("RUSTC_BACKTRACE_ON_ICE").is_ok() && env::var("RUST_BACKTRACE").is_err() { cmd.env("RUST_BACKTRACE", "1");
Code change:
We should only pass stage0 in general, should be sufficient for all use cases. cc for awareness and in case there's any concerns

Related discussion:
text: if !up_to_date(src_file, dst_file) { let mut cmd = Command::new(&builder.initial_rustc); builder.run(cmd.env("RUSTC_BOOTSTRAP", "1") <del> .arg("--cfg").arg("stage0") </del> <ins> .arg("--cfg").arg("bootstrap") </ins> .arg("--target").arg(target) .arg("--emit=obj") .arg("-o").arg(dst_file)
Code change:
We should only pass stage0 in general, should be sufficient for all use cases. cc for awareness and in case there's any concerns

Related discussion:
text: /// Returns the result of an unchecked addition, resulting in /// undefined behavior when `x + y > T::max_value()` or `x + y < T::min_value()`. <del> #[cfg(not(stage0))] </del> <ins> #[cfg(not(bootstrap))] </ins> pub fn unchecked_add<T>(x: T, y: T) -> T; /// Returns the result of an unchecked substraction, resulting in /// undefined behavior when `x - y > T::max_value()` or `x - y < T::min_value()`. <del> #[cfg(not(stage0))] </del> <ins> #[cfg(not(bootstrap))] </ins> pub fn unchecked_sub<T>(x: T, y: T) -> T; /// Returns the result of an unchecked multiplication, resulting in /// undefined behavior when `x * y > T::max_value()` or `x * y < T::min_value()`. <del> #[cfg(not(stage0))] </del> <ins> #[cfg(not(bootstrap))] </ins> pub fn unchecked_mul<T>(x: T, y: T) -> T; /// Performs rotate left.
Code change:
We should only pass stage0 in general, should be sufficient for all use cases. cc for awareness and in case there's any concerns

Related discussion:
text: #[derive(Copy, Clone, Eq, PartialEq, Ord, PartialOrd, Hash)] #[repr(transparent)] #[rustc_layout_scalar_valid_range_start(1)] <del> #[cfg_attr(not(stage0), rustc_nonnull_optimization_guaranteed)] </del> <ins> #[cfg_attr(not(bootstrap), rustc_nonnull_optimization_guaranteed)] </ins> pub struct $Ty($Int); }
Code change:
We should only pass stage0 in general, should be sufficient for all use cases. cc for awareness and in case there's any concerns

Related discussion:
text: #[stable(feature = "nonnull", since = "1.25.0")] #[repr(transparent)] #[rustc_layout_scalar_valid_range_start(1)] <del> #[cfg_attr(not(stage0), rustc_nonnull_optimization_guaranteed)] </del> <ins> #[cfg_attr(not(bootstrap), rustc_nonnull_optimization_guaranteed)] </ins> pub struct NonNull<T: ?Sized> { pointer: *const T, }
Code change:
Let's say you have the following (simplified) code: () This results in the following error: The suggested fix will work, but already copies the data so the extra is wasteful. The error message should instead suggest . This is an error you can run into if was previously of type and you changed it to a slice after writing the rest of the code.
Note: this kind of improvement applies to too: Err:

Related discussion:
text: if receiver.ends_with(&method_call) { None  // do not suggest code that is already there (#53348) } else { <del> Some(format!("{}{}", receiver, method_call)) </del> <ins> /* methods defined in `method_call_list` will overwrite `.clone()` in copy of `receiver` */ let method_call_list = [".to_vec()", ".to_string()"]; if receiver.ends_with(".clone()") && method_call_list.contains(&method_call.as_str()){ // created copy of `receiver` because we don't want other // suggestion to get affected let mut new_receiver = receiver.clone(); let max_len = new_receiver.rfind(".").unwrap(); new_receiver.truncate(max_len); Some(format!("{}{}", new_receiver, method_call)) } else { Some(format!("{}{}", receiver, method_call)) } </ins> } }) .collect::<Vec<_>>(); if !suggestions.is_empty() {
Code change:
Let's say you have the following (simplified) code: () This results in the following error: The suggested fix will work, but already copies the data so the extra is wasteful. The error message should instead suggest . This is an error you can run into if was previously of type and you changed it to a slice after writing the rest of the code.
Note: this kind of improvement applies to too: Err:

Related discussion:
text: <ins> // Copyright 2018 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { let items = vec![1, 2, 3]; let ref_items: &[i32] = &items; let items_clone: Vec<i32> = ref_items.clone(); // in that case no suggestion will be triggered let items_clone_2:Vec<i32> = items.clone(); let s = "hi"; let string: String = s.clone(); // in that case no suggestion will be triggered let s2 = "hi"; let string_2: String = s2.to_string(); } </ins>