jiebi/CodeConvo huggingface dataset:
Change:
Results in a crash (after a perfectly reasonable error message): This was tested with rustc 0.1. Building from HEAD on nyus now to try to get a more helpful backtrace and to verify that it hasn't since been fixed.
Here's a more helpful backtrace. Repros at .
Looks exactly like to me.

Discussion:
<del> Subproject commit 2751bdcef125468ea2ee006c11992cd1405aebe5 </del> <ins> Subproject commit 34fca48ed284525b2f124bf93c51af36d6685492 </ins>

<del> Subproject commit 388750b081c0893c275044d37203f97709e058ba </del> <ins> Subproject commit e3f3af69dce71cd37a785bccb7e58449197d940c </ins>

<del> Subproject commit d43038932adeb16ada80e206d4c073d851298101 </del> <ins> Subproject commit ee7c676fd6e287459cb407337652412c990686c0 </ins>

<del> Subproject commit 07e0df2f006e59d171c6bf3cafa9d61dbeb520d8 </del> <ins> Subproject commit c954202c1e1720cba5628f99543cc01188c7d6fc </ins>

<del> Subproject commit b123ab4754127d822ffb38349ce0fbf561f1b2fd </del> <ins> Subproject commit 08bb147d51e815b96e8db7ba4cf870f201c11ff8 </ins>
Change:
Currently, statements like "ret none;" don't work because the typechecker isn't smart enough to infer the type parameter from the explicit function signature.
WONTFIX (not required for bootstrapping, should work in rustc already; reopen if not)

Discussion:
rustup toolchain install --profile minimal nightly-${TOOLCHAIN} # Sanity check to see if the nightly exists echo nightly-${TOOLCHAIN} > rust-toolchain <del> echo "=> Uninstalling all old nighlies" </del> <ins> echo "=> Uninstalling all old nightlies" </ins> for nightly in $(rustup toolchain list | grep nightly | grep -v $TOOLCHAIN | grep -v nightly-x86_64); do rustup toolchain uninstall $nightly done
Change:
This causes them to be restricted to 2GB of address space, even though on 64-bit Windows they could have gotten full 4GB, had they been marked appropriately.

Discussion:
// Mark all dynamic libraries and executables as compatible with ASLR cmd.arg("-Wl,--dynamicbase"); <ins> // Mark all dynamic libraries and executables as compatible with the larger 4GiB address // space available to x86 Windows binaries on x86_64. if sess.targ_cfg.arch == abi::X86 { cmd.arg("-Wl,--large-address-aware"); } </ins> } if sess.targ_cfg.os == abi::OsAndroid {
Change:
According to std::rt::min_stack(), the minimum Rust stack size is 2MB. Given that the default stack size on Windows is 1MB, and that is generally plenty for any program I've seen, this seems a bit excessive. This, btw, contributes to doctest failure of "futures" example from guide- on Windows: this example spawns 1000 threads, and in conjunction with , this results in it running out of memory.
The Rust compiler uses a 6MiB stack and then increase than to 20MiB (!!!) when optimizations are disabled. The default stack size on Linux is 8MiB, so that's likely how much is available for the main thread. Rust tends to need a ridiculous amount of stack space, especially without optimizations.
If this is indeed the intended value, at least the test should be adjusted, because right now it's guaranteed to fail on a 32-bit Windows machine, even if the large-address-aware flag were fixed.

Discussion:
} fn main() { <del> let mut futures = Vec::from_fn(1000, |ind| Future::spawn( proc() { partial_sum(ind) })); </del> <ins> let mut futures = Vec::from_fn(200, |ind| Future::spawn( proc() { partial_sum(ind) })); </ins> let mut final_res = 0f64; for ft in futures.mut_iter()  {
Change:
It's currently but the convention is (and it is more readable) to have the closure last, i.e. .

Discussion:
/// Creates a new iterator that produces an infinite sequence of /// repeated applications of the given function `f`. #[allow(visible_private_types)] <del> pub fn iterate<'a, T: Clone>(f: |T|: 'a -> T, seed: T) -> Iterate<'a, T> { </del> <ins> pub fn iterate<'a, T: Clone>(seed: T, f: |T|: 'a -> T) -> Iterate<'a, T> { </ins> Unfold::new((f, Some(seed), true), |st| { let &(ref mut f, ref mut val, ref mut first) = st; if *first {

#[test] fn test_iterate() { <del> let mut it = iterate(|x| x * 2, 1u); </del> <ins> let mut it = iterate(1u, |x| x * 2); </ins> assert_eq!(it.next(), Some(1u)); assert_eq!(it.next(), Some(2u)); assert_eq!(it.next(), Some(4u));
Change:
alt (...) { case (none) { ... } } doesn't work because the compiler don't know what kind of "none" it is. This could be inferred from the discriminant.
WONTFIX (not required for bootstrapping; works in rustc automatically, I hope; re-open if not)

Discussion:
rustup toolchain install --profile minimal nightly-${TOOLCHAIN} # Sanity check to see if the nightly exists echo nightly-${TOOLCHAIN} > rust-toolchain <del> echo "=> Uninstalling all old nighlies" </del> <ins> echo "=> Uninstalling all old nightlies" </ins> for nightly in $(rustup toolchain list | grep nightly | grep -v $TOOLCHAIN | grep -v nightly-x86_64); do rustup toolchain uninstall $nightly done
Change:
broke iOS build. It happened because a new branch was started over instead of . While the new branch has all the required features, they are disabled because script is bundled. So either should be removed completely and constructed by during build process as usually or it should be regenerated and checked in on the every update. The latter perhaps requires a guide for contributors so they to be aware of the issue.
cc
What precisely is broken? Can iOS just not build? Why? Also, what do you mean by the May 8 and June 5 dates? We currently don't have a dependence on autotools, and there are certainly many of us that'd like to keep it that way! Do we just need to check in a new script?
fails to build as old script from doesn't contain support for iOS. Sorry for not being clear enough, those are names of snapshot branches Yep, that should be enough
If you'd like, it's ok to disable jemalloc by default for ios (for rust). Otherwise this is why we prefer to upstream changes before including them in our own repos (for example ).
The fun thing is that actually changes are upstreamed in . But upstream doesn't contain , this file is presented only in Rust repo and therefore it is fragile on updates - rebase on wrong branch and it may be invalid, this very case.
Aha! Well in that case, feel free to submit an updated configure script!
Will do. My point for creating this issue is increasing awareness of problem for future updates
I regenerated the script with autoconf when I made that branch and it does contain the case in the case statement.
Guys, I terribly sorry and apologize, but it is my fault in the end - it seems that iOS was deleted from upstream, from file which caused invalid file to be generated. Looks like a mistake as iOS was deleted in commit related to OpenRISC cleanup. I've sent a new PR to and will update once it lands. Apologies again.

Discussion:
<del> Subproject commit aae04170ccbfeea620502106b581c3c216cd132a </del> <ins> Subproject commit 2dba541881fb8e35246d653bbe2e7c7088777a4a </ins>
Change:
compiles fine (other than the dead code warning for ), but is not:
I hit this as well, I would love a fix :+1:

Discussion:
} ExprCall(ref callee, _) => { match v.tcx.def_map.borrow().find(&callee.id) { <del> Some(&DefStruct(..)) => {}    // OK. </del> <ins> Some(&DefStruct(..)) | </ins> Some(&DefVariant(..)) => {}    // OK. _ => { span_err!(v.tcx.sess, e.span, E0015,

DefStatic(..) => cx.tcx.sess.span_bug(pat_span, "static pattern should've been rewritten"), DefVariant(_, id, _) if *constructor != Variant(id) => None, <del> DefVariant(..) | DefFn(..) | DefStruct(..) => { </del> <ins> DefVariant(..) | DefStruct(..) => { </ins> Some(match args { &Some(ref args) => args.iter().map(|p| &**p).collect(), &None => Vec::from_elem(arity, &DUMMY_WILD_PAT)

if_ok!(self.cat_pattern(subcmt, &**subpat, |x,y,z| op(x,y,z))); } } <del> Some(&def::DefFn(..)) | </del> Some(&def::DefStruct(..)) => { for (i, subpat) in subpats.iter().enumerate() { let subpat_ty = if_ok!(self.pat_ty(&**subpat)); // see (*2)

maybe_did.unwrap_or(did) }) } <del> // Tuple struct constructors across crates are identified as // DefFn types, so we explicitly handle that case here. Some(&def::DefFn(did, _, _)) if !is_local(did) => { match csearch::get_tuple_struct_definition_if_ctor( &self.tcx.sess.cstore, did) { Some(did) => guard(did), None => {} } } </del> _ => {} } }

child_name_bindings.define_value(def, DUMMY_SP, is_exported); } } <ins> DefFn(ctor_id, _, true) => { child_name_bindings.define_value( csearch::get_tuple_struct_definition_if_ctor(&self.session.cstore, ctor_id) .map_or(def, |_| DefStruct(ctor_id)), DUMMY_SP, is_public); } </ins> DefFn(..) | DefStaticMethod(..) | DefStatic(..) => { debug!("(building reduced graph for external  crate) building value (fn/static) {}", final_ident);

} ast::PatEnum(..) | ast::PatIdent(_, _, None) => { match tcx.def_map.borrow().find(&pat.id) { <del> Some(&def::DefFn(..)) | </del> Some(&def::DefStruct(..)) => true, _ => false }

} } } <del> Some(def::DefFn(..)) | </del> Some(def::DefStruct(..)) => { match *sub_pats { None => {

Argument(Struct) } <ins> pub struct TupleStruct(pub uint, pub &'static str); </ins> // used by the cfail test pub struct StructWithFields {

static s3: xcrate_unit_struct::Unit = xcrate_unit_struct::Argument(xcrate_unit_struct::Struct); static s4: xcrate_unit_struct::Unit = xcrate_unit_struct::Argument(s1); <ins> static s5: xcrate_unit_struct::TupleStruct = xcrate_unit_struct::TupleStruct(20, "foo"); </ins> fn f1(_: xcrate_unit_struct::Struct) {} fn f2(_: xcrate_unit_struct::Unit) {} <ins> fn f3(_: xcrate_unit_struct::TupleStruct) {} </ins> pub fn main() { f1(xcrate_unit_struct::Struct); f2(xcrate_unit_struct::UnitVariant); f2(xcrate_unit_struct::Argument(xcrate_unit_struct::Struct)); <ins> f3(xcrate_unit_struct::TupleStruct(10, "bar")); </ins> f1(s1); f2(s2); f2(s3); f2(s4); <ins> f3(s5); </ins> }
Change:
Same error, with the last github version.
Also getting this, I'm running the Yosemite GM 1. Not sure if it's related.
I also getting this on MacOs
Still getting this make error, like many others did. Anyone want to fix this?
I have no idea how to fix this, other than just installing xetex or however it's spelled
The configure(or make) did find LuaTeX.
Sadly I don't have time to work on this right now. A simple fix would be to disable pdf generation unless specified in configure, or to require xetex.
I don't think that LaTeX should be a dependency to build a programming language like Rust.
it seems reasonable to have the option to not build PDF docs if you don't want to
I think I'm getting the same error, which is strange because I believe I was able to a couple days ago. In the log, the complaint is that is not found. As suggested above, is included with MacPorts' package and installing that allowed compilation of docs to go through.
will build without building the PDF docs

Discussion:
probe CFG_FLEX             flex probe CFG_BISON            bison probe CFG_PANDOC           pandoc <del> probe CFG_PDFLATEX         pdflatex </del> probe CFG_XELATEX          xelatex <del> probe CFG_LUALATEX         lualatex </del> probe CFG_GDB              gdb probe CFG_LLDB             lldb

HTML_DEPS := endif <del> # Check for the various external utilities for the EPUB/PDF docs: ifeq ($(CFG_LUALATEX),) $(info cfg: no lualatex found, deferring to xelatex) ifeq ($(CFG_XELATEX),) $(info cfg: no xelatex found, deferring to pdflatex) ifeq ($(CFG_PDFLATEX),) $(info cfg: no pdflatex found, disabling LaTeX docs) NO_PDF_DOCS = 1 else CFG_LATEX := $(CFG_PDFLATEX) endif else </del> <ins> # Check for xelatex ifeq ($(CFG_XELATEX),) </ins> CFG_LATEX := $(CFG_XELATEX) XELATEX = 1 <del> endif else CFG_LATEX := $(CFG_LUALATEX) </del> <ins> else $(info cfg: no xelatex found, disabling LaTeX docs) NO_PDF_DOCS = 1 </ins> endif ifeq ($(CFG_PANDOC),) $(info cfg: no pandoc found, omitting PDF and EPUB docs) ONLY_HTML_DOCS = 1
Change:
This is a minor issue but I'd suggest not using "here" as the link text for the standard library docs on the . Having informative link text makes the link easier to find and is generally considered . Maybe just link on "standard library" and drop the word "here"? i.e.:
and add the crate name ?

Discussion:
the iterator, and we loop another time. When there are no more values, the `for` loop is over. <del> In our example, the `range` function is a function, provided by Rust, that takes a start and an end position, and gives an iterator over those values. The upper bound is exclusive, though, so our loop will print `0` through `9`, not `10`. </del> <ins> In our example, `range` is a function that takes a start and an end position, and gives an iterator over those values. The upper bound is exclusive, though, so our loop will print `0` through `9`, not `10`. </ins> Rust does not have the "C style" `for` loop on purpose. Manually controlling each element of the loop is complicated and error prone, even for experienced C
Change:
Section 11.1 on for loops unusually begins by showing C syntax, saying "Rust's for loop doesn't look like this C for loop:" In my opinion that is a strange way to introduce Rust's for loops. Furthermore the C code is not clearly indicated to be in another language, so someone casually perusing the documentation may not notice that it is from another language. Lastly, the C code has a link to the rust play pen, which obviously results in a syntax error if you try to run it: <anon:2:12: 2:13 error: expected , found <anon:2 for (x = 0; x < 10; x++) { I think it would be better to introduce Rust's notation first, and then perhaps make a passing remark that this is different to some languages (such as C) - though it is also similar to other languages, such as Python.
:+1:
I called it a "C for loop" because even in JavaScript, Ruby, and Python, they also tend to call this notation a "C-style for loop." That said, the playpen link is certainly bad.
Being a C++ developer, it is easier for me understand what happens when the C version is presented first and then compared to how Rust does it...

Discussion:
the iterator, and we loop another time. When there are no more values, the `for` loop is over. <del> In our example, the `range` function is a function, provided by Rust, that takes a start and an end position, and gives an iterator over those values. The upper bound is exclusive, though, so our loop will print `0` through `9`, not `10`. </del> <ins> In our example, `range` is a function that takes a start and an end position, and gives an iterator over those values. The upper bound is exclusive, though, so our loop will print `0` through `9`, not `10`. </ins> Rust does not have the "C style" `for` loop on purpose. Manually controlling each element of the loop is complicated and error prone, even for experienced C
Change:
Section 5, Variable bindings, mentions "Well, Rust has this thing called "Hindley-Milner type inference", named after some really smart type theorists." This is a minor nitpick, but I cringed when I read that sentence. There are lots of features in Rust that are the result of work by smart people. There is no need to single out the Hindley-Milner algorithm. Also the follow on text seems a bit patronising "If you clicked that link, don't be scared:" Writing like that tends to perpetuate the idea that type inference is deep magic, when it is not. I expect many people reading the Rust guide will be familiar with type inference, even the HM algorithm. It is fine to link to the Wikipedia article, but I think the Guide should not imply that it is a difficult topic or something which is scary.
I very strongly disagree with this, but do agree that I don't have the right tone here. !
I'd call this fallacy "Appeal to unfamiliar notation."
If stylistic concerns are not compelling, there is a good technical one: Rust no longer uses H-M type inference. See and that mentions abandoning H-M.
Oh, I mean, I do think that style arguments are. Didn't mean to imply otherwise. But I also forgot that we switched, so thanks for the reminder.=
Rust also never really used H-M.

Discussion:
the iterator, and we loop another time. When there are no more values, the `for` loop is over. <del> In our example, the `range` function is a function, provided by Rust, that takes a start and an end position, and gives an iterator over those values. The upper bound is exclusive, though, so our loop will print `0` through `9`, not `10`. </del> <ins> In our example, `range` is a function that takes a start and an end position, and gives an iterator over those values. The upper bound is exclusive, though, so our loop will print `0` through `9`, not `10`. </ins> Rust does not have the "C style" `for` loop on purpose. Manually controlling each element of the loop is complicated and error prone, even for experienced C
Change:
Section 11.1, for loops says "In our example, the range function is a function, provided by Rust, " The repetition of the word "function" is awkward. The "provided by Rust" is redundant. I suggest re-wording to: "The range function takes a start and end position, and returns an iterator over those values."

Discussion:
the iterator, and we loop another time. When there are no more values, the `for` loop is over. <del> In our example, the `range` function is a function, provided by Rust, that takes a start and an end position, and gives an iterator over those values. The upper bound is exclusive, though, so our loop will print `0` through `9`, not `10`. </del> <ins> In our example, `range` is a function that takes a start and an end position, and gives an iterator over those values. The upper bound is exclusive, though, so our loop will print `0` through `9`, not `10`. </ins> Rust does not have the "C style" `for` loop on purpose. Manually controlling each element of the loop is complicated and error prone, even for experienced C
Change:
Under section 1, the link to the Windows binary is which gives a 404 error page. !
(The problem here is we now have both 32 and 64-bit installers, and thus the URL was split to reflect this. has the correct links, I guess the guide should either link to that page, or have both links.)

Discussion:
below.) If you're on Windows, please download either the [32-bit <del> installer](https://static.rust-lang.org/dist/rust-nightly-i686-pc-mingw32.exe) </del> <ins> installer](https://static.rust-lang.org/dist/rust-nightly-i686-w64-mingw32.exe) </ins> or the [64-bit installer](https://static.rust-lang.org/dist/rust-nightly-x86_64-w64-mingw32.exe) and run it.
Change:
Happens on WIndows 7 x64 with latest Rust 32-bit nightly. : (On a side note, is there any way to work out what the latest released nightly version is?) : Compiling with produces: is there to suppress the warning, can be removed if you compile the rest as a library. Also works if you substitute the expression for directly and if you pass two arguments (the original use case). The original intent was to tell if two s were identical as a sanity check.
Can confirm this still results in an ICE.
Triage: still ICEs.
cc rust-lang/rfcs
fixed this.
I'll add a regression test for this

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. #[allow(dead_code)] fn check(a: &str) { let x = a as *const str; x == x; } fn main() {} </ins>
Change:
While trying 'make check' on the latest revision (id mentioned in attachments), I get a bunch of failures in gdb debuginfo tests. Along with this, I see that 'make check' itself errors out and does not continue further. Here is how the system info looks: Also, the last few lines of output from the problem described above: I mentioned this issue in #rust last evening and was advised to file it as an issue. Please let me know if I can help resolve this issue by providing more information or trying a different setting/config.
This looks like a locale-related issue, given: vs. the expected (, vs . for floating point values).
cc
Yes, I've had that issue too and changing the systemwide number format fixed it. But we should see if we can't make our test suite independent of the system's locale... Thanks for the detailed bug report!
If this is the kind of bug that a newbie can handle, I'll try to fix it. I started with rust just some minutes ago and am going through the guide at the moment. On 21-09-14 20:30, Michael Woerister wrote:
Sure, if you want to give it a try, just go ahead. If you need any help you can post questions right here.
Here's my first attempt at solving this (works fine for me): However, I am not sure if this is a good way to do it. I'll eagerly wait for you folks to review it and see what could be improved (if needed).
:+1:

Discussion:
# If we're running perf then set this environment variable # to put the benchmarks into 'hard mode' ifeq ($(MAKECMDGOALS),perf) <del> RUST_BENCH=1 export RUST_BENCH </del> <ins> export RUST_BENCH=1 </ins> endif TEST_LOG_FILE=tmp/check-stage$(1)-T-$(2)-H-$(3)-$(4).log
Change:
The following program causes rustc to crash: Obviously it's badly typed (converting void to a pointer type), but the compiler shouldn't crash here right? :) output of rustc -v: rustc 0.12.0-pre-nightly ( 2014-09-11 00:05:41 +0000) backtrace from trying to compile; Let me know if you need more information.
Yes, any ICE is bad. Thanks!
Simpler: Works with every C-like enum.
I'll try to fix this one together with
Fixed in

Discussion:
(expr::cast_integral, expr::cast_pointer) => { llvm::LLVMConstIntToPtr(v, llty.to_ref()) } <ins> (expr::cast_pointer, expr::cast_integral) => { llvm::LLVMConstPtrToInt(v, llty.to_ref()) } </ins> _ => { cx.sess().impossible_case(e.span, "bad combination of types for cast")

// casts to scalars other than `char` and `bare fn` are trivial let t_1_is_trivial = t_1_is_scalar && !t_1_is_char && !t_1_is_bare_fn; if ty::type_is_c_like_enum(fcx.tcx(), t_e) && t_1_is_trivial { <del> if t_1_is_float { </del> <ins> if t_1_is_float || ty::type_is_unsafe_ptr(t_1) { </ins> fcx.type_error_message(span, |actual| { format!("illegal cast; cast through an  integer first: `{}` as `{}`",

<ins> // Copyright 2014 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 Test { Foo = 0 } fn main() { let _x = Foo as *const int; //~^ ERROR illegal cast; cast through an integer first: `Test` as `*const int` } </ins>

<ins> // Copyright 2014 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. static X: uint = 0 as *const uint as uint; fn main() { assert_eq!(X, 0); } </ins>