jiebi/CodeConvo huggingface dataset:
Change:
I found an error message that seems a bit off to me. The code: Clearly it should fail to compile, and it does. But the error message is: I would expect something like "a module name has already been imported", instead. Is it accurate to call it a type?

Discussion:
use DefModifiers; use Module; <ins> use ModuleKind; </ins> use Namespace::{self, TypeNS, ValueNS}; use NameBindings; use NamespaceResult::{BoundResult, UnboundResult, UnknownResult};

match target { Some(ref target) if target.shadowable != Shadowable::Always => { let ns_word = match namespace { <del> TypeNS => "type", </del> <ins> TypeNS => { if let Some(ref ty_def) = *target.bindings.type_def.borrow() { match ty_def.module_def { Some(ref module) if module.kind.get() == ModuleKind::NormalModuleKind => "module", Some(ref module) if module.kind.get() == ModuleKind::TraitModuleKind => "trait", _ => "type", } } else { "type" } }, </ins> ValueNS => "value", }; span_err!(self.resolver.session, import_span, E0252,

<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. use foo::baz; use bar::baz; //~ ERROR a module named `baz` has already been imported use foo::Quux; use bar::Quux; //~ ERROR a trait named `Quux` has already been imported use foo::blah; use bar::blah; //~ ERROR a type named `blah` has already been imported use foo::WOMP; use bar::WOMP; //~ ERROR a value named `WOMP` has already been imported fn main() {} mod foo { pub mod baz {} pub trait Quux { } pub type blah = (f64, u32); pub const WOMP: u8 = 5; } mod bar { pub mod baz {} pub type Quux = i32; struct blah { x: i8 } pub const WOMP: i8 = -5; } </ins>
Change:
At the end of Rust Book chapter 5.27 and is : Unfortunately, this is rather misleading. An experienced C programmer will try and avoid as much as possible (they do have their use) because: a is unscoped, and the C preprocessor is just a text preprocessor a is untyped You can check for more context and relevant advices; specifically Jonathan Leffer's answer (yep, just skip mine). Note: in C++, the answer is because C++ lifts a lot of restrictions for where one can use variables. Since in Rust is scoped and typed, it is really no equivalent to . It is, however, much closer to . Maybe simply comparing to instead of would avoid confusing the reader?
We had a chat about this on Reddit, I wanted an issue here for more visibility. Thoughts, anyone else?
I think it would be fine to add some clarification here, but the emphasis is that the definition is inlined everywhere (like ), not so much the odd semantics of

Discussion:
rare that you actually want a memory location associated with your constant, and using a const allows for optimizations like constant propagation not only in your crate but downstream crates. <del> A const can be thought of as a `#define` in C: it has metadata overhead but it has no runtime overhead. “Should I use a #define or a static in C,” is largely the same question as whether you should use a const or a static in Rust. </del>
Change:
On Rust 1.0
Minified: Backtrace (this is a relatively old rustc 2015-05-06, but playpen also crashes):
Neither test case appears to cause an ICE anymore.
Added a test case in PR

Discussion:
<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. enum Sexpression { Num(()), Cons(&'static mut Sexpression) } fn causes_ice(mut l: &mut Sexpression) { loop { match l { &mut Sexpression::Num(ref mut n) => {}, &mut Sexpression::Cons(ref mut expr) => { //~ ERROR cannot borrow `l.0` //~| ERROR cannot borrow `l.0` l = &mut **expr; //~ ERROR cannot assign to `l` } }} } fn main() { } </ins>
Change:
This is the link To quote: I understand "propagation" meaning "required linking of this artifact will attach further and further towards the final artifacts". The top sentence says "static libs are not propagated", but the following explanation (A native build dependency) makes it look like static libs are always propagated, on the contrary.

Discussion:
The different `kind` values are meant to differentiate how the native library participates in linkage. From a linkage perspective, the rust compiler creates two flavors of artifacts: partial (rlib/staticlib) and final (dylib/binary). <del> Native dynamic libraries and frameworks are propagated to the final artifact boundary, while static libraries are not propagated at all. </del> <ins> Native dynamic library and framework dependencies are propagated to the final artifact boundary, while static library dependencies are not propagated at all, because the static libraries are integrated directly into the subsequent artifact. </ins> A few examples of how this model can be used are:
Change:
In the book: I think it's better to add a few lines and let the readers know why bumping up the reference count here is needed.
It's hard to figure out what level of depth to go into in these higher-level docs, you're right.

Discussion:
Finally, inside of our `map()`/`collect()` loop, we call `table.clone()`. The `clone()` method on `Arc<T>` is what bumps up the reference count, and when it <del> goes out of scope, it decrements the count. You’ll notice we can introduce a new binding to `table` here, and it will shadow the old one. This is often used so that you don’t need to come up with two unique names. </del> <ins> goes out of scope, it decrements the count. This is needed so that we know how many references to `table` exist across our threads. If we didn’t have a count, we wouldn’t know how to deallocate it. You’ll notice we can introduce a new binding to `table` here, and it will shadow the old one. This is often used so that you don’t need to come up with two unique names. </ins> With this, our program works! Only two philosophers can eat at any one time, and so you’ll get some output like this:
Change:
current beta is 'rustc 1.1.0-beta' but it should be 'rustc 1.1.0-beta.1'

Discussion:
CFG_DISABLE_UNSTABLE_FEATURES=1 endif ifeq ($(CFG_RELEASE_CHANNEL),beta) <del> CFG_RELEASE=$(CFG_RELEASE_NUM)-beta </del> <ins> CFG_RELEASE=$(CFG_RELEASE_NUM)-beta$(CFG_PRERELEASE_VERSION) </ins> # When building beta distributables just reuse the same "beta" name # so when we upload we'll always override the previous beta. This # doesn't actually impact the version reported by rustc - it's just
Change:
At the end of bar(), it calls baz(): In the code baz is passed f whose value is the address of d which is 9. However, in the diagram, it is given a value of 4.
I believe this is fixed on master, can you confirm?
I believe it should say 11 f 9 not 11 f 4
not fixed on master but just filed a PR to do so

Discussion:
| (2<sup>30</sup>) - 1 |      | 5                    | | ...                  | ...  | ...                  | | 12                   | g    | 100                  | <del> | 11                   | f    | 4                    | </del> <ins> | 11                   | f    | 9                    | </ins> | 10                   | e    | 9                    | | 9                    | d    | (2<sup>30</sup>) - 1 | | 8                    | c    | 5                    |
Change:
This is with clang built from source. Guessing something in is not right. compare: What was ?
needs 3.7. I got this.

Discussion:
| cut -d ' ' -f 2) case $CFG_CLANG_VERSION in <del> (3.2* | 3.3* | 3.4* | 3.5* | 3.6*) </del> <ins> (3.2* | 3.3* | 3.4* | 3.5* | 3.6* | 3.7*) </ins> step_msg "found ok version of CLANG: $CFG_CLANG_VERSION" if [ -z "$CC" ] then
Change:
The page doesn't explain that it's possible to match compound data in this way: Currently only this form is covered: The latter form results in compiler warnings (). I'm not sure whether it should be avoided for that reason.
fixed this

Discussion:
let origin = Point { x: 0, y: 0 }; match origin { <del> Point { x: x, y: y } => println!("({},{})", x, y), </del> <ins> Point { x, y } => println!("({},{})", x, y), </ins> } ``` [struct]: structs.html <ins> We can use `:` to give a value a different name. ```rust struct Point { x: i32, y: i32, } let origin = Point { x: 0, y: 0 }; match origin { Point { x: x1, y: y1 } => println!("({},{})", x1, y1), } ``` </ins> If we only care about some of the values, we don’t have to give them all names: ```rust

let origin = Point { x: 0, y: 0 }; match origin { <del> Point { x: x, .. } => println!("x is {}", x), </del> <ins> Point { x, .. } => println!("x is {}", x), </ins> } ```

let origin = Point { x: 0, y: 0 }; match origin { <del> Point { y: y, .. } => println!("y is {}", y), </del> <ins> Point { y, .. } => println!("y is {}", y), </ins> } ```
Change:
Appears like: Essentially, 'LINK_foo' is empty. Heres a list:
I think this is your issue. (I ran into it myself while doing a build)
Dup of , apparently.
I believe this will be fixed by
Closing as a duplicate.

Discussion:
# aarch64-linux-android configuration # CROSS_PREFIX_aarch64-linux-android- CC_aarch64-linux-android=$(CFG_ANDROID_CROSS_PATH)/bin/aarch64-linux-android-gcc <del> LINK_aarch64-linux-android=$(CFG_ANDROID_CROSS_PATH)/bin/aarch64-linux-android-gcc </del> CXX_aarch64-linux-android=$(CFG_ANDROID_CROSS_PATH)/bin/aarch64-linux-android-g++ CPP_aarch64-linux-android=$(CFG_ANDROID_CROSS_PATH)/bin/aarch64-linux-android-gcc -E AR_aarch64-linux-android=$(CFG_ANDROID_CROSS_PATH)/bin/aarch64-linux-android-ar

# aarch64-unknown-linux-gnu configuration CROSS_PREFIX_aarch64-unknown-linux-gnu=aarch64-linux-gnu- CC_aarch64-unknown-linux-gnu=gcc <del> LINK_aarch64-unknown-linux-gnu=gcc </del> CXX_aarch64-unknown-linux-gnu=g++ CPP_aarch64-unknown-linux-gnu=gcc -E AR_aarch64-unknown-linux-gnu=ar

# arm-linux-androideabi configuration <del> LINK_arm-linux-androideabi=$(CFG_ANDROID_CROSS_PATH)/bin/arm-linux-androideabi-gcc </del> CC_arm-linux-androideabi=$(CFG_ANDROID_CROSS_PATH)/bin/arm-linux-androideabi-gcc CXX_arm-linux-androideabi=$(CFG_ANDROID_CROSS_PATH)/bin/arm-linux-androideabi-g++ CPP_arm-linux-androideabi=$(CFG_ANDROID_CROSS_PATH)/bin/arm-linux-androideabi-gcc -E

# i686-apple-darwin configuration CC_i686-apple-darwin=$(CC) <del> LINK_i686-apple-darwin=cc </del> CXX_i686-apple-darwin=$(CXX) CPP_i686-apple-darwin=$(CPP) AR_i686-apple-darwin=$(AR)

# i686-unknown-linux-gnu configuration CC_i686-unknown-linux-gnu=$(CC) <del> LINK_i686-unknown-linux-gnu=cc </del> CXX_i686-unknown-linux-gnu=$(CXX) CPP_i686-unknown-linux-gnu=$(CPP) AR_i686-unknown-linux-gnu=$(AR)

# x86_64-apple-darwin configuration CC_x86_64-apple-darwin=$(CC) <del> LINK_x86_64-apple-darwin=cc </del> CXX_x86_64-apple-darwin=$(CXX) CPP_x86_64-apple-darwin=$(CPP) AR_x86_64-apple-darwin=$(AR)

# x86_64-pc-windows-gnu configuration CROSS_PREFIX_x86_64-pc-windows-gnu=x86_64-w64-mingw32- CC_x86_64-pc-windows-gnu=gcc <del> LINK_x86_64-pc-windows-gnu=gcc </del> CXX_x86_64-pc-windows-gnu=g++ CPP_x86_64-pc-windows-gnu=gcc -E AR_x86_64-pc-windows-gnu=ar

# x86_64-unknown-linux-gnu configuration CC_x86_64-unknown-linux-gnu=$(CC) <del> LINK_x86_64-unknown-linux-gnu=cc </del> CXX_x86_64-unknown-linux-gnu=$(CXX) CPP_x86_64-unknown-linux-gnu=$(CPP) AR_x86_64-unknown-linux-gnu=$(AR)

$(foreach target,$(CFG_TARGET),  $(eval $(call ADD_INSTALLED_OBJECTS,$(target)))) <ins> define DEFINE_LINKER ifndef LINK_$(1) LINK_$(1) := $$(CC_$(1)) endif endef $(foreach target,$(CFG_TARGET),  $(eval $(call DEFINE_LINKER,$(target)))) </ins> # The -Qunused-arguments sidesteps spurious warnings from clang define FILTER_FLAGS ifeq ($$(CFG_USING_CLANG),1)
Change:
In the method- file: The example (copied below) that immediately follows this does not actually contain code returning self. Instead, a new Circle struct is built and returned. The wording suggests that the next example is going to show how returning self can be done, but the example doesn't show that.

Discussion:
# Chaining method calls So, now we know how to call a method, such as `foo.bar()`. But what about our <del> original example, `foo.bar().baz()`? This is called ‘method chaining’, and we can do it by returning `self`. </del> <ins> original example, `foo.bar().baz()`? This is called ‘method chaining’. Let’s look at an example: </ins> ```rust struct Circle {
Change:
Neither the nightly Rust reference nor the book seem to mention the fact that one can use enum constructors in a function like way inside expressions, eg. . (unless I'm mistaken and it's there somewhere, but I didn't find it)
It's maybe obliquely mentioned at best.
IMO, this is two parts: that enum constructors are functions. that functions can be used where traits are. I don't know how much you need to go into every permutation of every feature in Rust ^_^

Discussion:
[match]: match.html [if-let]: if-let.html [traits]: traits.html <ins> # Constructors as functions An enum’s constructors can also be used like functions. For example: ```rust # enum Message { # Write(String), # } let m = Message::Write("Hello, world".to_string()); ``` Is the same as ```rust # enum Message { # Write(String), # } fn foo(x: String) -> Message { Message::Write(x) } let x = foo("Hello, world".to_string()); ``` This is not immediately useful to us, but when we get to [`closures`][closures], we’ll talk about passing functions as arguments to other functions. For example, with [`iterators`][iterators], we can do this to convert a vector of `String`s into a vector of `Message::Write`s: ```rust # enum Message { # Write(String), # } let v = vec!["Hello".to_string(), "World".to_string()]; let v1: Vec<Message> = v.into_iter().map(Message::Write).collect(); ``` [closures]: closures.html [iterators]: iterators.html </ins>
Change:
I'm running the example from the section in Rust Book. I noticed that when I embed the code into Python and execute it, the execution time does not depend on the counter size (initially set to 5 million in the book). Although the text suggests it should (we are comparing execution time in different languages after all). However, if I modify the code to return, say, the count in the spawned thread (and later do , the execution time starts depending on the number of iterations. This seems not to depend on the number of iterations: This seems to get slower with more iterations (as it should): Why is this so? Is this some sort of compiler optimisation that removes the loop execution altogether? Should the code in the book be updated?
I thought that was enough to kill the optimization, but I guess not. Yes, it should be updated. (I think you can get rid of the `` too...)

Discussion:
5_000_000.times do count += 1 end <ins> count </ins> end end <del> threads.each { |t| t.join } </del> <ins> threads.each do |t| puts "Thread finished with count=#{t.value}" end </ins> puts "done!" ```

fn process() { let handles: Vec<_> = (0..10).map(|_| { thread::spawn(|| { <del> let mut _x = 0; </del> <ins> let mut x = 0; </ins> for _ in (0..5_000_000) { <del> _x += 1 </del> <ins> x += 1 </ins> } <ins> x </ins> }) }).collect(); for h in handles { <del> h.join().ok().expect("Could not join a thread!"); </del> <ins> println!("Thread finished with count={}", h.join().map_err(|_| "Could not join a thread!").unwrap()); </ins> } <ins> println!("done!"); </ins> } ``` Some of this should look familiar from previous examples. We spin up ten threads, collecting them into a `handles` vector. Inside of each thread, we <del> loop five million times, and add one to `_x` each time. Why the underscore? Well, if we remove it and compile: ```bash $ cargo build Compiling embed v0.1.0 (file:///home/steve/src/embed) src/lib.rs:3:1: 16:2 warning: function is never used: `process`, #[warn(dead_code)] on by default src/lib.rs:3 fn process() { src/lib.rs:4     let handles: Vec<_> = (0..10).map(|_| { src/lib.rs:5         thread::spawn(|| { src/lib.rs:6             let mut x = 0; src/lib.rs:7             for _ in (0..5_000_000) { src/lib.rs:8                 x += 1 ... src/lib.rs:6:17: 6:22 warning: variable `x` is assigned to, but never used, #[warn(unused_variables)] on by default src/lib.rs:6             let mut x = 0; ^~~~~ ``` That first warning is because we are building a library. If we had a test for this function, the warning would go away. But for now, it’s never called. The second is related to `x` versus `_x`. Because we never actually _do_ anything with `x`, we get a warning about it. In our case, that’s perfectly okay, as we’re just trying to waste CPU cycles. Prefixing `x` with the underscore removes the warning. Finally, we join on each thread. </del> <ins> loop five million times, and add one to `x` each time. Finally, we join on each thread. </ins> Right now, however, this is a Rust library, and it doesn’t expose anything that’s callable from C. If we tried to hook this up to another language right
Change:
As a new rust user I have struggled with a little problem: The ownership and borrowing rules are well explained in the docs but the copy trait and the types that implement them are not! In the doc primitive types are not listed as copy trait implementors. They should at least be mentioned there. It would be good to also add a little more info here: Maybe give some examples like in my question on stackoverflow: This is very important since it is an exception to the most important rule of the language Let me know if I have to make a pull request with a "change proposal" :)
Triage: no real change.
This .
points out that is not
This just confused me for the stable-soon never type, where I think it's likely that even experienced rustaceans would be wondering about implemented traits.
PR is working on it
Is it me, or do the docs still not mention the trait in (e.g.) and ?
Rust has a release cadence of 6 weeks. That commit was merged on Apr 4, starting on the nightly release. Rust 1.26 stable was released on Thu May 10 2018 and this was promoted to beta. . Rust 1.27 stable will be released on Thu Jun 21 2018, at which time this will show up in those docs.

Discussion:
But, unlike a move, we can still use `v` afterward. This is because an `i32` has no pointers to data somewhere else, copying it is a full copy. <ins> All primitive types implement the `Copy` trait and their ownership is therefore not moved like one would assume, following the ´ownership rules´. To give an example, the two following snippets of code only compile because the `i32` and `bool` types implement the `Copy` trait. ```rust fn main() { let a = 5; let _y = double(a); println!("{}", a); } fn double(x: i32) -> i32 { x * 2 } ``` ```rust fn main() { let a = true; let _y = change_truth(a); println!("{}", a); } fn change_truth(x: bool) -> bool { !x } ``` If we would have used types that do not implement the `Copy` trait, we would have gotten a compile error because we tried to use a moved value. ```text error: use of moved value: `a` println!("{}", a); ^ ``` </ins> We will discuss how to make your own types `Copy` in the [traits][traits] section.
Change:
All other examples say clearly, and when i read it, it seemed like the expanded version was legal, even though the output lifetime is unclear, which sounded a lot like the kind of "undefined behavior" rust wants to avoid, and that made me feel very uncomfortable. If this is actually illegal, it would be nice to say it explicitly.
I’d actually replace “unclear” with “ambiguous”.

Discussion:
fn get_str() -> &str; // ILLEGAL, no inputs fn frob(s: &str, t: &str) -> &str; // ILLEGAL, two inputs <del> fn frob<'a, 'b>(s: &'a str, t: &'b str) -> &str; // Expanded: Output lifetime is unclear </del> <ins> fn frob<'a, 'b>(s: &'a str, t: &'b str) -> &str; // Expanded: Output lifetime is ambiguous </ins> fn get_mut(&mut self) -> &mut T; // elided fn get_mut<'a>(&'a mut self) -> &'a mut T; // expanded
Change:
Works fine when not used as a attribute to be expanded by the macro system: Backtrace:
can confirm this happens on

Discussion:
tts: vec![TtToken(sp, token::Ident(token::str_to_ident("doc"), token::Plain)), TtToken(sp, token::Eq), <del> TtToken(sp, token::Literal(token::Str_(name), None))], </del> <ins> TtToken(sp, token::Literal(token::StrRaw(name, 0), None))], </ins> close_span: sp, })) }

<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. // When expanding a macro, documentation attributes (including documentation comments) must be // passed "as is" without being parsed. Otherwise, some text will be incorrectly interpreted as // escape sequences, leading to an ICE. // // Related issues: #25929, #25943 macro_rules! homura { (#[$x:meta]) => () } homura! { /// madoka x41 } fn main() { } </ins>
Change:
When using multiline string literal in doctest, rustdoc pads spaces after the newline. The doc renders perfectly fine: ! I tried this code: //! Hello world. //! //! # Examples //! //! //! //! fn main() { println!("hello world!"); } I expected to see this happen: The test should pass. Instead, this happened: The test failed. Did you notice it? : : Backtrace (I don't know if it'd be useful, but):
I hit this issue today as well with a similar case
Triaging: This is still happening on

Discussion:
let s = "foo bar"; <del> assert_eq!("foon        bar", s); </del> <ins> assert_eq!("foon    bar", s); </ins> ``` The second, with a ``, trims the spaces and the newline:

prog.push_str(&everything_else); } else { prog.push_str("fn main() {n    "); <del> prog.push_str(&everything_else.replace("n", "n    ")); </del> <ins> prog.push_str(&everything_else); </ins> prog = prog.trim().into(); prog.push_str("n}"); }

<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. // compile-flags:--test /// ``` /// let a = r#" /// foo /// bar"#; /// let b = "nfoonbar"; /// assert_eq!(a, b); /// ``` pub fn main() { } </ins>
Change:
The console reports this error: This is in question. I recognize that I'm using a beta browser version, and that the team may not wish to support these browsers. However, it's easy for me to report it, just in case it becomes a problem with the next released version! Chrome Version 45.0.2454.85 (64-bit) OS X -
It's broken for me, too. I'm using Chrome 45.0.2454.85 (not Chrome canary). Also Mac OSX and .

Discussion:
} function browserSupportsHistoryApi() { <del> return window.history && typeof window.history.pushState === "function"; </del> <ins> return document.location.protocol != "file:" && window.history && typeof window.history.pushState === "function"; </ins> } function highlightSourceLines(ev) {