jiebi/CodeConvo huggingface dataset:
Change:
I hope this is not already known, but my searching has not turned up anything. Compiling a rust binary with the dependency panices in nightly. How to reproduce: a new rust binary. to dependencies in This gives the following output It compiles on stable and beta. Edit: Just running in gives the same result.
Tried a few different nightlies. And it looks like it broke sometime between and
I have managed to get a much smaller example. Compiling this on nightly gives the above panic:
Looks like it's fixed in the newest nightly ()
Bisecting between ... gives as the regression PR.

Discussion:
<ins> #[derive(PartialEq, Eq)] pub struct Tag(pub Context, pub u16); #[derive(PartialEq, Eq)] pub enum Context { Tiff, Exif, } impl Tag { const ExifIFDPointer: Tag = Tag(Context::Tiff, 34665); } fn main() { match Tag::ExifIFDPointer { //~^ ERROR: non-exhaustive patterns: `Tag(Exif, _)` not covered Tag::ExifIFDPointer => {} } } </ins>

<ins> error[E0004]: non-exhaustive patterns: `Tag(Exif, _)` not covered --> $DIR/issue-50900.rs:15:11 | LL | pub struct Tag(pub Context, pub u16); | ------------------------------------- `Tag` defined here ... LL |     match Tag::ExifIFDPointer { |           ^^^^^^^^^^^^^^^^^^^ pattern `Tag(Exif, _)` not covered | = help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms error: aborting due to previous error For more information about this error, try `rustc --explain E0004`. </ins>
Change:
The error says type parameters when it should say lifetime parameters in this case. This is definitely a low priority issue. Might make a good first issue though?
I propose to work on that one.

Discussion:
hir::ItemFn(.., ref generics, _) => { let mut error = false; if !generics.params.is_empty() { <del> struct_span_err!(tcx.sess, generics.span, E0131, "`main` function is not allowed to have type parameters") .span_label(generics.span, "`main` cannot have type parameters") </del> <ins> let param_type = if generics.is_lt_parameterized() { "lifetime" } else { "type" }; let msg = format!("`main` function is not allowed to have {} parameters", param_type); let label = format!("`main` cannot have {} parameters", param_type); struct_span_err!(tcx.sess, generics.span, E0131, "{}", msg) .span_label(generics.span, label) </ins> .emit(); error = true; }

<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. // error-pattern: `main` function is not allowed to have lifetime parameters fn main<'a>() { } </ins>
Change:
The release notes for 1.26 mention but that is a nightly-only unstable feature. Was that intentional?
cc
Yes this seems unintentional, which is odd since it was marked relnotes and unstable features tend not to get that tag. cc would anyone be able to clarify ?
was initially intended for stable but through testing we ended up realizing it would be a breaking change and is not always desirable. Instead of stabilizing it was landed as a nightly feature, guarded by in the manifest

Discussion:
- [Cargo will now output path to custom commands when `-v` is passed with `--list`][cargo/5041] - [The Cargo binary version is now the same as the Rust version][cargo/5083] <del> - [`Cargo.lock` files are now included in published crates.][cargo/5093] </del> Misc ----

[`String::retain`]: https://doc.rust-lang.org/std/string/struct.String.html#method.retain [cargo/5041]: https://github.com/rust-lang/cargo/pull/5041 [cargo/5083]: https://github.com/rust-lang/cargo/pull/5083 <del> [cargo/5093]: https://github.com/rust-lang/cargo/pull/5093 </del> Version 1.25.0 (2018-03-29)
Change:
Minimal example: The error is technically correct. I specified, that I want a box of F, but I create a closure. Because F is generic, it is caller-chosen and I create a new closure, which has a different type. Still, it took me quite some time to find out what was going on in the more complicated real code. I think that it would help to add a note here explaining, that each closure has a different type, and that the inner closure does not match the type F exactly. Maybe additionally a hint could be , stating to use instead (i.e. the traits F is bound to).
Current output: It doesn't handle the closure case in any special way, and it should.
I’m experiencing the same problem

Discussion:
#traits-as-parameters", ); } <ins> (ty::Param(p), ty::Closure(..) | ty::Generator(..)) => { let generics = self.generics_of(body_owner_def_id); let p_span = self.def_span(generics.type_param(p, self).def_id); if !sp.contains(p_span) { db.span_label(p_span, "this type parameter"); } db.help(&format!( "every closure has a distinct type and so could not always match the  caller-chosen type of parameter `{}`", p )); } </ins> (ty::Param(p), _) | (_, ty::Param(p)) => { let generics = self.generics_of(body_owner_def_id); let p_span = self.def_span(generics.type_param(p, self).def_id);

ty } <del> // Checks that the type of `expr` can be coerced to `expected`. // // N.B., this code relies on `self.diverges` to be accurate. In // particular, assignments to `!` will be permitted if the // diverges flag is currently "always". </del> <ins> /// Checks that the type of `expr` can be coerced to `expected`. /// /// N.B., this code relies on `self.diverges` to be accurate. In particular, assignments to `!` /// will be permitted if the diverges flag is currently "always". </ins> pub fn demand_coerce_diag( &self, expr: &hir::Expr<'_>,

<ins> fn foo<F: FnMut()>() { let _: Box<F> = Box::new(|| ()); //~^ ERROR mismatched types } fn main() {} </ins>

<ins> error[E0308]: mismatched types --> $DIR/issue-51154.rs:2:30 | LL | fn foo<F: FnMut()>() { |        - this type parameter LL |     let _: Box<F> = Box::new(|| ()); |                              ^^^^^ expected type parameter `F`, found closure | = note: expected type parameter `F` found closure `[closure@$DIR/issue-51154.rs:2:30: 2:35]` = help: every closure has a distinct type and so could not always match the caller-chosen type of parameter `F` error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>
Change:
Look at its expected error output is () but under NLL it yields (): The latter is amazingly different from the former.
Hmm. We actually do try to give the nicer errors, but for whatever reason the heuristics we use to decide what is the "main error" to report are failing here. Seems like an interesting case to dig into a bit.
But I'll mark it as a sub-issue of
OK so -- the problem here I think is the TEST. In particular, the line serves no purpose. It does however cause typeck to fail and hence we never get to MIR borrowck. If you remove that line and enable , we get the same error message.

Discussion:
LL |     x.push(y); //~ ERROR explicit lifetime required |            ^ <del> error[E0282]: type annotations needed --> $DIR/ex2a-push-one-existing-name-early-bound.rs:20:9 </del> <ins> error[E0621]: explicit lifetime required in the type of `y` --> $DIR/ex2a-push-one-existing-name-early-bound.rs:17:5 </ins> | <del> LL | let x = baz; |     -   ^^^ cannot infer type for `T` |     | |     consider giving `x` a type </del> <ins> LL | fn baz<'a, 'b, T>(x: &mut Vec<&'a T>, y: &T) |                                          -- help: add explicit lifetime `'a` to the type of `y`: `&'a T` ... LL |     x.push(y); //~ ERROR explicit lifetime required |     ^^^^^^^^^ lifetime `'a` required </ins> error: aborting due to previous error <del> For more information about this error, try `rustc --explain E0282`. </del> <ins> For more information about this error, try `rustc --explain E0621`. </ins>

x.push(y); //~ ERROR explicit lifetime required } fn main() { <del> let x = baz; </del> }
Change:
This compiles successfully with . It's possible that this regressed when the two features were separated. It's also possible that stabilizing never_type first will make this issue moot.
I'm very surprised that this is still open. can you add the I-nomiated flag please, if you think it's appropriate here? modify labels: T-compiler C-Bug
This only seems to occur with nightly features enabled, so I'm not sure it's supposed to be nominated. I'll mention it in the tracking issue though.

Discussion:
PatternKind::Variant { adt_def, substs, variant_index, ref subpatterns } => { let irrefutable = adt_def.variants.iter_enumerated().all(|(i, v)| { i == variant_index || { <del> self.hir.tcx().features().never_type && </del> self.hir.tcx().features().exhaustive_patterns && !v.uninhabited_from(self.hir.tcx(), substs, adt_def.adt_kind()).is_empty() }

<ins> // check-pass #![feature(exhaustive_patterns)] enum Void {} fn main() { let a: Option<Void> = None; let None = a; } </ins>
Change:
A while ago, this would cause an illigal instruction, but has been fixed, see , and no longer is an issue in the current nightly. Except, using such code while creating a constant, results in an ICE: This is rustc 1.28.0-nightly ( 2018-05-30). Backtrace:
I can look into this. I should be able to reference the previous PR to help resolve the issue.
the problem here is quite different. The issue is that the gets turned into a , which then causes to be called (which causes the ICE): and hence the error to never be reached here: Really, it feels like this error is happening at too low a level, and it'd be better to match on the expressions at a higher level to report a similar error, rather than doing the analysis on the MIR.
Still ICE's in both 2015 and 2018 editions.
As of now, this no longer ICE's. Looking on godbolt, since stable 1.33 this code just compiles.
Added a test case:

Discussion:
<ins> // Using labeled break in a while loop has caused an illegal instruction being // generated, and an ICE later. // // See https://github.com/rust-lang/rust/issues/51350 for more information. const CRASH: () = 'a: while break 'a {}; fn main() { println!("{:?}", CRASH); } </ins>
Change:
This may be related/identical to and . The following code fails to compile with a dubious error. This is a simplified reproduction example based on code on IRC. Note that commenting the clause in the definition of makes the code compile.
This code now compiles. It just needs a test to close.

Discussion:
<ins> // Regression test for #51446. // check-pass trait Foo { type Item; fn get(&self) -> Self::Item; } fn blah<T, F>(x: T, f: F) -> B<T::Item, impl Fn(T::Item)> where T: Foo, F: Fn(T::Item), { B { x: x.get(), f } } pub struct B<T, F> where F: Fn(T), { pub x: T, pub f: F, } impl Foo for i32 { type Item = i32; fn get(&self) -> i32 { *self } } fn main() { let _ = blah(0, |_| ()); } </ins>
Change:
In the there is this code fragment: This code isn't correct -- it should be instead. In fact, trying the run the example fails on .

Discussion:
/// reducing the number of actual writes to the file. /// /// ```no_run <del> /// use std::fs::File; </del> <ins> /// use std::fs::{self, File}; </ins> /// use std::io::prelude::*; /// use std::io::LineWriter; ///

///     let file = File::create("poem.txt")?; ///     let mut file = LineWriter::new(file); /// <del> ///     for &byte in road_not_taken.iter() { ///        file.write(&[byte]).unwrap(); ///     } </del> <ins> ///     file.write_all(b"I shall be telling this with a sigh")?; /// ///     // No bytes are written until a newline is encountered (or ///     // the internal buffer is filled). ///     assert_eq!(fs::read_to_string("poem.txt")?, ""); ///     file.write_all(b"n")?; ///     assert_eq!( ///         fs::read_to_string("poem.txt")?, ///         "I shall be telling this with a sighn", ///     ); </ins> /// <del> ///     // let's check we did the right thing. ///     let mut file = File::open("poem.txt")?; ///     let mut contents = String::new(); </del> <ins> ///     // Write the rest of the poem. ///     file.write_all(b"Somewhere ages and ages hence: /// Two roads diverged in a wood, and I - /// I took the one less traveled by, /// And that has made all the difference.")?; </ins> /// <del> ///     file.read_to_string(&mut contents)?; </del> <ins> ///     // The last line of the poem doesn't end in a newline, so ///     // we have to flush or drop the `LineWriter` to finish ///     // writing. ///     file.flush()?; </ins> /// <del> ///     assert_eq!(contents.as_bytes(), &road_not_taken[..]); </del> <ins> ///     // Confirm the whole poem was written. ///     assert_eq!(fs::read("poem.txt")?, &road_not_taken[..]); </ins> ///     Ok(()) /// } /// ```

/// /// The internal buffer is written out before returning the writer. /// <del> // # Errors </del> <ins> /// # Errors </ins> /// /// An `Err` will be returned if an error occurs while flushing the buffer. ///
Change:
There seems to be a malformed URL in the rustup manifest since 1.27 got released today.
Related to ?
This is causing problems on Travis too, see for example
This affects the mozilla overlay for nixpkgs as well, since that uses the same URLs.
Comparison of nightly and stable metadata for rustup: Somehow got replaced by for latest nightly, other things seem fine. Opening in the browser starts downloading of the archive.
Regression caused by .
you were few minutes faster. tool doesn't expect additional argument: Forget about it, old commit
You're looking at an old commit
Oops, commit from 27 Jul 2017. Probably I should've had a bit more sleep :unamused:
Updating with a previous version such as seems to work for me...
Indeed, this breaks every single project having CI against Rust nightly.
For anyone wondering, PR has fixed the bug. It will take until the next scheduled nightly upload until rustup starts working again.
Should rustup tests be as part of the release process?
There is already an open issue about testing rustup.
when is the next scheduled nightly upload?
It should be in progress right now. runs at midnight UTC.
Nightly should release within the next 30 minutes, probably the next 10-15 minutes. Until then, yes, the command won't work.
2018-06-23 is live and the url is fixed
Same issue with current meta for nightly: From
Please reply to the stickied issue , thanks.

Discussion:
let cargo_release = args.next().unwrap(); let rls_release = args.next().unwrap(); let rustfmt_release = args.next().unwrap(); <ins> let _llvm_tools_vers = args.next().unwrap(); // FIXME do something with it? </ins> let s3_address = args.next().unwrap(); let mut passphrase = String::new(); t!(io::stdin().read_to_string(&mut passphrase));
Change:
Current documentation for uses examples with and an . I was just porting over some old code and copied over the examples for testing. However in a codebase this leads to infinite recursion and probably stack exhaustion or other weird behavior depending on the design of the system implementing the panic. I think that the example should be changed from: to something like: Or switching to to handle the case. Not really that big of an issue, but I think any panic handler examples in the documentation should not be able to recursively panic.

Discussion:
/// use std::panic; /// /// panic::set_hook(Box::new(|panic_info| { <del> ///     println!("panic occurred: {:?}", panic_info.payload().downcast_ref::<&str>().unwrap()); </del> <ins> ///     if let Some(s) = panic_info.payload().downcast_ref::<&str>() { ///         println!("panic occurred: {:?}", s); ///     } else { ///         println!("panic occurred"); ///     } </ins> /// })); /// /// panic!("Normal panic");
Change:
Building the crate causes an ICE in beta 1.28. Looking at the backtrace seems like that's caused by the const evaluator. regressed from stable to beta () cc cc
is fixing so not going to bisect this

Discussion:
val: Value, ty: Ty<'tcx>, ) -> &'tcx ty::Const<'tcx> { <del> let layout = ecx.tcx.layout_of(ty::ParamEnv::reveal_all().and(ty)).unwrap(); </del> <ins> let layout = ecx.layout_of(ty).unwrap(); </ins> match (val, &layout.abi) { (Value::Scalar(Scalar::Bits { defined: 0, ..}), _) if layout.is_zst() => {}, (Value::ByRef(..), _) |

<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. // compile-pass pub trait Nullable { const NULL: Self; fn is_null(&self) -> bool; } impl<T> Nullable for *const T { const NULL: Self = 0 as *const T; fn is_null(&self) -> bool { *self == Self::NULL } } fn main() { } </ins>
Change:
Please note the
The literal's span should point inside the parenthesis. Probably needs a change to in .
I'm interested in working on this.
feel free to reach out for any help you might need! I believe that you should verify if changing the span being used in the AST for literals changes the suggestion output. If it doesn't, it means that the problem is not at the parser level, but when lowering to HIR. If that is the case, we need to dig deeper, but I'll be here to help you with that.

Discussion:
"f32" }; match expr.node { <del> hir::ExprLit(_) => {  // numeric literal let snippet = tcx.sess.codemap().span_to_snippet(expr.span) </del> <ins> hir::ExprLit(ref lit) => {  // numeric literal let snippet = tcx.sess.codemap().span_to_snippet(lit.span) </ins> .unwrap_or("<numeric literal>".to_string()); <del> // FIXME: use the literal for missing snippet err.span_suggestion(expr.span, </del> <ins> err.span_suggestion(lit.span, </ins> &format!("you must specify a concrete type for  this numeric value, like `{}`", concrete_type),

<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 a = (1.0).pow(1.0); //~ ERROR can't call method `pow` on ambiguous numeric type } </ins>

<ins> error[E0689]: can't call method `pow` on ambiguous numeric type `{float}` --> $DIR/issue-51874.rs:12:19 | LL |     let a = (1.0).pow(1.0); //~ ERROR can't call method `pow` on ambiguous numeric type |                   ^^^ help: you must specify a concrete type for this numeric value, like `f32` | LL |     let a = (1.0_f32).pow(1.0); //~ ERROR can't call method `pow` on ambiguous numeric type |              ^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0689`. </ins>
Change:
The following code creates a trait (creatively named ) that has an associated type (creatively named ). An default implementation of this trait is given for all types, with . Specializing the trait (for , for example) works, except that doing causes an ICE. () Expected behavior: I believe this code should compile just fine, with 's being equivalent to to 's . Actual behavior: ICE: T/ Rust version: Backtrace:
This looks related to (see in particular ).
Triage: This is no longer ICE with the latest nightly:

Discussion:
<ins> // Test to ensure that trait bounds are propertly // checked on specializable associated types #![allow(incomplete_features)] #![feature(specialization)] trait UncheckedCopy: Sized { type Output: From<Self> + Copy + Into<Self>; } impl<T> UncheckedCopy for T { default type Output = Self; //~^ ERROR: the trait bound `T: Copy` is not satisfied } fn unchecked_copy<T: UncheckedCopy>(other: &T::Output) -> T { (*other).into() } fn bug(origin: String) { // Turn the String into it's Output type... // Which we can just do by `.into()`, the assoc type states `From<Self>`. let origin_output = origin.into(); // Make a copy of String::Output, which is a String... let mut copy: String = unchecked_copy::<String>(&origin_output); // Turn the Output type into a String again, // Which we can just do by `.into()`, the assoc type states `Into<Self>`. let mut origin: String = origin_output.into(); // assert both Strings use the same buffer. assert_eq!(copy.as_ptr(), origin.as_ptr()); // Any use of the copy we made becomes invalid, drop(origin); // OH NO! UB UB UB UB! copy.push_str(" world!"); println!("{}", copy); } fn main() { bug(String::from("hello")); } </ins>

<ins> error[E0277]: the trait bound `T: Copy` is not satisfied --> $DIR/issue-33017.rs:12:5 | LL |     type Output: From<Self> + Copy + Into<Self>; |                               ---- required by this bound in `UncheckedCopy::Output` ... LL |     default type Output = Self; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `Copy` is not implemented for `T` | help: consider restricting type parameter `T` | LL | impl<T: std::marker::Copy> UncheckedCopy for T { |       ^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>

<ins> #![allow(incomplete_features)] #![feature(const_generics)] #![feature(const_evaluatable_checked)] #![feature(specialization)] pub trait Trait { type Type; } impl<T: ?Sized> Trait for T { default type Type = [u8; 1]; } impl<T: Trait> Trait for *const T { type Type = [u8; std::mem::size_of::<<T as Trait>::Type>()]; //~^ ERROR: unconstrained generic constant } fn main() {} </ins>

<ins> error: unconstrained generic constant --> $DIR/issue-51892.rs:15:5 | LL |     type Type = [u8; std::mem::size_of::<<T as Trait>::Type>()]; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: try adding a `where` bound using this expression: `where [(); std::mem::size_of::<<T as Trait>::Type>()]:` error: aborting due to previous error </ins>