jiebi/CodeConvo huggingface dataset:
Change:
EDITED: MCVE is here: I tried to compile the following, which caused the rust compiler to panic. The following compiles just fine: The error message: And running again with verbosity and backtrace: Running nixos 17.09 using rust nightly installed using the mozilla nixpkgs overlay. It's about a month out of date, so I'll check the updates.
This still crashes as of the most recent nightly. Self-contained repro: Mentioning who this assertion in .
That was confusing at first, heh - the multi-line message which doesn't split custom messages on their own line doesn't help at all (can we split it off?). So what's happening is the length expression is using a generic parameter in its outer scope. This hasn't ever been supported, but it's extremely obnoxious to prevent - we could ban in but that already works in some specific situations, so it'd be backwards-incompatible. This problem would get properly fixed once we actually start supporting generics-in-scope for array expressions, and that can't happen without lazy normalization (cc
I'm having the same problem still. succeeds in making the compiler cry about the function call in the array size, but with the compiler panics. Here's my :
exampe ICEs at , cc
Issue is still present on current stable and nightly. Just wanted to add that it only occurs when using a lifetime parameter. example ICEs whereas the following with removed lifetime parameter works fine.
Triage: This is no longer ICE with the latest nightly:

Discussion:
<ins> struct ArpIPv4<'a> { s: &'a u8 } impl<'a> ArpIPv4<'a> { const LENGTH: usize = 20; pub fn to_buffer() -> [u8; Self::LENGTH] { //~^ ERROR: generic `Self` types are currently not permitted in anonymous constants unimplemented!() } } fn main() {} </ins>

<ins> error: generic `Self` types are currently not permitted in anonymous constants --> $DIR/issue-47814.rs:8:32 | LL |     pub fn to_buffer() -> [u8; Self::LENGTH] { |                                ^^^^ | note: not a concrete type --> $DIR/issue-47814.rs:5:10 | LL | impl<'a> ArpIPv4<'a> { |          ^^^^^^^^^^^ error: aborting due to previous error </ins>
Change:
I've noticed that the nightly compilers lately have taken quite a long time to compile . The crate is a large amount of code generated by . I've narrowed down the difference in build time to a nightly release. The results below are from debug builds, but I've seen similar numbers for release builds. rustc 1.25.0-nightly ( 2018-01-26): rustc 1.25.0-nightly ( 2018-01-27): I'm not really sure how to profile this further, so I'll take any suggestion you have.
Looks like the only PRs in that range are , , , and . None of which seem immediately relevant. I also can't reproduce locally... Are you sure these results are caused by some external process? What platform are you running on?
I've been able to reliably reproduce this behavior on my desktop. I tried re-running the test on my laptop and saw similar results. Both my laptop and desktop are using NixOS 17.09.2964. (Hummingbird) with . The test results with the full invocations are below. The borrow checking stands out though... vs. I'm going to go ahead and test this again inside of a fedora container to try to narrow down if this is specific to NixOS. <details
I think I've heard reports elsewhere of similar slowdowns, but I can't seem to find anything right now. I tested on a Ubuntu 17.10 machine, so it's possible nix is somehow at fault here...
Can you try testing with nightly-2018-01-28 (actually )? That's the version where I start to see the failure.
Yes, I can now reproduce. Based on a quick inspection with gdp, I suspect is at fault -- I'm seeing CPU time mostly spent in memmove... called from . I suspect the problem is the String allocations here:
cc
After testing in the Fedora container, I'm seeing similar performance so I think it's safe to rule out NixOS's packaging as a factor. Since the time to borrow check seems to be the issue, is the only change that seems relevant. <details
it seems to me like those could be instead...
Yep, I have a patch locally that seems to solve the problem by removing the allocation.

Discussion:
return 1; } <ins> let src = local_begin.fm.external_src.borrow(); </ins> // We need to extend the snippet to the end of the src rather than to end_index so when // searching forwards for boundaries we've got somewhere to search. let snippet = if let Some(ref src) = local_begin.fm.src { let len = src.len(); <del> (&src[start_index..len]).to_string() } else if let Some(src) = local_begin.fm.external_src.borrow().get_source() { </del> <ins> (&src[start_index..len]) } else if let Some(src) = src.get_source() { </ins> let len = src.len(); <del> (&src[start_index..len]).to_string() </del> <ins> (&src[start_index..len]) </ins> } else { return 1; };
Change:
This is in regards to this example in the documentation: Clicking 'Run' on brings you to the rust playground, where it fails to compile. It is missing the function Link to playground: %5D%0Afn%20main()%20%7B%0Ause%20std%3A%3Affi%3A%3ACString%3B%0Ause%20std%3A%3Aos%3A%3Araw%3A%3Acchar%3B%0A%0Aextern%20%7B%0A%20%20%20%20fn%20myprinter(s%3A%20*const%20cchar)()%0Alet%20ctoprint%20%3D%20CString%3A%3Anew(%22Hello%2C%20world!%22).unwrap()%3B%0Aunsafe%20%7B%0A%20%20%20%20myprinter(ctoprint.as_ptr())%3B%0A%7D%0A%7D%0A)
I am not sure why this is not marked , but certainly should be! thanks!
This also effects the three examples here: Should I file a separate issue?

Discussion:
/// /// # Examples /// <del> /// ```no_run </del> <ins> /// ```ignore (extern-declaration) </ins> /// # fn main() { /// use std::ffi::CString; /// use std::os::raw::c_char;

/// /// Inspecting a foreign C string: /// <del> /// ```no_run </del> <ins> /// ```ignore (extern-declaration) </ins> /// use std::ffi::CStr; /// use std::os::raw::c_char; ///

/// /// Passing a Rust-originating C string: /// <del> /// ```no_run </del> <ins> /// ```ignore (extern-declaration) </ins> /// use std::ffi::{CString, CStr}; /// use std::os::raw::c_char; ///

/// /// Converting a foreign C string into a Rust [`String`]: /// <del> /// ```no_run </del> <ins> /// ```ignore (extern-declaration) </ins> /// use std::ffi::CStr; /// use std::os::raw::c_char; ///

/// /// # Examples /// <del> /// ```no_run </del> <ins> /// ```ignore (extern-declaration) </ins> /// use std::ffi::CString; /// use std::os::raw::c_char; ///

/// Create a `CString`, pass ownership to an `extern` function (via raw pointer), then retake /// ownership with `from_raw`: /// <del> /// ```no_run </del> <ins> /// ```ignore (extern-declaration) </ins> /// use std::ffi::CString; /// use std::os::raw::c_char; ///

/// /// # Examples /// <del> /// ```no_run </del> <ins> /// ```ignore (extern-declaration) </ins> /// # fn main() { /// use std::ffi::CStr; /// use std::os::raw::c_char;
Change:
Yet another build failure caused by newer mingw-w64 from MSYS2
The relevant commit from mingw-w64 is probably I think we are mixing mingw-w64 library versions. Old crt2.o with newer libmsvcrt.a. Commit ( removed the downloading of rust-mingw which is a copy of mingw and libraries that should work with crt2.o, and other such libraries, that are included in rust-std. Extracting the matching rust-mingw files into the stage0 manually made the build continue. (Not sure if it will finish, it can take a while... ). EDIT: It finished.
Hm ok, we could try to add that download back in, I sort of forget at this point why it was removed..
I am running Arch Linux, rustc 1.31.0-nightly installed using rustup. I am using precompiled package from AUR. I am experiencing the same issue. To fix this, I tried this and it somehow worked :D I was compiling a Hello World application using gtk-rs.
cc

Discussion:
with open(self.rustc_stamp(), 'w') as rust_stamp: rust_stamp.write(self.date) <ins> # This is required so that we don't mix incompatible MinGW # libraries/binaries that are included in rust-std with # the system MinGW ones. if "pc-windows-gnu" in self.build: filename = "rust-mingw-{}-{}.tar.gz".format( rustc_channel, self.build) self._download_stage0_helper(filename, "rust-mingw") </ins> if self.cargo().startswith(self.bin_root()) and  (not os.path.exists(self.cargo()) or self.program_out_of_date(self.cargo_stamp())):
Change:
At the very least, the tests don't appear to be re-checked. It's possible is also not rebuilt.

Discussion:
} } <ins> /// Get the paths to all of the compiler's codegen backends. fn codegen_backends(&self, compiler: Compiler) -> impl Iterator<Item = PathBuf> { fs::read_dir(self.sysroot_codegen_backends(compiler)) .into_iter() .flatten() .filter_map(Result::ok) .map(|entry| entry.path()) } </ins> pub fn rustdoc(&self, host: Interned<String>) -> PathBuf { self.ensure(tool::Rustdoc { host }) }

match mode { Mode::Std => { self.clear_if_dirty(&my_out, &self.rustc(compiler)); <ins> for backend in self.codegen_backends(compiler) { self.clear_if_dirty(&my_out, &backend); } </ins> }, Mode::Test => { self.clear_if_dirty(&my_out, &libstd_stamp);
Change:
The command: cargo build The version: rustc 1.26.0-nightly ( 2018-02-25) The error:
Can confirm, is seeing this in our builds too.
Regression in . I will investigate.

Discussion:
<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. // Regression test for #48551. Covers a case where duplicate candidates // arose during associated type projection. use std::ops::{Mul, MulAssign}; pub trait ClosedMul<Right>: Sized + Mul<Right, Output = Self> + MulAssign<Right> {} impl<T, Right> ClosedMul<Right> for T where T: Mul<Right, Output = T> + MulAssign<Right>, { } pub trait InnerSpace: ClosedMul<<Self as InnerSpace>::Real> { type Real; } pub trait FiniteDimVectorSpace: ClosedMul<<Self as FiniteDimVectorSpace>::Field> { type Field; } pub trait FiniteDimInnerSpace : InnerSpace + FiniteDimVectorSpace<Field = <Self as InnerSpace>::Real> { } pub trait EuclideanSpace: ClosedMul<<Self as EuclideanSpace>::Real> { type Coordinates: FiniteDimInnerSpace<Real = Self::Real> + Mul<Self::Real, Output = Self::Coordinates> + MulAssign<Self::Real>; type Real; } fn main() {} </ins>
Change:
It should either elaborate on AssertUnwindSafe or else drop the claim that it will elaborate below.

Discussion:
#![feature(pointer_methods)] #![feature(inclusive_range_fields)] #![cfg_attr(stage0, feature(generic_param_attrs))] <ins> #![feature(rustc_const_unstable)] </ins> #![cfg_attr(not(test), feature(fn_traits, i128))] #![cfg_attr(test, feature(test))]

impl<T, A: Alloc> RawVec<T, A> { /// Like `new` but parameterized over the choice of allocator for /// the returned RawVec. <del> pub fn new_in(a: A) -> Self { </del> <ins> pub const fn new_in(a: A) -> Self { </ins> // !0 is usize::MAX. This branch should be stripped at compile time. <del> let cap = if mem::size_of::<T>() == 0 { !0 } else { 0 }; </del> <ins> // FIXME(mark-i-m): use this line when `if`s are allowed in `const` //let cap = if mem::size_of::<T>() == 0 { !0 } else { 0 }; </ins> // Unique::empty() doubles as "unallocated" and "zero-sized allocation" RawVec { ptr: Unique::empty(), <del> cap, </del> <ins> // FIXME(mark-i-m): use `cap` when ifs are allowed in const cap: [0, !0][(mem::size_of::<T>() == 0) as usize], </ins> a, } }

/// RawVec with capacity 0. If T has 0 size, then it makes a /// RawVec with capacity `usize::MAX`. Useful for implementing /// delayed allocation. <del> pub fn new() -> Self { </del> <ins> pub const fn new() -> Self { </ins> Self::new_in(Global) }

/// ``` #[inline] #[stable(feature = "rust1", since = "1.0.0")] <del> pub fn new() -> Vec<T> { </del> <ins> #[rustc_const_unstable(feature = "const_vec_new")] pub const fn new() -> Vec<T> { </ins> Vec { buf: RawVec::new(), len: 0,

/// This is useful for initializing types which lazily allocate, like /// `Vec::new` does. // FIXME: rename to dangling() to match NonNull? <del> pub fn empty() -> Self { </del> <ins> pub const fn empty() -> Self { </ins> unsafe { <del> let ptr = mem::align_of::<T>() as *mut T; Unique::new_unchecked(ptr) </del> <ins> Unique::new_unchecked(mem::align_of::<T>() as *mut T) </ins> } } }

<ins> // Copyright 2012 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. // Test that Vec::new() can be used for constants #![feature(const_vec_new)] const MY_VEC: Vec<usize> = Vec::new(); pub fn main() {} </ins>
Change:
Stable documentation (e.g. ): Click on to collapse everything Click on in Page will be scrolled to the . Nightly documentation (e.g. ): Click on to collapse everything Click on in Nothing will happen, because the is inside a collapsed outer section.
Another example: Click the word in the description on the page Nothing happens, making it appear that the link is broken. Since trait impls are collapsed by default, AFAIK there is no way to properly link to them. I'm guessing this would need to be implemented in and , and check if the block is hidden?

Discussion:
} } } <del> highlightSourceLines(null); </del> <ins> function expandSection(id) { var elem = document.getElementById(id); if (elem && isHidden(elem)) { var h3 = elem.parentNode.previousSibling; if (h3 && h3.tagName !== 'H3') { h3 = h3.previousSibling; // skip div.docblock } if (h3) { var collapses = h3.getElementsByClassName("collapse-toggle"); if (collapses.length > 0) { // The element is not visible, we need to make it appear! collapseDocs(collapses[0], "show"); } } } } </ins> window.onhashchange = highlightSourceLines; // Gets the human-readable string for the virtual-key code of the

} } <ins> function findParentElement(elem, tagName) { do { if (elem && elem.tagName === tagName) { return elem; } } while (elem = elem.parentNode); return null; } </ins> document.onkeypress = handleShortcut; document.onkeydown = handleShortcut; document.onclick = function(ev) {

} else if (!hasClass(document.getElementById("help"), "hidden")) { addClass(document.getElementById("help"), "hidden"); removeClass(document.body, "blur"); <ins> } else { // Making a collapsed element visible on onhashchange seems // too late var a = findParentElement(ev.target, 'A'); if (a && a.hash) { expandSection(a.hash.replace(/^#/, '')); } </ins> } };

autoCollapse(getPageId(), getCurrentValue("rustdoc-collapse") === "true"); if (window.location.hash && window.location.hash.length > 0) { <del> var hash = getPageId(); if (hash !== null) { var elem = document.getElementById(hash); if (elem && elem.offsetParent === null) { if (elem.parentNode && elem.parentNode.previousSibling) { var collapses = elem.parentNode .previousSibling .getElementsByClassName("collapse-toggle"); if (collapses.length > 0) { // The element is not visible, we need to make it appear! collapseDocs(collapses[0], "show"); } } } } </del> <ins> expandSection(window.location.hash.replace(/^#/, '')); </ins> } }());
Change:
cc possibly caused by ; it seems that stdsimd will have to be included in rust-src
Also, this broke Xargo and the development workflow of all the no_std / embedded users who use it. cc

Discussion:
"src/libterm", "src/jemalloc", "src/libprofiler_builtins", <ins> "src/stdsimd", </ins> ]; let std_src_dirs_exclude = [ "src/libcompiler_builtins/compiler-rt/test",
Change:
rustc crashed during compilation with: (This is a locally built rustc 1.24.0, compiled in the dev channel. It is being invoked from Buck in a custom build system, which is why the paths are atypical.) It appears that the file is truncated, or corrupt in some way that makes it try to parse off the end of the file. This was on a machine that had been running into out-of-memory conditions, so its possible its a left-over from a previous failed compilation attempt. I think rustc should handle corrupted incremental data by handling the error, deleting the file and compiling non-incrementally.

Discussion:
Some(future) => { let prev_graph = time(sess, "blocked while dep-graph loading finishes", || { future.open() <del> .expect("Could not join with background dep_graph thread") </del> <ins> .unwrap_or_else(|e| rustc_incremental::LoadResult::Error { message: format!("could not decode incremental cache: {:?}", e) }) </ins> .open(sess) }); DepGraph::new(prev_graph)

pub use persist::dep_graph_tcx_init; pub use persist::load_dep_graph; pub use persist::load_query_result_cache; <ins> pub use persist::LoadResult; </ins> pub use persist::save_dep_graph; pub use persist::save_trans_partition; pub use persist::save_work_products;

pub fn open(self, sess: &Session) -> PreviousDepGraph { match self { LoadResult::Error { message } => { <del> sess.fatal(&message) /* never returns */ </del> <ins> sess.warn(&message); PreviousDepGraph::new(SerializedDepGraph::new()) </ins> }, LoadResult::DataOutOfDate => { if let Err(err) = delete_all_session_dir_contents(sess) {

pub use self::load::dep_graph_tcx_init; pub use self::load::load_dep_graph; pub use self::load::load_query_result_cache; <ins> pub use self::load::LoadResult; </ins> pub use self::save::save_dep_graph; pub use self::save::save_work_products; pub use self::work_product::save_trans_partition;
Change:
Bisecting it seems to be an issue with . It appears this may be a double crash? Like it's hitting some error and then unwinding improperly and crashing again. Not familiar enough with the traces to know.
The root error seems to be a crash from - everything else is a result of that.
The issue is with the crate. Miri's errors generate a true backtrace (not const eval backtrace, but from within the compiler). cc You can work around this issue for now by not passing () Not sure what the correct course of action is here (except for fixing on FreeBSD of course, but I can't do that). Should we simply not generate backtraces on bsd?
Ah this is unfortunate :( But yeah the "best" solution for now is probably to avoid backtrace generation on freebsd
should that be disabled in rustc or in the backtrace crate?
Either's fine by me, but I'd probably recommend rustc
I prefer the backtrace crate. There is a lot of code that depends on and will fail on these platforms anyways. If doesn't support some platform, it should probably, silently, just write backtraces that state "platform not supported" or similar instead of crashing or failing to compile.

Discussion:
impl<'tcx> From<EvalErrorKind<'tcx>> for EvalError<'tcx> { fn from(kind: EvalErrorKind<'tcx>) -> Self { <del> let backtrace = match env::var("RUST_BACKTRACE") { </del> <ins> let backtrace = match env::var("MIRI_BACKTRACE") { </ins> Ok(ref val) if !val.is_empty() => Some(Backtrace::new_unresolved()), _ => None };
Change:
Computing the specialization graph for a trait involves looking at lots of things. The result of the query should be easily cacheable:
I'll take this.

Discussion:
///   parents of a given specializing impl, which is needed for extracting ///   default items amongst other things. In the simple "chain" rule, every impl ///   has at most one parent. <ins> #[derive(RustcEncodable, RustcDecodable)] </ins> pub struct Graph { // all impls have a parent; the "root" impls have as their parent the def_id // of the trait

/// Children of a given impl, grouped into blanket/non-blanket varieties as is /// done in `TraitDef`. <ins> #[derive(RustcEncodable, RustcDecodable)] </ins> struct Children { // Impls of a trait (or specializations of a given impl). To allow for // quicker lookup, the impls are indexed by a simplified version of their

/// because we sometimes need to use SimplifiedTypeGen values as stable sorting /// keys (in which case we use a DefPathHash as id-type) but in the general case /// the non-stable but fast to construct DefId-version is the better choice. <del> #[derive(Clone, Copy, Debug, PartialEq, Eq, Hash, PartialOrd, Ord)] </del> <ins> #[derive(Clone, Copy, Debug, PartialEq, Eq, Hash, PartialOrd, Ord, RustcEncodable, RustcDecodable)] </ins> pub enum SimplifiedTypeGen<D> where D: Copy + Debug + Ord + Eq + Hash {

impl_disk_cacheable_query!(predicates_of, |def_id| def_id.is_local()); impl_disk_cacheable_query!(used_trait_imports, |def_id| def_id.is_local()); impl_disk_cacheable_query!(trans_fn_attrs, |_| true); <ins> impl_disk_cacheable_query!(specialization_graph_of, |_| true); </ins>

encode_query_results::<symbol_name, _>(tcx, enc, qri)?; encode_query_results::<check_match, _>(tcx, enc, qri)?; encode_query_results::<trans_fn_attrs, _>(tcx, enc, qri)?; <ins> encode_query_results::<specialization_graph_of, _>(tcx, enc, qri)?; </ins> // const eval is special, it only encodes successfully evaluated constants use ty::maps::plumbing::GetCacheInternal;

PredicatesOfItem => predicates_of, UsedTraitImports => used_trait_imports, TransFnAttrs => trans_fn_attrs, <ins> SpecializationGraph => specialization_graph_of, </ins> );
Change:
This segfaults.
Reproduced. I'll take a stab at it.
Hmm, I'm not sure if this should even be legal (that is, whether it should be accepted by borrowck). And, the failure (which also happens when i change the pattern from to just ) is a null-dereference in . I think I may be a bit out of my depth here.
I think this should be legal. Presumably we are failing to root the managed box or something like that, I'm not sure what this function is.
Fixed, just need to add the test case

Discussion:
#[lang="return_to_mut"] #[inline(always)] pub unsafe fn return_to_mut(a: *u8) { <del> let a: *mut BoxRepr = transmute(a); (*a).header.ref_count &= !FROZEN_BIT; </del> <ins> // Sometimes the box is null, if it is conditionally frozen. // See e.g. #4904. if !a.is_null() { let a: *mut BoxRepr = transmute(a); (*a).header.ref_count &= !FROZEN_BIT; } </ins> } #[lang="check_not_borrowed"]
Change:
After a while I have noticed that compilation wasn't going to stop. And I see 3 rustc processes with However, after 15 minutes I saw one more process with And 9 minutes after there was another process. So, it looks like compilation is not infinite per se, it just tooks way more time to finish. (P.S. It took 28 minutes to fall with "can't find crate for "). For example, rustc has the following stack of a thread that burns CPU:
cc
Thanks for the bug report,
Strangely enough looks like it happens only on Windows (both msvc and gnu).
Just to clarify: building the dependencies for the crate failing with the above error took 28 minutes. The final crate errors immediately. So it's not const eval related just because it mentions . It is const eval related though ;) And the issue is most likely backtrace generation. Is it possible generating backtraces takes a long time on windows? Every const eval error generates a backtrace. I think we can safely assume noone needs those except for someone debugging miri. The backtraces are also an issue for FreeBSD. I don't want to remove them because they are super helpful for miri debugging, but since they obviously have a negative effect, I'll add a check to only generate them if explicitly requested.
triage: P-high

Discussion:
impl<'tcx> From<EvalErrorKind<'tcx>> for EvalError<'tcx> { fn from(kind: EvalErrorKind<'tcx>) -> Self { <del> let backtrace = match env::var("RUST_BACKTRACE") { </del> <ins> let backtrace = match env::var("MIRI_BACKTRACE") { </ins> Ok(ref val) if !val.is_empty() => Some(Backtrace::new_unresolved()), _ => None };