jiebi/CodeConvo huggingface dataset:
Code change:
This is similar to the same buggy behavior we saw for matchers fixed in 1.20.0. For example in Rust 1.19 the following code fails to compile with the message , but correctly prints followed by as of 1.20. The matcher is currently broken in the same way. rustc 1.28.0-nightly ( 2018-06-09)
The ident issue was , so mentioning who fixed that one in . Would you be interested in taking a look at this similar case?
Duplicate of . should still be working on it I think?
Thanks! Let's continue to track this as part of .

Related discussion:
text: //}}} <ins> //{{{ issue 50903 ============================================================== macro_rules! foo_50903 { ($($lif:lifetime ,)* #) => {}; } foo_50903!('a, 'b, #); foo_50903!('a, #); foo_50903!(#); //}}} //{{{ issue 51477 ============================================================== macro_rules! foo_51477 { ($lifetime:lifetime) => { "last token is lifetime" }; ($other:tt) => { "last token is other" }; ($first:tt $($rest:tt)*) => { foo_51477!($($rest)*) }; } fn test_51477() { assert_eq!("last token is lifetime", foo_51477!('a)); assert_eq!("last token is other", foo_51477!(@)); assert_eq!("last token is lifetime", foo_51477!(@ {} 'a)); } //}}} </ins> //{{{ some more tests ========================================================== macro_rules! test_block {
Code change:
This is similar to the same buggy behavior we saw for matchers fixed in 1.20.0. For example in Rust 1.19 the following code fails to compile with the message , but correctly prints followed by as of 1.20. The matcher is currently broken in the same way. rustc 1.28.0-nightly ( 2018-06-09)
The ident issue was , so mentioning who fixed that one in . Would you be interested in taking a look at this similar case?
Duplicate of . should still be working on it I think?
Thanks! Let's continue to track this as part of .

Related discussion:
text: test_meta_block!(windows {}); <ins> macro_rules! test_lifetime { (1. $($l:lifetime)* $($b:block)*) => {}; (2. $($b:block)* $($l:lifetime)*) => {}; } test_lifetime!(1. 'a 'b {} {}); test_lifetime!(2. {} {} 'a 'b); </ins> //}}} fn main() {
Code change:
This is similar to the same buggy behavior we saw for matchers fixed in 1.20.0. For example in Rust 1.19 the following code fails to compile with the message , but correctly prints followed by as of 1.20. The matcher is currently broken in the same way. rustc 1.28.0-nightly ( 2018-06-09)
The ident issue was , so mentioning who fixed that one in . Would you be interested in taking a look at this similar case?
Duplicate of . should still be working on it I think?
Thanks! Let's continue to track this as part of .

Related discussion:
text: test_40569(); test_35650(); test_24189(); <ins> test_51477(); </ins> }
Code change:
When I build this code on nightly... ...I get these errors: The first error is fine, but the second one is missing the first character of . It looks like rustc assumes the first character is an and removes it without checking. :
Currently working on a fix here: Still need to add UI tests, which I'll do once I figure out how they work.
Adding to the Rust 2018 Edition Preview milestone. Has a pending PR, too.

Related discussion:
text: // highlighted text will always be `&<expr>` and // thus can transform to `&mut` by slicing off // first ASCII character and prepending "&mut ". <del> let borrowed_expr = src[1..].to_string(); return (assignment_rhs_span, format!("&mut {}", borrowed_expr)); </del> <ins> if src.starts_with('&') { let borrowed_expr = src[1..].to_string(); return (assignment_rhs_span, format!("&mut {}", borrowed_expr)); } </ins> } }
Code change:
When I build this code on nightly... ...I get these errors: The first error is fine, but the second one is missing the first character of . It looks like rustc assumes the first character is an and removes it without checking. :
Currently working on a fix here: Still need to add UI tests, which I'll do once I figure out how they work.
Adding to the Rust 2018 Edition Preview milestone. Has a pending PR, too.

Related discussion:
text: <ins> // Copyright 2018 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. #![feature(nll)] fn main() { let foo = &16; //~^ HELP consider changing this to be a mutable reference //~| SUGGESTION &mut 16 *foo = 32; //~^ ERROR cannot assign to `*foo` which is behind a `&` reference let bar = foo; //~^ HELP consider changing this to be a mutable reference //~| SUGGESTION &mut i32 *bar = 64; //~^ ERROR cannot assign to `*bar` which is behind a `&` reference } </ins>
Code change:
When I build this code on nightly... ...I get these errors: The first error is fine, but the second one is missing the first character of . It looks like rustc assumes the first character is an and removes it without checking. :
Currently working on a fix here: Still need to add UI tests, which I'll do once I figure out how they work.
Adding to the Rust 2018 Edition Preview milestone. Has a pending PR, too.

Related discussion:
text: <ins> error[E0594]: cannot assign to `*foo` which is behind a `&` reference --> $DIR/issue-51515.rs:17:5 | LL |     let foo = &16; |               --- help: consider changing this to be a mutable reference: `&mut 16` ... LL |     *foo = 32; |     ^^^^^^^^^ `foo` is a `&` reference, so the data it refers to cannot be written error[E0594]: cannot assign to `*bar` which is behind a `&` reference --> $DIR/issue-51515.rs:22:5 | LL |     let bar = foo; |         --- help: consider changing this to be a mutable reference: `&mut i32` ... LL |     *bar = 64; |     ^^^^^^^^^ `bar` is a `&` reference, so the data it refers to cannot be written error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0594`. </ins>
Code change:
I noticed this in the output running locally: and that didn't make tests fail. Cc:
Same with panic_unwind:
This error message is printed when running , but before running any test. The code printing it is in . It looks like rustdoc is using that code in order to load the crate and find doctests in it. But since it’s not actually compiling this crate, not having an allocator is not a problem. So I think there are two issues: rustdoc keeps doing its thing even though there are errors. It probably should call something like on its instance at some point. This error should not occur in the first place. One way to inhibit it would be to tell that we’re "compiling" an rlib () rather than some other crate type. rlibs do not need (yet) to have an allocator defined. This is possibly this line: The first issue could in some other situation hide a real problem, but in this case it makes the second one mostly harmless. The only bad consequence is some noise in the output of a test run.
Related:
modify labels: +T-rustdoc
Error: Parsing label command in failed: labels +T-rustdo... Please let know if you're having trouble with this bot.

Related discussion:
text: let crate_types = if options.proc_macro_crate { vec![config::CrateType::ProcMacro] } else { <del> vec![config::CrateType::Dylib] </del> <ins> vec![config::CrateType::Rlib] </ins> }; let sessopts = config::Options {
Code change:
I noticed this in the output running locally: and that didn't make tests fail. Cc:
Same with panic_unwind:
This error message is printed when running , but before running any test. The code printing it is in . It looks like rustdoc is using that code in order to load the crate and find doctests in it. But since it’s not actually compiling this crate, not having an allocator is not a problem. So I think there are two issues: rustdoc keeps doing its thing even though there are errors. It probably should call something like on its instance at some point. This error should not occur in the first place. One way to inhibit it would be to tell that we’re "compiling" an rlib () rather than some other crate type. rlibs do not need (yet) to have an allocator defined. This is possibly this line: The first issue could in some other situation hide a real problem, but in this case it makes the second one mostly harmless. The only bad consequence is some noise in the output of a test run.
Related:
modify labels: +T-rustdoc
Error: Parsing label command in failed: labels +T-rustdo... Please let know if you're having trouble with this bot.

Related discussion:
text: intravisit::walk_crate(this, krate); }); }); <ins> compiler.session().abort_if_errors(); </ins> let ret: Result<_, ErrorReported> = Ok(collector.tests); ret }) <del> }) .expect("compiler aborted in rustdoc!"); </del> <ins> }); let tests = match tests { Ok(tests) => tests, Err(ErrorReported) => return 1, }; </ins> test_args.insert(0, "rustdoctest".to_string());
Code change:
I noticed this in the output running locally: and that didn't make tests fail. Cc:
Same with panic_unwind:
This error message is printed when running , but before running any test. The code printing it is in . It looks like rustdoc is using that code in order to load the crate and find doctests in it. But since it’s not actually compiling this crate, not having an allocator is not a problem. So I think there are two issues: rustdoc keeps doing its thing even though there are errors. It probably should call something like on its instance at some point. This error should not occur in the first place. One way to inhibit it would be to tell that we’re "compiling" an rlib () rather than some other crate type. rlibs do not need (yet) to have an allocator defined. This is possibly this line: The first issue could in some other situation hide a real problem, but in this case it makes the second one mostly harmless. The only bad consequence is some noise in the output of a test run.
Related:
modify labels: +T-rustdoc
Error: Parsing label command in failed: labels +T-rustdo... Please let know if you're having trouble with this bot.

Related discussion:
text: <ins> // compile-flags:--test /// ``` /// assert!(true) /// ``` pub fn f() {} pub fn f() {} </ins>
Code change:
I noticed this in the output running locally: and that didn't make tests fail. Cc:
Same with panic_unwind:
This error message is printed when running , but before running any test. The code printing it is in . It looks like rustdoc is using that code in order to load the crate and find doctests in it. But since it’s not actually compiling this crate, not having an allocator is not a problem. So I think there are two issues: rustdoc keeps doing its thing even though there are errors. It probably should call something like on its instance at some point. This error should not occur in the first place. One way to inhibit it would be to tell that we’re "compiling" an rlib () rather than some other crate type. rlibs do not need (yet) to have an allocator defined. This is possibly this line: The first issue could in some other situation hide a real problem, but in this case it makes the second one mostly harmless. The only bad consequence is some noise in the output of a test run.
Related:
modify labels: +T-rustdoc
Error: Parsing label command in failed: labels +T-rustdo... Please let know if you're having trouble with this bot.

Related discussion:
text: <ins> error[E0428]: the name `f` is defined multiple times --> $DIR/test-compile-fail1.rs:8:1 | 6 | pub fn f() {} | ---------- previous definition of the value `f` here 7 | 8 | pub fn f() {} | ^^^^^^^^^^ `f` redefined here | = note: `f` must be defined only once in the value namespace of this module error: aborting due to previous error For more information about this error, try `rustc --explain E0428`. </ins>
Code change:
I noticed this in the output running locally: and that didn't make tests fail. Cc:
Same with panic_unwind:
This error message is printed when running , but before running any test. The code printing it is in . It looks like rustdoc is using that code in order to load the crate and find doctests in it. But since it’s not actually compiling this crate, not having an allocator is not a problem. So I think there are two issues: rustdoc keeps doing its thing even though there are errors. It probably should call something like on its instance at some point. This error should not occur in the first place. One way to inhibit it would be to tell that we’re "compiling" an rlib () rather than some other crate type. rlibs do not need (yet) to have an allocator defined. This is possibly this line: The first issue could in some other situation hide a real problem, but in this case it makes the second one mostly harmless. The only bad consequence is some noise in the output of a test run.
Related:
modify labels: +T-rustdoc
Error: Parsing label command in failed: labels +T-rustdo... Please let know if you're having trouble with this bot.

Related discussion:
text: <ins> error: expected one of `!` or `::`, found `<eof>` --> $DIR/test-compile-fail2.rs:3:1 | 3 | fail | ^^^^ expected one of `!` or `::` error: aborting due to previous error </ins>
Code change:
I noticed this in the output running locally: and that didn't make tests fail. Cc:
Same with panic_unwind:
This error message is printed when running , but before running any test. The code printing it is in . It looks like rustdoc is using that code in order to load the crate and find doctests in it. But since it’s not actually compiling this crate, not having an allocator is not a problem. So I think there are two issues: rustdoc keeps doing its thing even though there are errors. It probably should call something like on its instance at some point. This error should not occur in the first place. One way to inhibit it would be to tell that we’re "compiling" an rlib () rather than some other crate type. rlibs do not need (yet) to have an allocator defined. This is possibly this line: The first issue could in some other situation hide a real problem, but in this case it makes the second one mostly harmless. The only bad consequence is some noise in the output of a test run.
Related:
modify labels: +T-rustdoc
Error: Parsing label command in failed: labels +T-rustdo... Please let know if you're having trouble with this bot.

Related discussion:
text: <ins> error: unterminated double quote string --> $DIR/test-compile-fail3.rs:3:1 | 3 | "fail | ^^^^^^ error: aborting due to previous error </ins>
Code change:
I noticed this in the output running locally: and that didn't make tests fail. Cc:
Same with panic_unwind:
This error message is printed when running , but before running any test. The code printing it is in . It looks like rustdoc is using that code in order to load the crate and find doctests in it. But since it’s not actually compiling this crate, not having an allocator is not a problem. So I think there are two issues: rustdoc keeps doing its thing even though there are errors. It probably should call something like on its instance at some point. This error should not occur in the first place. One way to inhibit it would be to tell that we’re "compiling" an rlib () rather than some other crate type. rlibs do not need (yet) to have an allocator defined. This is possibly this line: The first issue could in some other situation hide a real problem, but in this case it makes the second one mostly harmless. The only bad consequence is some noise in the output of a test run.
Related:
modify labels: +T-rustdoc
Error: Parsing label command in failed: labels +T-rustdo... Please let know if you're having trouble with this bot.

Related discussion:
text: <ins> // compile-flags:--test // normalize-stdout-test: "src/test/rustdoc-ui" -> "$$DIR" // build-pass #![no_std] extern crate alloc; /// ``` /// assert!(true) /// ``` pub fn f() {} </ins>
Code change:
I noticed this in the output running locally: and that didn't make tests fail. Cc:
Same with panic_unwind:
This error message is printed when running , but before running any test. The code printing it is in . It looks like rustdoc is using that code in order to load the crate and find doctests in it. But since it’s not actually compiling this crate, not having an allocator is not a problem. So I think there are two issues: rustdoc keeps doing its thing even though there are errors. It probably should call something like on its instance at some point. This error should not occur in the first place. One way to inhibit it would be to tell that we’re "compiling" an rlib () rather than some other crate type. rlibs do not need (yet) to have an allocator defined. This is possibly this line: The first issue could in some other situation hide a real problem, but in this case it makes the second one mostly harmless. The only bad consequence is some noise in the output of a test run.
Related:
modify labels: +T-rustdoc
Error: Parsing label command in failed: labels +T-rustdo... Please let know if you're having trouble with this bot.

Related discussion:
text: <ins> running 1 test test $DIR/test-no_std.rs - f (line 9) ... ok test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out </ins>
Code change:
I was in the middle of bisecting on system llvm and running when I noticed that, in fact, while each step was rebuilding the compiler with the changed llvm correctly, the test that was being run was never recompiled, such that the same one was always running, and my bisect was guided by wrong results. STR: Run once Touch anything that is part of e.g. , e.g. Run again Expected result: Both and the test are rebuilt, and the rebuilt test executed. Actual result: is rebuilt, the test is not, and the test built before the codegen changes is executed.

Related discussion:
text: }, } <ins> // This tells Cargo (and in turn, rustc) to output more complete // dependency information.  Most importantly for rustbuild, this // includes sysroot artifacts, like libstd, which means that we don't // need to track those in rustbuild (an error prone process!). This // feature is currently unstable as there may be some bugs and such, but // it represents a big improvement in rustbuild's reliability on // rebuilds, so we're using it here. // // For some additional context, see #63470 (the PR originally adding // this), as well as #63012 which is the tracking issue for this // feature on the rustc side. cargo.arg("-Zbinary-dep-depinfo"); </ins> cargo.arg("-j").arg(self.jobs().to_string()); // Remove make-related flags to ensure Cargo can correctly set things up cargo.env_remove("MAKEFLAGS");
Code change:
I was in the middle of bisecting on system llvm and running when I noticed that, in fact, while each step was rebuilding the compiler with the changed llvm correctly, the test that was being run was never recompiled, such that the same one was always running, and my bisect was guided by wrong results. STR: Run once Touch anything that is part of e.g. , e.g. Run again Expected result: Both and the test are rebuilt, and the rebuilt test executed. Actual result: is rebuilt, the test is not, and the test built before the codegen changes is executed.

Related discussion:
text: let libdir = builder.sysroot_libdir(compiler, target); let hostdir = builder.sysroot_libdir(compiler, compiler.host); add_to_sysroot(&builder, &libdir, &hostdir, &rustdoc_stamp(builder, compiler, target)); <del> builder.cargo(compiler, Mode::ToolRustc, target, "clean"); </del> } }
Code change:
I was in the middle of bisecting on system llvm and running when I noticed that, in fact, while each step was rebuilding the compiler with the changed llvm correctly, the test that was being run was never recompiled, such that the same one was always running, and my bisect was guided by wrong results. STR: Run once Touch anything that is part of e.g. , e.g. Run again Expected result: Both and the test are rebuilt, and the rebuilt test executed. Actual result: is rebuilt, the test is not, and the test built before the codegen changes is executed.

Related discussion:
text: use std::process::{Command, Stdio, exit}; use std::str; <del> use build_helper::{output, mtime, t, up_to_date}; </del> <ins> use build_helper::{output, t, up_to_date}; </ins> use filetime::FileTime; use serde::Deserialize; use serde_json;
Code change:
I was in the middle of bisecting on system llvm and running when I noticed that, in fact, while each step was rebuilding the compiler with the changed llvm correctly, the test that was being run was never recompiled, such that the same one was always running, and my bisect was guided by wrong results. STR: Run once Touch anything that is part of e.g. , e.g. Run again Expected result: Both and the test are rebuilt, and the rebuilt test executed. Actual result: is rebuilt, the test is not, and the test built before the codegen changes is executed.

Related discussion:
text: // for reason why the sanitizers are not built in stage0. copy_apple_sanitizer_dylibs(builder, &builder.native_dir(target), "osx", &libdir); } <del> builder.cargo(target_compiler, Mode::ToolStd, target, "clean"); </del> } }
Code change:
I was in the middle of bisecting on system llvm and running when I noticed that, in fact, while each step was rebuilding the compiler with the changed llvm correctly, the test that was being run was never recompiled, such that the same one was always running, and my bisect was guided by wrong results. STR: Run once Touch anything that is part of e.g. , e.g. Run again Expected result: Both and the test are rebuilt, and the rebuilt test executed. Actual result: is rebuilt, the test is not, and the test built before the codegen changes is executed.

Related discussion:
text: &builder.sysroot_libdir(target_compiler, compiler.host), &libtest_stamp(builder, compiler, target) ); <del> builder.cargo(target_compiler, Mode::ToolTest, target, "clean"); </del> } }
Code change:
I was in the middle of bisecting on system llvm and running when I noticed that, in fact, while each step was rebuilding the compiler with the changed llvm correctly, the test that was being run was never recompiled, such that the same one was always running, and my bisect was guided by wrong results. STR: Run once Touch anything that is part of e.g. , e.g. Run again Expected result: Both and the test are rebuilt, and the rebuilt test executed. Actual result: is rebuilt, the test is not, and the test built before the codegen changes is executed.

Related discussion:
text: &builder.sysroot_libdir(target_compiler, compiler.host), &librustc_stamp(builder, compiler, target) ); <del> builder.cargo(target_compiler, Mode::ToolRustc, target, "clean"); </del> } }