jiebi/CodeConvo huggingface dataset:
Change:
Compiler crashes while compiling using Cargo. Cargo version: cargo 0.6.0-nightly ( 2015-10-17) rustc version: 1.3.0
It looks like this comes from the linker producing output (normal or error) that is not valid UTF-8. Fixing this in any other way than just using a lossy conversion is going to be really painful because it goes through the error logging infrastructure, which all works with s. That's certainly not ideal, because it would be best to relay other programs' messages to the user unchanged, but it's probably the only realistic way to handle this in the near future.
Just dump the bytes as hexadecimal? I am not sure what is going on here.
My first thought was that the path was probably not UTF-8, but because of the way cargo invokes it that crashes rustc long before it tries to link anything, so that can't be it. I'm not sure why else the message would be non-UTF-8. (I can't reproduce the ICE on that crate (I just get a normal link error), but I can reproduce the ICE by constructing a situation where the linker prints non-UTF-8 messages.) But yeah, some kind of lossy conversion with hex escapes is probably the way to go. I'm not aware of an existing function to do that.
Actually, mapping with is probably good enough.
foo'ncollect2: error: ld returned 1 exit statusn` Not great, but not an ICE and probably good enough until we have a dedicated function to do this sort of thing since this should be a very rare error.

Discussion:
use util::fs::fix_windows_verbatim_for_gcc; use rustc_back::tempdir::TempDir; <ins> use std::ascii; use std::char; </ins> use std::env; use std::ffi::OsString; use std::fs::{self, PathExt};

let prog = time(sess.time_passes(), "running linker", || cmd.output()); match prog { Ok(prog) => { <ins> fn escape_string(s: &[u8]) -> String { str::from_utf8(s).map(|s| s.to_owned()) .unwrap_or_else(|_| { let mut x = "Non-UTF-8 output: ".to_string(); x.extend(s.iter() .flat_map(|&b| ascii::escape_default(b)) .map(|b| char::from_u32(b as u32).unwrap())); x }) } </ins> if !prog.status.success() { sess.err(&format!("linking with `{}` failed: {}", pname,

sess.note(&format!("{:?}", &cmd)); let mut output = prog.stderr.clone(); output.push_all(&prog.stdout); <del> sess.note(str::from_utf8(&output[..]).unwrap()); </del> <ins> sess.note(&*escape_string(&output[..])); </ins> sess.abort_if_errors(); } <del> info!("linker stderr:n{}", String::from_utf8(prog.stderr).unwrap()); info!("linker stdout:n{}", String::from_utf8(prog.stdout).unwrap()); </del> <ins> info!("linker stderr:n{}", escape_string(&prog.stderr[..])); info!("linker stdout:n{}", escape_string(&prog.stdout[..])); </ins> }, Err(e) => { sess.fatal(&format!("could not exec the linker `{}`: {}", pname, e));
Change:
read_dir returns ErrorKind::Other for inexistent file. I tried this code I expected to see . Instead it shows Rust version

Discussion:
} } } <ins> #[test] fn read_dir_not_found() { let res = fs::read_dir("/path/that/does/not/exist"); assert_eq!(res.err().unwrap().kind(), ErrorKind::NotFound); } </ins> }

pub const EXCEPTION_MAXIMUM_PARAMETERS: usize = 15; pub const EXCEPTION_STACK_OVERFLOW: DWORD = 0xc00000fd; <ins> pub const ERROR_PATH_NOT_FOUND: libc::c_int = 3; </ins> #[repr(C)] #[cfg(target_arch = "x86")] pub struct WSADATA {

libc::ERROR_ALREADY_EXISTS => ErrorKind::AlreadyExists, libc::ERROR_BROKEN_PIPE => ErrorKind::BrokenPipe, libc::ERROR_FILE_NOT_FOUND => ErrorKind::NotFound, <ins> c::ERROR_PATH_NOT_FOUND => ErrorKind::NotFound, </ins> libc::ERROR_NO_DATA => ErrorKind::BrokenPipe, libc::ERROR_OPERATION_ABORTED => ErrorKind::TimedOut,
Change:
Updated 10/21: is currently valid Rust. I don't know if it should be, but it causes the compiler to blow its stack when recursively traversing a crate which contains it. To reproduce: Create a lib crate with this body: (compiles fine)Link to this crate, then include code that results in a method missing error, such as: This will cause the stack to overflow in while it looks up traits in linked crates that define a method . There are probably other functions which overflow like this in the case of this text. I would think either should be smart enough to not recursively include the self module or should be an error.
It would be easier to debug this problem if we would have source code that causes it (e.g. for ).
I did some debugging, found the issue, and have updated the title and top comment to explain it clearly, including steps to reproduce. Fortunately, the practical fix is easy (don't use ).

Discussion:
use middle::subst::Substs; use middle::traits::{Obligation, SelectionContext}; use metadata::{csearch, cstore, decoder}; <ins> use util::nodemap::{FnvHashSet}; </ins> use syntax::ast; use syntax::codemap::Span;

}, ccx.tcx.map.krate()); // Cross-crate: <ins> let mut external_mods = FnvHashSet(); </ins> fn handle_external_def(traits: &mut AllTraitsVec, <ins> external_mods: &mut FnvHashSet<DefId>, </ins> ccx: &CrateCtxt, cstore: &cstore::CStore, dl: decoder::DefLike) {

traits.push(TraitInfo::new(did)); } decoder::DlDef(def::DefMod(did)) => { <ins> if !external_mods.insert(did) { return; } </ins> csearch::each_child_of_item(cstore, did, |dl, _, _| { <del> handle_external_def(traits, ccx, cstore, dl) </del> <ins> handle_external_def(traits, external_mods, ccx, cstore, dl) </ins> }) } _ => {}

let cstore = &ccx.tcx.sess.cstore; cstore.iter_crate_data(|cnum, _| { csearch::each_top_level_item_of_crate(cstore, cnum, |dl, _, _| { <del> handle_external_def(&mut traits, ccx, cstore, dl) </del> <ins> handle_external_def(&mut traits, &mut external_mods, ccx, cstore, dl) </ins> }) });

<ins> // Copyright 2015 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. #![crate_type="lib"] pub mod foo { pub use super::*; } </ins>

<ins> // Copyright 2015 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. // aux-build:issue-29181.rs extern crate issue_29181 as foo; fn main() { 0.homura(); //~ ERROR no method named `homura` found } </ins>
Change:
This fails to build: NB. I'm on an x86-64 computer, but I installed and am running a i686 compiler via multirust: It also , where the i686 installer is and manually. I guess this may be some issue with how multirust/that installation works.
This looks like it's because the host libs are different from the target libs (in theory shouldn't ever happen). Possible cause: the i686 libstd package is actually a bunch of libraries produced by a x8664 compiler, it may be the case that the symbols or something along the line is dependent on the architecture that produced the artifact. The i686 host libs, however, are produced by an i686 compiler. I think due to the way hashing works the same library compiled by an i686 compiler vs x8664 compiler (even if for the same target) will produce different binaries (causing the discrepancy here). This... seems like we should be more picky about picking libs to ship!

Discussion:
$(foreach host,$(CFG_HOST), $(eval $(call DEF_INSTALLER,$(host)))) <del> $(foreach target,$(CFG_TARGET), </del> <ins> # When generating packages for the standard library, we've actually got a lot of # artifacts to choose from. Each of the CFG_HOST compilers will have a copy of # the standard library for each CFG_TARGET, but we only want to generate one # standard library package. As a result, for each entry in CFG_TARGET we need to # pick a CFG_HOST to get the standard library from. # # In theory it doesn't actually matter what host we choose as it should be the # case that all hosts produce the same set of libraries for a target (regardless # of the host itself). Currently there is a bug in the compiler, however, which # means this is not the case (see #29228 and #29235). To solve the first of # those bugs, we prefer to select a standard library from the host it was # generated from, allowing plugins to work in more situations. # # For all CFG_TARGET entries in CFG_HOST, however, we just pick CFG_BUILD as the # host we slurp up a standard library from. $(foreach host,$(CFG_HOST), $(eval $(call DEF_INSTALLER_TARGETS,$(host),$(host)))) $(foreach target,$(filter-out $(CFG_HOST),$(CFG_TARGET)), </ins> $(eval $(call DEF_INSTALLER_TARGETS,$(CFG_BUILD),$(target)))) ifdef CFG_WINDOWSY_$(CFG_BUILD)
Change:
Program: Crate test1lib: Notice that this is a static in one crate referencing a static in another crate. A complete cargo-buildable test case is at This bug was found by a user of . The coding pattern in this test case commonly occurs when using ring. To reproduce: rustc crashes with Reproduced with (on x86_64-pc-windows-msvc): rustc 1.3.0 ( 2015-09-15) / cargo 0.4.0-nightly ( 2015-08-03) (built 2015-08-03) rustc 1.4.0-nightly ( 2015-08-27) / cargo 0.5.0-nightly ( 2015-08-26) rustc 1.5.0-nightly ( 2015-10-22) / cargo 0.6.0-nightly ( 2015-10-22)
In particular, this was found by who originally reported it as
Triaging: There is an error hapening on , but it is not the Assertion on GEP indices anymore. On nightly the example compiles without errors.
Stable probably still hits the same assert, but LLVM assertions are disabled on stable and beta
This no longer asserts on the current nightly.

Discussion:
<ins> #![crate_type = "lib"] pub struct SomeType { pub some_member: usize, } pub static SOME_VALUE: SomeType = SomeType { some_member: 1, }; </ins>

<ins> #![crate_type = "lib"] pub fn foo() -> Vec<String> { std::env::args() .skip(1) .collect() } </ins>

<ins> // aux-build:issue-29265.rs // check-pass extern crate issue_29265 as lib; static _UNUSED: &'static lib::SomeType = &lib::SOME_VALUE; fn main() { vec![0u8; lib::SOME_VALUE.some_member]; } </ins>

<ins> // ignore-emscripten no asm! support #![feature(asm)] fn main() { unsafe { asm!("" :: "r"("")); //~^ ERROR: invalid value for constraint in inline assembly } } </ins>

<ins> error[E0669]: invalid value for constraint in inline assembly --> $DIR/issue-37433.rs:7:24 | LL |         asm!("" :: "r"("")); |                        ^^ error: aborting due to previous error </ins>

<ins> // aux-build:issue-49544.rs // check-pass extern crate issue_49544; use issue_49544::foo; fn main() { let _ = foo(); } </ins>
Change:
Should be mentioned in the "Method Syntax" chapter: Example: Rationale: Makes the following traits section more sense:

Discussion:
This will print `12.566371`. We’ve made a `struct` that represents a circle. We then write an `impl` block, and inside it, define a method, `area`.

} ``` <ins> You can use as many `impl` blocks as you’d like. The previous example could have also been written like this: ```rust struct Circle { x: f64, y: f64, radius: f64, } impl Circle { fn reference(&self) { println!("taking self by reference!"); } } impl Circle { fn mutable_reference(&mut self) { println!("taking self by mutable reference!"); } } impl Circle { fn takes_ownership(self) { println!("taking ownership of self!"); } } ``` </ins> # Chaining method calls So, now we know how to call a method, such as `foo.bar()`. But what about our
Change:
Part of did a wonderful job here a month or two ago, but we should still double check it, and make sure links are in place for all types, etc.
I am happy with this now.

Discussion:
//! Overloadable operators. //! <del> //! Implementing these traits allows you to get an effect similar to //! overloading operators. </del> <ins> //! Implementing these traits allows you to overload certain operators. </ins> //! //! Some of these traits are imported by the prelude, so they are available in <del> //! every Rust program. </del> <ins> //! every Rust program. Only operators backed by traits can be overloaded. For //! example, the addition operator (`+`) can be overloaded through the `Add` //! trait, but since the assignment operator (`=`) has no backing trait, there //! is no way of overloading its semantics. Additionally, this module does not //! provide any mechanism to create new operators. If traitless overloading or //! custom operators are required, you should look toward macros or compiler //! plugins to extend Rust's syntax. </ins> //! //! Many of the operators take their operands by value. In non-generic //! contexts involving built-in types, this is usually not a problem.
Change:
As mentioned in This strikes me as a bug, either in the core library or in the documentation. Previously reported at , moving here.
This is a dupe of (and somewhat related to and ). Thanks for filing!
In general, however, I don't necessarily consider and as dependencies of libcore that need to be worried about. Linking with will eliminate them and otherwise you still have to deal with basic dependencies like and , so having a few small "very well known" functions being unimplemented I think is fine (although they should obviously be minimized where possible). If we could I'd love to only provide / on floats in the standard library, but coherence forces our hand of putting them in libcore, and it's not necessarily the end of the world.
I'm still not sure that we should describe as 'dependency free' if there are dependencies, though. Shouldn't that be a doc issue?

Discussion:
//! # The Rust Core Library //! <del> //! The Rust Core Library is the dependency-free foundation of [The </del> <ins> //! The Rust Core Library is the dependency-free[^free] foundation of [The </ins> //! Rust Standard Library](../std/index.html). It is the portable glue //! between the language and its libraries, defining the intrinsic and //! primitive building blocks of all Rust code. It links to no //! upstream libraries, no system libraries, and no libc. //! <ins> //! [^free]: Strictly speaking, there are some symbols which are needed but //!          they aren't always neccesary. //! </ins> //! The core library is *minimal*: it isn't even aware of heap allocation, //! nor does it provide concurrency or I/O. These things require //! platform integration, and this library is platform-agnostic.
Change:
In The Stack and Heap section: "There’s some important things we have to take note of here." is slightly incorrect because there's is usually considered as a contraction for there is. Although according to this: maybe it's acceptable. Nonetheless it would be better to write: "There are some important things we have to take note of here."
Thank you! I would accept a patch for that change. If anyone would like to try to fix this, I'm willing to help. The source is in , just the text needs changed.

Discussion:
stack frame. It grows upward, the more functions we call. <del> There’s some important things we have to take note of here. The numbers 0, 1, </del> <ins> There are some important things we have to take note of here. The numbers 0, 1, </ins> and 2 are all solely for illustrative purposes, and bear no relationship to the actual numbers the computer will actually use. In particular, the series of addresses are in reality going to be separated by some number of bytes that
Change:
gives an example that uses , where using works just as well (tested: rustc 1.6.0-nightly ( 2015-10-29)). And therefore I have no idea why and where I'd need the longer form. I tested
The expanded form is required when the method you want to call doesn't mention in any way. For example: Seems like the example in the book should be updated to something like that.
works just fine there. I agree we need a better example.... but I'm not sure what that is.
Ah yeah. If you add a directly to as well, then you should need to use the full UFCS form to specify you want to call 's rather than 's:

Discussion:
```rust trait Foo { <del> fn clone(&self); </del> <ins> fn foo() -> i32; </ins> } <del> #[derive(Clone)] </del> struct Bar; <del> impl Foo for Bar { fn clone(&self) { println!("Making a clone of Bar"); </del> <ins> impl Bar { fn foo() -> i32 { 20 } } </ins> <del> <Bar as Clone>::clone(self); </del> <ins> impl Foo for Bar { fn foo() -> i32 { 10 </ins> } } <ins> fn main() { assert_eq!(10, <Bar as Foo>::foo()); assert_eq!(20, Bar::foo()); } </ins> ``` <del> This will call the `Clone` trait’s `clone()` method, rather than `Foo`’s. </del> <ins> Using the angle bracket syntax lets you call the trait method instead of the inherent one. </ins>
Change:
As noted in among other places, core is not really completely dependency-free. While this claim is defensible in some sense, the crate documentation could be more clear about what it means by this, for example by describing the criterion outlined by in the aforementioned issue: The docs already talk about and , but in the meantime libcore gained a few other (intentionally) undefined symbols such as and --- possibly others as well. The docs should explain those symbols too, and also explain how get around the need for them (don't use on floats, link with ).

Discussion:
//! # The Rust Core Library //! <del> //! The Rust Core Library is the dependency-free foundation of [The </del> <ins> //! The Rust Core Library is the dependency-free[^free] foundation of [The </ins> //! Rust Standard Library](../std/index.html). It is the portable glue //! between the language and its libraries, defining the intrinsic and //! primitive building blocks of all Rust code. It links to no //! upstream libraries, no system libraries, and no libc. //! <ins> //! [^free]: Strictly speaking, there are some symbols which are needed but //!          they aren't always neccesary. //! </ins> //! The core library is *minimal*: it isn't even aware of heap allocation, //! nor does it provide concurrency or I/O. These things require //! platform integration, and this library is platform-agnostic.
Change:
has the implementation which is It is however , so rustdoc does the correct thing after doc inlining. This bug with blanket impls shows up in user's crates, ; for example the trait in itertools does not have its blanket impl visible in the docs.
It regressed on nightly, it also disappeard from the libstd page.
The regression is not due to specialization, see e.g. vs which does not use specialization. Regression is also visible on beta btw.
hmm, is this bug affecting me? , corresponding
Yes, it's the same bug.
thanks. a bit confusing, since that impl is the whole point of my crate :smile:
The regression was already fixed in

Discussion:
_ => None, } } <ins> pub fn is_generic(&self) -> bool { match *self { ResolvedPath { is_generic, .. } => is_generic, _ => false, } } </ins> } impl GetDefId for Type {

// trait impls for private items should be stripped clean::ImplItem(clean::Impl{ <del> for_: clean::ResolvedPath{ did, .. }, .. </del> <ins> for_: clean::ResolvedPath{ did, is_generic, .. }, .. </ins> }) => { <del> if did.is_local() && !self.access_levels.is_exported(did) { </del> <ins> if did.is_local() && !is_generic && !self.access_levels.is_exported(did) { </ins> return None; } }

fn fold_item(&mut self, i: Item) -> Option<Item> { if let clean::ImplItem(ref imp) = i.inner { if let Some(did) = imp.for_.def_id() { <del> if did.is_local() && !self.retained.contains(&did) { </del> <ins> if did.is_local() && !imp.for_.is_generic() && !self.retained.contains(&did) { </ins> return None; } }

<ins> // Copyright 2016 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. use std::fmt; // @has issue_29503/trait.MyTrait.html pub trait MyTrait { fn my_string(&self) -> String; } // @has - "//ul[@id='implementors-list']/li" "impl<T> MyTrait for T where T: Debug" impl<T> MyTrait for T where T: fmt::Debug { fn my_string(&self) -> String { format!("{:?}", self) } } pub fn main() { } </ins>
Change:
For the following error code: I think it's useful to suggest that the following statement may be needed for :
It actually does say that in the error message: But not on the error explanations page.

Discussion:
pub struct Foo; } ``` <ins> Or, if you tried to use a module from an external crate, you may have missed the `extern crate` declaration: ``` extern crate homura; // Required to use the `homura` crate use homura::Madoka; ``` </ins> "##, E0433: r##"
Change:
Some systems, like Gentoo, want to package multiple versions of the Rust compiler along side each other. There are several obstacles to this, but the obvious one is that the installed Rust crates need to not have conflicting names. While we have a mechanism for this , the extra strings appended by the current makefile are not sufficient to discriminate between arbitrary compiler revisions. Most likely we will add a configure switch that specifies an additional string to hash into the filename extra, in addition to what we're already hashing. re

Discussion:
valopt nacl-cross-path  "" "NaCl SDK path (Pepper Canary is recommended). Must be absolute!" valopt release-channel "dev" "the name of the release channel to build" valopt musl-root "/usr/local" "MUSL root installation directory" <ins> valopt extra-filename "" "Additional data that is hashed and passed to the -C extra-filename flag" </ins> # Used on systems where "cc" and "ar" are unavailable valopt default-linker "cc" "the default linker"

# Append a version-dependent hash to each library, so we can install different # versions in the same place <del> CFG_FILENAME_EXTRA=$(shell printf '%s' $(CFG_RELEASE) | $(CFG_HASH_COMMAND)) </del> <ins> CFG_FILENAME_EXTRA=$(shell printf '%s' $(CFG_RELEASE)$(CFG_EXTRA_FILENAME) | $(CFG_HASH_COMMAND)) </ins> ifeq ($(CFG_RELEASE_CHANNEL),stable) # This is the normal semver version string, e.g. "0.12.0", "0.12.0-nightly"