jiebi/CodeConvo huggingface dataset:
Change:
I'm trying to upgrade code that worked in 0.10/0.11-pre (implementation of ): I've found a method that sounds like what I need, but it's undocumented: Linked Arguments documentation suggests usnig : but the usage I'd expect: fails with "format argument must be a string literal.", which left me lost. If really supports only literals as arguments then it's totally useless, but if I'm doing something wrong, then the docs/compiler don't help me figure this out.
The docs are not up to date. I think this should work for you: doesn't need to be escaped anymore, and you can use directly on the formatter. It should have been documented at but it has not quite been updated. *Updated to not ignore the return value. has a return value -- you can return it from the method.
That works, thanks! Shall I leave the issue open as a reminder to update the docs?
Errors from the formatter should be propagated upstream instead of being ignored.
yes, please leave it open, i will tag it 'docs'
I just opened a PR to remove that faulty paragraph.
The docs are up-to-date, it's just passes the created structure into a closure/function passed as the first argument. .

Discussion:
/// to prevent modification. /// /// The `format_args!` macro will safely create an instance of this structure <del> /// and pass it to a user-supplied function. The macro validates the format /// string at compile-time so usage of the `write` and `format` functions can /// be safely performed. </del> <ins> /// and pass it to a function or closure, passed as the first argument. The /// macro validates the format string at compile-time so usage of the `write` /// and `format` functions can be safely performed. </ins> pub struct Arguments<'a> { fmt: &'a [rt::Piece<'a>], args: &'a [Argument<'a>],
Change:
Example: This should be fixed by code in .
Nominating for 1.0, P-backcompat-lang.
Assigning 1.0, P-backcompat-lang

Discussion:
//! } //! //! // This function wants to log its parameter out prior to doing work with it. <del> //! fn do_work<T: Show>(value: &T) { </del> <ins> //! fn do_work<T: Show+'static>(value: &T) { </ins> //!     log(value); //!     // ...do some other work //! }

fn check_bounds_on_type_parameters(cx: &mut Context, e: &Expr) { let method_map = cx.tcx.method_map.borrow(); <del> let method = method_map.find(&typeck::MethodCall::expr(e.id)); </del> <ins> let method_call = typeck::MethodCall::expr(e.id); let method = method_map.find(&method_call); </ins> // Find the values that were provided (if any) let item_substs = cx.tcx.item_substs.borrow();

type_param_def.space, type_param_def.index, ty.repr(cx.tcx)); check_typaram_bounds(cx, e.span, ty, type_param_def) } <ins> // Check the vtable. let vtable_map = cx.tcx.vtable_map.borrow(); let vtable_res = match vtable_map.find(&method_call) { None => return, Some(vtable_res) => vtable_res, }; check_type_parameter_bounds_in_vtable_result(cx, e.span, vtable_res); </ins> } fn check_type_parameter_bounds_in_vtable_result(

<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. trait Foo { } impl<T:Copy> Foo for T { } fn take_param<T:Foo>(foo: &T) { } fn main() { let x = box 3i; take_param(&x); //~^ ERROR instantiating a type parameter with an incompatible type } </ins>
Change:
I was able to perform the commands above successfully with both fish and bash fish bash
I am able to as well. Closing! Thanks for the triage.
Hm I'm actually quite surprised that this works. What versions of the compilers were you using? For me it continues to not work:
Oh this may be a shell thing (I'm using zsh), when running after executing the commands in bash I see: I think that the escape syntax for bash must be different.
I just tried zsh and got your error:
Reproducable in bash (note the ).
It now fails saying, "called on an value". I believe this is simply due to using rather than , so it panics on the non-utf8. You can reproduce this with any bad argument at all, e.g. in bash: Accepting will require changes down through the crate, and I guess all the other users of that should be updated too. I'm interested to try, if this sounds ok...

Discussion:
Registry::new(&all_errors) } <ins> fn get_args() -> Vec<String> { env::args_os().enumerate() .map(|(i, arg)| arg.into_string().unwrap_or_else(|arg| { early_error(ErrorOutputType::default(), &format!("Argument {} is not valid Unicode: {:?}", i, arg)) })) .collect() } </ins> pub fn main() { env_logger::init().unwrap(); <del> let result = run(|| run_compiler(&env::args().collect::<Vec<_>>(), </del> <ins> let result = run(|| run_compiler(&get_args(), </ins> &mut RustcDefaultCalls, None, None));

const STACK_SIZE: usize = 32_000_000; // 32MB env_logger::init().unwrap(); let res = std::thread::Builder::new().stack_size(STACK_SIZE).spawn(move || { <del> let s = env::args().collect::<Vec<_>>(); main_args(&s) </del> <ins> get_args().map(|args| main_args(&args)).unwrap_or(1) </ins> }).unwrap().join().unwrap_or(101); process::exit(res as i32); } <ins> fn get_args() -> Option<Vec<String>> { env::args_os().enumerate() .map(|(i, arg)| arg.into_string().map_err(|arg| { print_error(format!("Argument {} is not valid Unicode: {:?}", i, arg)); }).ok()) .collect() } </ins> fn stable(g: getopts::OptGroup) -> RustcOptGroup { RustcOptGroup::stable(g) } fn unstable(g: getopts::OptGroup) -> RustcOptGroup { RustcOptGroup::unstable(g) }
Change:
cc This part is somewhat confusing: My suggestion is: either mention that samples the whole range of int and you use modulo to narrow the range. Or use the function. This way you also don't get modulo bias.
cc (If you want to mention someone, use )
Done, thanks.
I pulled this up in the original review: As you can see the modulo bias is miniscule (even on 32-bit platforms it is only billionths).
The introduction of modulo bias is not the main issue. The issue is that I, as a newbie, got confused by the %100 trick, so maybe it needs some more explanation.
I agree. should also be the recommended way to generate a random number in a range. If it will be expanded on later in the guide, that's fine, but then some more explanation here could be nice. If you surround your code with backticks, like then you'll get code sytax

Discussion:
This operator is called 'modulo', and it returns the remainder of a division. By taking the modulo of the result of `rand::random()`, we're limiting the values to be between 0 and 99. Then, we add one to the result, making it from 1 <del> to 100. </del> <ins> to 100. Using modulo can give you a very, very small bias in the result, but for this example, it is not important. </ins> Let's try to compile this using `cargo build`:
Change:
In , the type is referred to as an array and is done as an slice. A in the RFC also refers to as an array, as a slice and as a vector. However, and don't conform to it. I think it is a problem.
The documentation at I find particularly hard to follow.

Discussion:
assert!(b != "world"); ~~~~ <del> ### Vector types </del> <ins> ### Vector, Array, and Slice types </ins> <del> The vector type constructor represents a homogeneous array of values of a given type. A vector has a fixed size. (Operations like `vec.push` operate solely on owned vectors.) A vector type can be annotated with a _definite_ size, such as `[int, ..10]`. Such a definite-sized vector type is a first-class type, since its size is known statically. A vector without such a size is said to be of _indefinite_ size, and is therefore not a _first-class_ type. An indefinite-size vector can only be instantiated through a pointer type, such as `&[T]` or `Vec<T>`. The kind of a vector type depends on the kind of its element type, as with other simple structural types. </del> <ins> Rust has three different types for a list of items: </ins> <del> Expressions producing vectors of definite size cannot be evaluated in a context expecting a vector of indefinite size; one must copy the definite-sized vector contents into a distinct vector of indefinite size. </del> <ins> * `Vec<T>`, a 'vector' * `[T ..N]`, an 'array' * `&[T]`, a 'slice'. </ins> <del> An example of a vector type and its use: </del> <ins> A vector is a heap-allocated list of `T`. A vector has ownership over the data inside of it. It is also able to grow and change in size. It's important to note that `Vec<T>` is a library type, it's not actually part of the core language. </ins> <del> ~~~~ let v: &[int] = &[7, 5, 3]; let i: int = v[2]; assert!(i == 3); ~~~~ </del> <ins> An array has a fixed size, and can be allocated on either the stack or the heap. A slice is a 'view' into a vector or array. It doesn't own the data it points to, it borrows it. An example of each kind: ```{rust} let vec: Vec<int>  = vec![1, 2, 3]; let arr: [int, ..3] = [1, 2, 3]; let s: &[int]      = vec.as_slice(); ``` As you can see, the `vec!` macro allows you to create a `Vec<T>` easily. The `vec!` macro is also part of the standard library, rather than the language. </ins> <del> All in-bounds elements of a vector are always initialized, and access to a vector is always bounds-checked. </del> <ins> All in-bounds elements of vectors, arrays, and slices are always initialized, and access to a vector, array, or slice is always bounds-checked. </ins> ### Structure types
Change:
The back-edge check to prevent infinitely nested tag types rejects some valid programs, namely those that look like this: The order of the tag declarations must be switched. Instead of comparing opaque IDs, we could instead do the following: In the Semant context, store a well-ordering on every tag type. Every time a type /a/ is contained in a type /b/ without boxing, we declare that /a/ < /b/. Then boxed back-pointers from /b/ to /a/ result in opaque types. Any contradiction (declaring that /b/ < /a/ when /a/ < /b/ is already established) results in an error, because a type would have infinite size.
Thank you so much for figuring this out, Patrick. I was pretty frustrated that I couldn't make sense of the problem before, and you cut to the heart of it. Some clarification that at least helps me: there's a very concrete reason why the ordering and the restriction are necessary. It's not that the type has unbounded size (all trees have unbounded size), nor even that it has infinite size. For example, with the type: could still have finite size. CONS(1, CONS(2, CONS(3, NIL()))) is perfectly finite. But the problem is that it doesn't have /statically predictable size/, which is one of the key aspects of the Rust design. As another example: in a sense, there's nothing inherently worse about the type: compared to the type: Both of them are impossible to instantiate, so neither really threatens any kind of safety properties. But the first type has statically unpredictable size, whereas the second has a static size that can be inductively computed, thanks to the ordering you describe. So in summary: by imposing a well-ordering on these potentially cyclic types, we recover an inductively defined, static sizeof operation.
Fixed in commit .

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:
loops allow moving out of fixed size arrays. This code compiles and should not compile. segfault with channels I don't know how to make this test case smaller, but... This commit introduces a segfault. Seems bad.
From what I'm seeing here(debugger wise) the problem looks to stem from the call to in the function. Inside we enter the loop, make it through the first unsafe match and then the problem appears to occur in the branch when we try to match again.
Can you describe the system that you're running on as well as the cargo/rustc versions you're using? I've been unable to reproduce the segfault on the most recent nightly on both linux and osx.
Oh sorry, I'm running Windows here. Latest installer version. After restarting into Xubuntu and updating I recompiled there and got a segfault. I get rust from the hansjorg/rust PPA. I'm running off of a Toshiba Satellite L875D-S7210 with an AMD A6-4400M APU. Windows is 64bit and Xubuntu is 32bit.
Ah, found it. Nominating and cc this seems bad and related to the recent removal of for-loop desugaring.
Assigning P-backcompat-lang, 1.0 milestone.
Simpler reproduction (it's not related to fixed sized arrays, updating title):
If you want to see a segfault you have to do something in the loop and iterate twice: This prints 1 and 2, then stalls a bit, then segfaults.

Discussion:
ast::ExprForLoop(ref pat, ref head, ref blk, _) => { // The pattern lives as long as the block. debug!("walk_expr for loop case: blk id={}", blk.id); <del> self.walk_expr(&**head); </del> <ins> self.consume_expr(&**head); </ins> <del> let head_cmt = return_if_err!(self.mc.cat_expr(&**head)); self.walk_pat(head_cmt, pat.clone()); </del> <ins> // Fetch the type of the value that the iteration yields to // produce the pattern's categorized mutable type. let pattern_type = ty::node_id_to_type(self.tcx(), pat.id); let pat_cmt = self.mc.cat_rvalue(pat.id, pat.span, ty::ReScope(blk.id), pattern_type); self.walk_pat(pat_cmt, pat.clone()); </ins> self.walk_block(&**blk); }

} ast::PatIdent(ast::BindByValue(_), _, _) => { let mode = copy_or_move(typer.tcx(), cmt_pat.ty, PatBindingMove); <ins> debug!("walk_pat binding consuming pat"); </ins> delegate.consume_pat(pat, cmt_pat, mode); } _ => {

<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. // Issue #16205. struct Foo { a: [Box<int>, ..3], } fn main() { let mut y = 1i; let x = Some(&mut y); for &a in x.iter() {    //~ ERROR cannot move out } let f = Foo { a: [box 3, box 4, box 5], }; for &a in f.a.iter() {  //~ ERROR cannot move out } let x = Some(box 1i); for &a in x.iter() {    //~ ERROR cannot move out } } </ins>
Change:
Some combinations of string variables and literals are not concatenated properly using '+'. It seems to be if there's a variable between two literals. Example Produces rt: --- rt: e6c6:main:main: rust: abcABCabc rt: e6c6:main:main: rust: ABCabABC Note the missing 'c' in the second line.
When translating vec-append, delay destination string's null-byte-accounting length decrement until the destination string has already been resized. Closed by .

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:
I was looking for a collection of environment variables that honours but was unable to find a definitive list. There are a few mentions of variables such as , and on google but none of them are documented in Would it be possible to add these to the manual for future reference under an section much like and ?
Yup, that'd be great.
Lots of these are duplicates, but
This looks like an actual list of all of them right now:
FYI: Just (Document RUSTTESTTASKS in the "book") in response to spurious test failures due to parallel text execution.
Full list as of now:
(I gusess some of these are not actually env vars)

Discussion:
fBopt-levelfR=fIVALfR Optimize with possible levels 0[en]3 <ins> .SH ENVIRONMENT VARIABLES Some of these affect the output of the compiler, while others affect programs which link to the standard library. .TP fBRUST_TEST_THREADSfR The test framework Rust provides executes tests in parallel. This variable sets the maximum number of threads used for this purpose. .TP fBRUST_TEST_NOCAPTUREfR A synonym for the --nocapture flag. .TP fBRUST_MIN_STACKfR Sets the minimum stack size for new threads. .TP fBRUST_BACKTRACEfR If set, produces a backtrace in the output of a program which panics. </ins> .SH "EXAMPLES" To build an executable from a source file with a main function: $ rustc -o hello hello.rs
Change:
Lists of items on the std docs should be sorted in some fashion. Alphabetical sorting throughout may not be desirable but I thought I should list all of them here anyway. If other sorting methods are better, I could create more categories. Lists which are sorted alphabetically: [x] [x] In : managedbound should be first.

Discussion:
* `begin_unwind` : ___Needs filling in___ <ins> * `managed_bound` : This type implements "managed" </ins> * `no_copy_bound` : This type does not implement "copy", even if eligible * `no_send_bound` : This type does not implement "send", even if eligible <del> * `no_sync_bound` : This type does not implement "sync", even if eligible * `managed_bound` : This type implements "managed" </del> <ins> * `no_share_bound` : This type does not implement "share", even if eligible </ins> * `eh_personality` : ___Needs filling in___ * `exchange_free`
Change:
Instead of just saying the key can't be verified, explain why.
Yeah, it should also not fail! Missing gpg is a warning condition, not an error condition.

Discussion:
if c.pgp { pgp::init(c.root); <ins> } else { warn("command "gpg" is not found"); warn("you have to install "gpg" from source " + " or package manager to get it to work correctly"); </ins> } c

let buildpath = fs::connect(_path, "/test"); need_dir(buildpath); #debug("Testing: %s -> %s", cf, buildpath); <del> let p = run::program_output("rustc", ["--out-dir", buildpath, "--test", cf]); </del> <ins> let p = run::program_output(rustc_sysroot(), ["--out-dir", buildpath, "--test", cf]); </ins> if p.status != 0 { error(#fmt["rustc failed: %dn%sn%s", p.status, p.err, p.out]); ret;

let buildpath = fs::connect(_path, "/build"); need_dir(buildpath); #debug("Installing: %s -> %s", cf, buildpath); <del> let p = run::program_output("rustc", ["--out-dir", buildpath, cf]); </del> <ins> let p = run::program_output(rustc_sysroot(), ["--out-dir", buildpath, cf]); </ins> if p.status != 0 { error(#fmt["rustc failed: %dn%sn%s", p.status, p.err, p.out]); ret;

} } <ins> fn rustc_sysroot() -> str { alt os::get_exe_path() { some(_path) { let path = [_path, "..", "bin", "rustc"]; check vec::is_not_empty(path); let rustc = fs::normalize(fs::connect_many(path)); #debug("  rustc: %s", rustc); rustc } none { "rustc" } } } </ins> fn install_source(c: cargo, path: str) { #debug("source: %s", path); fs::change_dir(path);
Change:
Both the exportname and linksection attributes will produce an ICE if '0' is contained within the string. Input Output and Bakctrace Version
Fascinating find! I'm curious about what lead you to it. Is there a need to put null in these values?
I had typed rather than . It was an accidental discovery, I'm not aware of any need for a null character here.
I marked this as easy since fixing this is probably just a matter of going to that exact code and emitting a proper error. Good starter bug.
This is actually caused by CStrings failing the task if they have an interior null. . Adding an error would fix this particular issue, but it wouldn't fix the underlying issue, so maybe a different course of action would be better. On a side note, what is the proper way to add an error to the compiler? ? ? I couldn't find any documentation on it.
What is the underlying issue? That we should always throw an error if a has an interior null character? Or that we should allow 's to have null characters?
The underlying issue was that the checked versions of tocstring and withcstr crash on interior nulls. Doing an extra interior null check before calling them in this case doesn't help with this problem in other cases, and failing the task seems unnecessary, especially for the checked version. Perhaps the checked version could return an Option, and the unchecked would keep its current behavior. Edit: Alternately, a tocstropt function could be and used where necessary.
Is anyone working on this? I'll take a crack at it this week if not.
I am. I a withcstr_opt function (that had to wait on ), and am putting the finishing touches on the error messages.

Discussion:
} } <ins> fn contains_null(s: &str) -> bool { s.bytes().any(|b| b == 0) } </ins> pub fn get_item_val(ccx: &CrateContext, id: ast::NodeId) -> ValueRef { debug!("get_item_val(id=`{:?}`)", id);

unsafe { let llty = llvm::LLVMTypeOf(v); <ins> if contains_null(sym.as_slice()) { ccx.sess().fatal( format!("Illegal null byte in export_name value: `{}`", sym).as_slice()); } </ins> let g = sym.as_slice().with_c_str(|buf| { llvm::LLVMAddGlobal(ccx.llmod(), llty, buf) });

match attr::first_attr_value_str_by_name(i.attrs.as_slice(), "link_section") { <del> Some(sect) => unsafe { sect.get().with_c_str(|buf| { llvm::LLVMSetSection(v, buf); }) </del> <ins> Some(sect) => { if contains_null(sect.get()) { ccx.sess().fatal(format!("Illegal null byte in link_section value: `{}`", sect.get()).as_slice()); } unsafe { sect.get().with_c_str(|buf| { llvm::LLVMSetSection(v, buf); }) } </ins> }, None => () }