jiebi/CodeConvo huggingface dataset:
Change:
In the rust book Getting Started section, it is mentioned that we can have source file name as "", however in the cargo introduction section if we move the file inside src directory and run cargo build, it fails. Having the file renamed as makes cargo build success. This is not mentioned in the getting started document. I think the Getting Started section should either say that the file name should be or if the file name is other than , it should mention on how to make cargo build succeed by telling the cargo to look for in the src directory.
Hm, this is just an example of multiple-words source file name: All other places mention : I would call it unfortunate place for file naming details: we switch from to and back in the same paragaph. It make sense to move this example to some other place.

Discussion:
## Writing and Running a Rust Program <del> Next, make a new source file and call it *main.rs*. Rust files always end in a *.rs* extension. If you’re using more than one word in your filename, use an underscore to separate them; for example, you'd use *hello_world.rs* rather than *helloworld.rs*. </del> <ins> We need to create a source file for our Rust program. Rust files always end in a *.rs* extension. If you are using more than one word in your filename, use an underscore to separate them; for example, you would use *my_program.rs* rather than *myprogram.rs*. </ins> <del> Now open the *main.rs* file you just created, and type the following code: </del> <ins> Now, make a new file and call it *main.rs*. Open the file and type the following code: </ins> ```rust fn main() {
Change:
When doing a build with rustbuild, it turns out that two tmp/ dirs end up being created. One is in the directory that rustbuild owns, and one is in the current directory (next to the directory). The one next to the directory contains some information for partitioning tests and information about the error index. Both of these shouldn't exist and their output should be in the rustbuild build/ directory. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
More on rustbuild:
I seem to recall seeing a tmp directory inside build, but I can't seem to recreate it now. Maybe it only appears temporarily during some particular steps and I've deleted it. What do you see as the steps for removing the tmp directory inside build/? Or is the solution to leave that and move the tmp directory created in the root into the build/ directory?
I'd advocate to move the root tmp directory into the build/ directory, personally. The strategy here is to track down what's creating that dir (I'm not sure myself) and just update it to all use the build/ dir
Doesn't seem to be case anymore, creates only .
Perhaps creates it because I still see the second outside of the directory created in the last few days.
claim Indeed created this directory, I'll see if I can fix it.
This directory is created by tests which use like . I'll have PR soon.
cc (re-adds the outer to ).
release-assignment

Discussion:
/unicode-downloads /target /src/tools/x/target <del> # Generated by compiletest for incremental /tmp/ </del> # Created by default with `src/ci/docker/run.sh` /obj/

} pub fn run_tests(config: Config) { <del> // FIXME(#33435) Avoid spurious failures in codegen-units/partitioning tests. if let Mode::CodegenUnits = config.mode { let _ = fs::remove_dir_all("tmp/partitioning-tests"); } </del> // If we want to collect rustfix coverage information, // we first make sure that the coverage file does not exist. // It will be created later on.
Change:
I feel like the warning fires wrongly on this variant name in particular.
the warning fires whenever the name contains a ` if the characters directly before and after are digits?
Adding an exception for digits only will lead to to an issue later about some other non-letter case. What should be done instead, IMO, is check that the character before and after are letters and only warn then. /me shrugs. Very bikeshedy thing to discuss.
I understand wanting this to just work, but it's getting uncomfortably clever. Requiring a suppression here isn't so bad. Is this a case that comes up other than for "X86_64"?

Discussion:
impl NonCamelCaseTypes { fn check_case(&self, cx: &LateContext, sort: &str, name: ast::Name, span: Span) { <ins> fn char_has_case(c: char) -> bool { c.is_lowercase() || c.is_uppercase() } </ins> fn is_camel_case(name: ast::Name) -> bool { let name = name.as_str(); if name.is_empty() {

// start with a non-lowercase letter rather than non-uppercase // ones (some scripts don't have a concept of upper/lowercase) <del> !name.is_empty() && !name.chars().next().unwrap().is_lowercase() && !name.contains('_') </del> <ins> !name.is_empty() && !name.chars().next().unwrap().is_lowercase() && !name.contains("__") && !name.chars().collect::<Vec<_>>().windows(2).any(|pair| { // contains a capitalisable character followed by, or preceded by, an underscore char_has_case(pair[0]) && pair[1] == '_' || char_has_case(pair[1]) && pair[0] == '_' }) </ins> } fn to_camel_case(s: &str) -> String { <del> s.split('_') .flat_map(|word| { </del> <ins> s.trim_matches('_') .split('_') .map(|word| { </ins> word.chars().enumerate().map(|(i, c)| if i == 0 { c.to_uppercase().collect::<String>() } else { c.to_lowercase().collect() }) <ins> .collect::<Vec<_>>() .concat() </ins> }) <ins> .filter(|x| !x.is_empty()) </ins> .collect::<Vec<_>>() <del> .concat() </del> <ins> .iter().fold((String::new(), None), |(acc, prev): (String, Option<&String>), next| { // separate two components with an underscore if their boundary cannot // be distinguished using a uppercase/lowercase case distinction let join = if let Some(prev) = prev { let l = prev.chars().last().unwrap(); let f = next.chars().next().unwrap(); !char_has_case(l) && !char_has_case(f) } else { false }; (acc + if join { "_" } else { "" } + next, Some(next)) }).0 </ins> } if !is_camel_case(name) {

type __ = isize; //~ ERROR type `__` should have a camel case name such as `CamelCase` <ins> struct X86_64; struct X86__64; //~ ERROR type `X86__64` should have a camel case name such as `X86_64` struct Abc_123; //~ ERROR type `Abc_123` should have a camel case name such as `Abc123` struct A1_b2_c3; //~ ERROR type `A1_b2_c3` should have a camel case name such as `A1B2C3` </ins> fn main() { }
Change:
Gives: Specifically, .LBB07 is unreachable, but LLVM can't quite figure that out. It's probably possible to write wrappingdiv in a way which avoids this problem.
Not sure why LLVM doesn't optimise this more (the duplicated check of against -1 should be easy enough to handle), but the good news is that the MIR-driven code generator produces this ASM instead: Which is what is expected.
Currently generated code looks just fine to me. Fixed.
Still looks fine it seems: (latest stable)
Given this just needs a test, this could be transformed into an easy issue for newcomers.
Triage; not aware of any test . Still gives the good code when compiled.

Discussion:
<ins> // Test that `wrapping_div` only checks divisor once. // This test checks that there is only a single compare agains -1 and -1 is not present as a // switch case (the second check present until rustc 1.12). // This test also verifies that a single panic call is generated (for the division by zero case). // compile-flags: -O #![crate_type = "lib"] // CHECK-LABEL: @f #[no_mangle] pub fn f(x: i32, y: i32) -> i32 { // CHECK-COUNT-1: icmp eq i32 %y, -1 // CHECK-COUNT-1: panic // CHECK-NOT: i32 -1, label x.wrapping_div(y) } </ins>
Change:
As I was using writeln! to fill an in-memory buffer for data that explicitly wants a specific type of newlines (LF, fortunately), and I was wondering whether writeln! would always use LF, or would use the type of newline relevant to the platform (essentially, LF on Unix, CR/LF on Windows), and couldn't find the answer in !.html. (I got my answer on IRC, it's always LF) There may be other places where such information is relevant (println! comes to mind). Cc:
Sure, want to add it? :)
I would, if I knew whether there are other places that would benefit from this information as well.
Except for and , I don't see any places... You can already add it to these docs and if another function/macro needs it, then we'll add it.

Discussion:
} /// Use the `format!` syntax to write data into a buffer, appending a newline. <ins> /// On all platforms, the newline is the LINE FEED character (`n`/`U+000A`) /// alone (no additional CARRIAGE RETURN (`r`/`U+000D`). </ins> /// /// This macro is typically used with a buffer of `&mut `[`Write`][write]. ///

($($arg:tt)*) => ($crate::io::_print(format_args!($($arg)*))); } <del> /// Macro for printing to the standard output, with a newline. </del> <ins> /// Macro for printing to the standard output, with a newline. On all /// platforms, the newline is the LINE FEED character (`n`/`U+000A`) alone /// (no additional CARRIAGE RETURN (`r`/`U+000D`). </ins> /// /// Use the `format!` syntax to write data to the standard output. /// See `std::fmt` for more information.
Change:
rustc 1.12.0-nightly ( 2016-07-10) Changing the order of bounds in the associated type declaration changes which causes a spurious "mismatched types" error. Using UFCS works around the issue: The same issue exists with bounds like to compare with itself as well as another type. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cf.
Looks like this is caused by on the set of bounds from the trait, but that is just find the first one (in the order they are internally stored), this needs to filter and produce a vector of bounds or something similar. cc
Update: using filter and then calling on all matching bounds does not fix this issue.
I believe your problem is . Right now it works fine because the above would trigger for vs or vs . However, it's incorrect with your changes as is dropped in favor of even if and are not equal. The correct form would be more like this:
I guess that you didn't just call , but are also packaging up the specific bound that was matched? Anyway, not having seen the full diff, the general direction of these changes make sense to me.
Related:
triage: P-medium
Triage: :
This is fixed on current master. Should be closed.
I would like to work on this issue if its still relevant?
As mentioned the original code now compiles: Closing as there doesn’t seem to be anything left to do here.
do we have any regression test? I couldn't see any.
Oh good point. Sorry I missed the label. Yes, feel free to work on adding a regression test!
claim

Discussion:
<ins> // This test is a regression test for #34792 // check-pass pub struct A; pub struct B; pub trait Foo { type T: PartialEq<A> + PartialEq<B>; } pub fn generic<F: Foo>(t: F::T, a: A, b: B) -> bool { t == a && t == b } pub fn main() {} </ins>
Change:
Building the compiler docs with rustbuild overwrites the js search index of the std docs with the one from the compiler docs. (that is no longer live).
Hm I think that this may be a result of a little too aggressively cleaning out the directory, there's probably some which should be sequenced differently or perhaps just not run at all.
This was fixed by .
Indeed!

Discussion:
for (krate, path, default) in krates("test_shim") { rules.doc(&krate.doc_step, path) .dep(|s| s.name("libtest")) <del> .default(default && build.config.docs) </del> <ins> .default(default && build.config.compiler_docs) </ins> .run(move |s| doc::test(build, s.stage, s.target)); } for (krate, path, default) in krates("rustc-main") {
Change:
For example, invocation in should search in but instead searches in .
cc
It looks like this is a problem with .

Discussion:
/// compilation on error, merely emits a non-fatal error and returns None. pub fn expr_to_string(cx: &mut ExtCtxt, expr: P<ast::Expr>, err_msg: &str) -> Option<(InternedString, ast::StrStyle)> { <ins> // Update `expr.span`'s expn_id now in case expr is an `include!` macro invocation. let expr = expr.map(|mut expr| { expr.span.expn_id = cx.backtrace; expr }); </ins> // we want to be able to handle e.g. concat("foo", "bar") let expr = cx.expander().fold_expr(expr); match expr.node {

macro_rules! m { () => { include!("file.txt"); } } <ins> macro_rules! n { () => { unsafe { asm!(include_str!("file.txt")); } } } </ins>

// option. This file may not be copied, modified, or distributed // except according to those terms. <del> #![feature(rustc_attrs)] </del> <ins> #![feature(asm, rustc_attrs)] #![allow(unused)] </ins> #[macro_use] mod foo; m!(); <ins> fn f() { n!(); } </ins> #[rustc_error] fn main() {} //~ ERROR compilation successful
Change:
Ownership, borrowing and lifetimes are discussed after vectors and before methods, but the text seems written with another order in mind. In particular, there's an inaccuracy in , which says: Should this be removed/rephrased/dealt with some other way? I might try a PR for this (removing the inaccuracy) myself.
A PR for this would be great; I would say "in a later chapter" and create a forward reference.

Discussion:
vector, even the heap-allocated memory. This happens deterministically, at the end of the scope. <del> We'll cover [vectors] in detail later in this chapter; we only use them </del> <ins> We covered [vectors] in the previous chapter; we use them </ins> here as an example of a type that allocates space on the heap at runtime. They behave like [arrays], except their size may change by `push()`ing more elements onto them. Vectors have a [generic type][generics] `Vec<T>`, so in this example `v` will have type <del> `Vec<i32>`. We'll cover generics in detail later in this chapter. </del> <ins> `Vec<i32>`. We'll cover [generics] in detail in a later chapter. </ins> [arrays]: primitive-types.html#arrays [vectors]: vectors.html
Change:
Tracking issue for the new non-blocking iterator API introduced in . The API is currently gated behind the unstable feature. The API includes: - cc
Hey folks, just thought I'd ping this and ask if there's anything I can do to help guide this towards stable? Would love to start using it, but no worries if it's just low on the priority list :+1:
I'd like to know the same thing as mitchmindtree. Is this being guide towards stable?
fcp merge Seems like a nifty API to have!
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell: psst I wasn't able to add the label, please do so.
The final comment period is now complete.

Discussion:
rx: &'a Receiver<T> } <ins> /// An iterator that attempts to yield all pending values for a receiver. /// `None` will be returned when there are no pending values remaining or /// if the corresponding channel has hung up. /// /// This Iterator will never block the caller in order to wait for data to /// become available. Instead, it will return `None`. #[unstable(feature = "receiver_try_iter", issue = "34931")] pub struct TryIter<'a, T: 'a> { rx: &'a Receiver<T> } </ins> /// An owning iterator over messages on a receiver, this iterator will block /// whenever `next` is called, waiting for a new message, and `None` will be /// returned when the corresponding channel has hung up.

pub fn iter(&self) -> Iter<T> { Iter { rx: self } } <ins> /// Returns an iterator that will attempt to yield all pending values. /// It will return `None` if there are no more pending values or if the /// channel has hung up. The iterator will never `panic!` or block the /// user by waiting for values. #[unstable(feature = "receiver_try_iter", issue = "34931")] pub fn try_iter(&self) -> TryIter<T> { TryIter { rx: self } } </ins> } impl<T> select::Packet for Receiver<T> {

fn next(&mut self) -> Option<T> { self.rx.recv().ok() } } <ins> #[unstable(feature = "receiver_try_iter", issue = "34931")] impl<'a, T> Iterator for TryIter<'a, T> { type Item = T; fn next(&mut self) -> Option<T> { self.rx.try_recv().ok() } } </ins> #[stable(feature = "receiver_into_iter", since = "1.1.0")] impl<'a, T> IntoIterator for &'a Receiver<T> { type Item = T;

} #[test] <ins> fn test_recv_try_iter() { let (request_tx, request_rx) = channel(); let (response_tx, response_rx) = channel(); // Request `x`s until we have `6`. let t = thread::spawn(move|| { let mut count = 0; loop { for x in response_rx.try_iter() { count += x; if count == 6 { return count; } } request_tx.send(()).unwrap(); } }); for _ in request_rx.iter() { if response_tx.send(2).is_err() { break; } } assert_eq!(t.join().unwrap(), 6); } #[test] </ins> fn test_recv_into_iter_owned() { let mut iter = { let (tx, rx) = channel::<i32>();
Change:
Testcase: Produces the following asm in release mode: I would expect it to generate straight-line code with just three multiplies. It's possible this will be fixed by upgrading LLVM; there have been some recent changes to unrolling heuristics.
Assembly produced today is correct, and as expected. Closing.
Reopening as E-needstest. This should get a codegen test.

Discussion:
<ins> // Copyright 2017 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: -O #![crate_type = "lib"] // CHECK-LABEL: @issue_34947 #[no_mangle] pub fn issue_34947(x: i32) -> i32 { // CHECK: mul // CHECK-NEXT: mul // CHECK-NEXT: mul // CHECK-NEXT: ret x.pow(5) } </ins>
Change:
Perhaps there's a minimum amount of debug info we can output by default without breaking things. This is alarming to newcomers.
I am 99% confident this comes straight from dsymutil.
Possibly related to
non-critical for 0.6, de-milestoning
+1 to fix this or provide temporary "fix"
As a new user curious about the language, this definitely made me think I'd done something wrong while building. This issue is also not a top result in Google if you search for the full error message and I haven't seen anywhere else that the issue is detailed. While this is totally understandable in a pre 1.0 release, it would be really nice to have a note that it's expected in the README and/or printed to the console at the end of the build output.
+1 30 seconds into playing with rust, initial impression: 0.6 is still not ready for anything more than casual experimentation. If that's the message you intend to send, well done!
+1 Occurs when building rust, and when compiling .rs files. I was almost certain my build had failed since the last ~6 lines were these warnings (while everything was fine). I also get this warning every time I compile any .rs file.
Nominating, production ready.
accepted for production-ready milestone
Thanks! I know it's a small thing, but I certainly appreciate it :)
I'd be curious what happens if we stop running dsymutil for non-debug builds. In particular, does the gdb experience suffer at all when debugging the resulting binary?
I am writing a rustpkg script for to fix cadencemarseille/rust-pcre and this is tripping me up because part of the script looks at output, which includes this warning in the data. For now I think I'll just use the last line of output, but it would be great to have this issue fixed.
I'm still getting this in Homebrew Rust on Mavericks. Trace: System: When Homebrew gets Rust 0.9 for Mavericks, will this be fixed?
I get this all the time still.
That's probably because we build servo with debug symbols, hence we run dsymutil. I would expect will have a better experience.
The job failed! Check out the build log: <details<summary<iClick to see the possible cause of the failure (guessed by this bot)</i</summary</details

Discussion:
sess.abort_if_errors(); } <del> // Clean up on Darwin if sess.targ_cfg.os == abi::OsMacos { </del> <ins> // On OSX, debuggers needs this utility to get run to do some munging of the // symbols if sess.targ_cfg.os == abi::OsMacos && sess.opts.debuginfo { </ins> // FIXME (#9639): This needs to handle non-utf8 paths run::process_status("dsymutil", [output.as_str().unwrap().to_owned()]); }
Change:
Gives (on playground): There are two problems here: error message is absolutely terrible. the sake of safety, we might need to do something other than panic if this happens. This could affect crates which require that join() never returns early, like crossbeam.
Possibly in or otherwise, but this seems to have since been fixed -- this now deadlocks.

Discussion:
unsafe { let ret = libc::pthread_join(self.id, ptr::null_mut()); mem::forget(self); <del> debug_assert_eq!(ret, 0); </del> <ins> assert!(ret == 0, "failed to join thread: {}", io::Error::from_raw_os_error(ret)); </ins> } }

pub const WAIT_OBJECT_0: DWORD = 0x00000000; pub const WAIT_TIMEOUT: DWORD = 258; <ins> pub const WAIT_FAILED: DWORD = 0xFFFFFFFF; </ins> #[cfg(target_env = "msvc")] pub const MAX_SYM_NAME: usize = 2000;

} pub fn join(self) { <del> unsafe { c::WaitForSingleObject(self.handle.raw(), c::INFINITE); } </del> <ins> let rc = unsafe { c::WaitForSingleObject(self.handle.raw(), c::INFINITE) }; if rc == c::WAIT_FAILED { panic!("failed to join on thread: {}", io::Error::last_os_error()); } </ins> } pub fn yield_now() {

/// [`Err`]: ../../std/result/enum.Result.html#variant.Err /// [`panic`]: ../../std/macro.panic.html /// <ins> /// # Panics /// /// This function may panic on some platforms if a thread attempts to join /// itself or otherwise may create a deadlock with joining threads. /// </ins> /// # Examples /// /// ```