jiebi/CodeConvo huggingface dataset:
Code change:
https://crater- cc
Possibly accidentally injected by Would be good to find out why this is happening, so let's ping cleanup and see if we can bisect / shrink the problem down to something usable for finding a fix.
ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Failed to confirm that is the cause: Seems like it regressed prior to
For code I used:
modify labels: -E-needs-bisection
Reduced example: () Errors:
Split the macro in two parts to make it easier to follow, and removed the special lifetime : () Error: I think we can now modify labels: -E-needs-mcve
I believe that the most probable culprit is , cc
is indeed the culprit, I can reproduce the bug on
This was . Assigning for now until we have a better understanding of what's going on.
Fixed in

Related discussion:
text: <ins> // check-pass macro_rules! foo { ($(: $p:path)? $(: $l:lifetime)? ) => { bar! {$(: $p)? $(: $l)? } }; } macro_rules! bar { ($(: $p:path)? $(: $l:lifetime)? ) => {}; } foo! {: 'a } fn main() {} </ins>
Code change:
This is still in 's build script: But the use site has been moved here: This means that won't be rebuilt when that env var changes. For the record, I haven't seen a bug from this, was just curious where may be used and spotted the mismatch. cc
Found another one: is used in but it's still mentioned by . cc Could we automate ensuring this? e.g. by searching for in tidy.
Yeah, we can try I guess. Not sure :) Maybe the right solution is that Cargo would, other than some whitelist, remove unknown variables from rustc's environment -- and the whitelist can be expanded via the build script env-tracking.
hmm I wonder if abusing the file format (from ) or encoding this extra info in a comment, would be a good idea.
You mean such that if you use we automatically tell Cargo to rebuild on changes? (That's ). But yeah, I think that would be good. Ideally this would be "well-integrated" vs. the current state of everyone having to remember to do it.

Related discussion:
text: }; let sp = cx.with_def_site_ctxt(sp); <del> let e = match env::var(&var.as_str()) { Err(..) => { </del> <ins> let value = env::var(&var.as_str()).ok().as_deref().map(Symbol::intern); cx.parse_sess.env_depinfo.borrow_mut().insert((Symbol::intern(&var), value)); let e = match value { None => { </ins> let lt = cx.lifetime(sp, Ident::new(kw::StaticLifetime, sp)); cx.expr_path(cx.path_all( sp,
Code change:
This is still in 's build script: But the use site has been moved here: This means that won't be rebuilt when that env var changes. For the record, I haven't seen a bug from this, was just curious where may be used and spotted the mismatch. cc
Found another one: is used in but it's still mentioned by . cc Could we automate ensuring this? e.g. by searching for in tidy.
Yeah, we can try I guess. Not sure :) Maybe the right solution is that Cargo would, other than some whitelist, remove unknown variables from rustc's environment -- and the whitelist can be expanded via the build script env-tracking.
hmm I wonder if abusing the file format (from ) or encoding this extra info in a comment, would be a good idea.
You mean such that if you use we automatically tell Cargo to rebuild on changes? (That's ). But yeah, I think that would be good. Ideally this would be "well-integrated" vs. the current state of everyone having to remember to do it.

Related discussion:
text: ))], )) } <del> Ok(s) => cx.expr_call_global( </del> <ins> Some(value) => cx.expr_call_global( </ins> sp, cx.std_path(&[sym::option, sym::Option, sym::Some]), <del> vec![cx.expr_str(sp, Symbol::intern(&s))], </del> <ins> vec![cx.expr_str(sp, value)], </ins> ), }; MacEager::expr(e)
Code change:
This is still in 's build script: But the use site has been moved here: This means that won't be rebuilt when that env var changes. For the record, I haven't seen a bug from this, was just curious where may be used and spotted the mismatch. cc
Found another one: is used in but it's still mentioned by . cc Could we automate ensuring this? e.g. by searching for in tidy.
Yeah, we can try I guess. Not sure :) Maybe the right solution is that Cargo would, other than some whitelist, remove unknown variables from rustc's environment -- and the whitelist can be expanded via the build script env-tracking.
hmm I wonder if abusing the file format (from ) or encoding this extra info in a comment, would be a good idea.
You mean such that if you use we automatically tell Cargo to rebuild on changes? (That's ). But yeah, I think that would be good. Ideally this would be "well-integrated" vs. the current state of everyone having to remember to do it.

Related discussion:
text: } let sp = cx.with_def_site_ctxt(sp); <del> let e = match env::var(&*var.as_str()) { Err(_) => { </del> <ins> let value = env::var(&*var.as_str()).ok().as_deref().map(Symbol::intern); cx.parse_sess.env_depinfo.borrow_mut().insert((var, value)); let e = match value { None => { </ins> cx.span_err(sp, &msg.as_str()); return DummyResult::any(sp); } <del> Ok(s) => cx.expr_str(sp, Symbol::intern(&s)), </del> <ins> Some(value) => cx.expr_str(sp, value), </ins> }; MacEager::expr(e) }
Code change:
This is still in 's build script: But the use site has been moved here: This means that won't be rebuilt when that env var changes. For the record, I haven't seen a bug from this, was just curious where may be used and spotted the mismatch. cc
Found another one: is used in but it's still mentioned by . cc Could we automate ensuring this? e.g. by searching for in tidy.
Yeah, we can try I guess. Not sure :) Maybe the right solution is that Cargo would, other than some whitelist, remove unknown variables from rustc's environment -- and the whitelist can be expanded via the build script env-tracking.
hmm I wonder if abusing the file format (from ) or encoding this extra info in a comment, would be a good idea.
You mean such that if you use we automatically tell Cargo to rebuild on changes? (That's ). But yeah, I think that would be good. Ideally this would be "well-integrated" vs. the current state of everyone having to remember to do it.

Related discussion:
text: #![feature(bool_to_option)] #![feature(crate_visibility_modifier)] #![feature(decl_macro)] <ins> #![feature(inner_deref)] </ins> #![feature(nll)] #![feature(or_patterns)] #![feature(proc_macro_internals)]
Code change:
This is still in 's build script: But the use site has been moved here: This means that won't be rebuilt when that env var changes. For the record, I haven't seen a bug from this, was just curious where may be used and spotted the mismatch. cc
Found another one: is used in but it's still mentioned by . cc Could we automate ensuring this? e.g. by searching for in tidy.
Yeah, we can try I guess. Not sure :) Maybe the right solution is that Cargo would, other than some whitelist, remove unknown variables from rustc's environment -- and the whitelist can be expanded via the build script env-tracking.
hmm I wonder if abusing the file format (from ) or encoding this extra info in a comment, would be a good idea.
You mean such that if you use we automatically tell Cargo to rebuild on changes? (That's ). But yeah, I think that would be good. Ideally this would be "well-integrated" vs. the current state of everyone having to remember to do it.

Related discussion:
text: filename.to_string().replace(" ", " ") } <ins> // Makefile comments only need escaping newlines and ``. // The result can be unescaped by anything that can unescape `escape_default` and friends. fn escape_dep_env(symbol: Symbol) -> String { let s = symbol.as_str(); let mut escaped = String::with_capacity(s.len()); for c in s.chars() { match c { 'n' => escaped.push_str(r"n"), 'r' => escaped.push_str(r"r"), '' => escaped.push_str(r""), _ => escaped.push(c), } } escaped } </ins> fn write_out_deps( sess: &Session, boxed_resolver: &Steal<Rc<RefCell<BoxedResolver>>>,
Code change:
This is still in 's build script: But the use site has been moved here: This means that won't be rebuilt when that env var changes. For the record, I haven't seen a bug from this, was just curious where may be used and spotted the mismatch. cc
Found another one: is used in but it's still mentioned by . cc Could we automate ensuring this? e.g. by searching for in tidy.
Yeah, we can try I guess. Not sure :) Maybe the right solution is that Cargo would, other than some whitelist, remove unknown variables from rustc's environment -- and the whitelist can be expanded via the build script env-tracking.
hmm I wonder if abusing the file format (from ) or encoding this extra info in a comment, would be a good idea.
You mean such that if you use we automatically tell Cargo to rebuild on changes? (That's ). But yeah, I think that would be good. Ideally this would be "well-integrated" vs. the current state of everyone having to remember to do it.

Related discussion:
text: for path in files { writeln!(file, "{}:", path)?; } <ins> // Emit special comments with information about accessed environment variables. let env_depinfo = sess.parse_sess.env_depinfo.borrow(); if !env_depinfo.is_empty() { let mut envs: Vec<_> = env_depinfo .iter() .map(|(k, v)| (escape_dep_env(*k), v.map(escape_dep_env))) .collect(); envs.sort_unstable(); writeln!(file)?; for (k, v) in envs { write!(file, "# env-dep:{}", k)?; if let Some(v) = v { write!(file, "={}", v)?; } writeln!(file)?; } } </ins> Ok(()) })();
Code change:
This is still in 's build script: But the use site has been moved here: This means that won't be rebuilt when that env var changes. For the record, I haven't seen a bug from this, was just curious where may be used and spotted the mismatch. cc
Found another one: is used in but it's still mentioned by . cc Could we automate ensuring this? e.g. by searching for in tidy.
Yeah, we can try I guess. Not sure :) Maybe the right solution is that Cargo would, other than some whitelist, remove unknown variables from rustc's environment -- and the whitelist can be expanded via the build script env-tracking.
hmm I wonder if abusing the file format (from ) or encoding this extra info in a comment, would be a good idea.
You mean such that if you use we automatically tell Cargo to rebuild on changes? (That's ). But yeah, I think that would be good. Ideally this would be "well-integrated" vs. the current state of everyone having to remember to do it.

Related discussion:
text: pub symbol_gallery: SymbolGallery, /// The parser has reached `Eof` due to an unclosed brace. Used to silence unnecessary errors. pub reached_eof: Lock<bool>, <ins> /// Environment variables accessed during the build and their values when they exist. pub env_depinfo: Lock<FxHashSet<(Symbol, Option<Symbol>)>>, </ins> } impl ParseSess {
Code change:
This is still in 's build script: But the use site has been moved here: This means that won't be rebuilt when that env var changes. For the record, I haven't seen a bug from this, was just curious where may be used and spotted the mismatch. cc
Found another one: is used in but it's still mentioned by . cc Could we automate ensuring this? e.g. by searching for in tidy.
Yeah, we can try I guess. Not sure :) Maybe the right solution is that Cargo would, other than some whitelist, remove unknown variables from rustc's environment -- and the whitelist can be expanded via the build script env-tracking.
hmm I wonder if abusing the file format (from ) or encoding this extra info in a comment, would be a good idea.
You mean such that if you use we automatically tell Cargo to rebuild on changes? (That's ). But yeah, I think that would be good. Ideally this would be "well-integrated" vs. the current state of everyone having to remember to do it.

Related discussion:
text: gated_spans: GatedSpans::default(), symbol_gallery: SymbolGallery::default(), reached_eof: Lock::new(false), <ins> env_depinfo: Default::default(), </ins> } }
Code change:
This is still in 's build script: But the use site has been moved here: This means that won't be rebuilt when that env var changes. For the record, I haven't seen a bug from this, was just curious where may be used and spotted the mismatch. cc
Found another one: is used in but it's still mentioned by . cc Could we automate ensuring this? e.g. by searching for in tidy.
Yeah, we can try I guess. Not sure :) Maybe the right solution is that Cargo would, other than some whitelist, remove unknown variables from rustc's environment -- and the whitelist can be expanded via the build script env-tracking.
hmm I wonder if abusing the file format (from ) or encoding this extra info in a comment, would be a good idea.
You mean such that if you use we automatically tell Cargo to rebuild on changes? (That's ). But yeah, I think that would be good. Ideally this would be "well-integrated" vs. the current state of everyone having to remember to do it.

Related discussion:
text: <ins> -include ../../run-make-fulldeps/tools.mk all: EXISTING_ENV=1 EXISTING_OPT_ENV=1 $(RUSTC) --emit dep-info main.rs $(CGREP) "# env-dep:EXISTING_ENV=1" < $(TMPDIR)/main.d $(CGREP) "# env-dep:EXISTING_OPT_ENV=1" < $(TMPDIR)/main.d $(CGREP) "# env-dep:NONEXISTENT_OPT_ENV" < $(TMPDIR)/main.d $(CGREP) "# env-dep:ESCAPEnESCAPE" < $(TMPDIR)/main.d </ins>
Code change:
This is still in 's build script: But the use site has been moved here: This means that won't be rebuilt when that env var changes. For the record, I haven't seen a bug from this, was just curious where may be used and spotted the mismatch. cc
Found another one: is used in but it's still mentioned by . cc Could we automate ensuring this? e.g. by searching for in tidy.
Yeah, we can try I guess. Not sure :) Maybe the right solution is that Cargo would, other than some whitelist, remove unknown variables from rustc's environment -- and the whitelist can be expanded via the build script env-tracking.
hmm I wonder if abusing the file format (from ) or encoding this extra info in a comment, would be a good idea.
You mean such that if you use we automatically tell Cargo to rebuild on changes? (That's ). But yeah, I think that would be good. Ideally this would be "well-integrated" vs. the current state of everyone having to remember to do it.

Related discussion:
text: <ins> fn main() { env!("EXISTING_ENV"); option_env!("EXISTING_OPT_ENV"); option_env!("NONEXISTENT_OPT_ENV"); option_env!("ESCAPEnESCAPE"); } </ins>
Code change:
Sorry for the vague title. () <details<summaryRelevant errors:</summary</details<hrNote that this does not result in an ICE: Also works with shared references. <hr
Regression in – 1.44.0-nightly ( 2020-03-24) Commits:
This needs bisection ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
I suspect based on .
Assigning and removing nomination. This was .
Oops, forgot to cc
I just tried to repro in our test suite and passes... This is on unmodified master from 03:00 this morning.
Oh interesting, this only reproduces with , probably because the function is then never really compiled because it's dead code. The following also ICEs
found a fix, not sure if that is too ad-hoc though.

Related discussion:
text: _ => bug!(), }; <ins> let param_env = tcx.param_env(source.def_id()); </ins> for (local, decl) in body.local_decls.iter_enumerated() { // Ignore locals which are internal or not live if !live_locals.contains(local) || decl.internal { continue; } <ins> let decl_ty = tcx.normalize_erasing_regions(param_env, decl.ty); </ins> // Sanity check that typeck knows about the type of locals which are // live across a suspension point <del> if !allowed.contains(&decl.ty) && !allowed_upvars.contains(&decl.ty) { </del> <ins> if !allowed.contains(&decl_ty) && !allowed_upvars.contains(&decl_ty) { </ins> span_bug!( body.span, "Broken MIR: generator contains type {} in MIR,
Code change:
Sorry for the vague title. () <details<summaryRelevant errors:</summary</details<hrNote that this does not result in an ICE: Also works with shared references. <hr
Regression in – 1.44.0-nightly ( 2020-03-24) Commits:
This needs bisection ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
I suspect based on .
Assigning and removing nomination. This was .
Oops, forgot to cc
I just tried to repro in our test suite and passes... This is on unmodified master from 03:00 this morning.
Oh interesting, this only reproduces with , probably because the function is then never really compiled because it's dead code. The following also ICEs
found a fix, not sure if that is too ad-hoc though.

Related discussion:
text: <ins> // check-pass // edition:2018 // compile-flags: --crate-type=lib pub async fn test() { const C: usize = 4; foo(&mut [0u8; C]).await; } async fn foo(_: &mut [u8]) {} </ins>
Code change:
Especially the fact that the lines are broken up seems like a bug. () Errors: modify labels: A-diagnostics, C-bug, D-papercut, T-compiler
There are two things here have a label that has embedded newlines which causes the broken down ASCII art should find a way to reverse the order in which multiline spans are sorted, but this will require handling multiple labels. The current order is optimized for not having to tweak the label positions, but when no labels are involved, we could do much better.
So, using raw text from the program as part of our label feels like a hack. We should try to come up with another way of getting a name (and falling back to a description like "async block" or something if that doesn't work). Failing a good way of doing that, I guess we can scan the program text for newlines and only use it if there aren't any..
Agree, we should never be using snippets in labels. The change needs to happen in You have the which lets you get the and from there use an appropriate description. I think there is an open PR that adds description to all variants.

Related discussion:
text: <ins> // edition:2018 // #70935: Check if we do not emit snippet // with newlines which lead complex diagnostics. use std::future::Future; async fn baz<T>(_c: impl FnMut() -> T) where T: Future<Output=()> { } fn foo(tx: std::sync::mpsc::Sender<i32>) -> impl Future + Send { //~^ ERROR: future cannot be sent between threads safely async move { baz(|| async{ foo(tx.clone()); }).await; } } fn bar(_s: impl Future + Send) { } fn main() { let (tx, _rx) = std::sync::mpsc::channel(); bar(foo(tx)); } </ins>
Code change:
Especially the fact that the lines are broken up seems like a bug. () Errors: modify labels: A-diagnostics, C-bug, D-papercut, T-compiler
There are two things here have a label that has embedded newlines which causes the broken down ASCII art should find a way to reverse the order in which multiline spans are sorted, but this will require handling multiple labels. The current order is optimized for not having to tweak the label positions, but when no labels are involved, we could do much better.
So, using raw text from the program as part of our label feels like a hack. We should try to come up with another way of getting a name (and falling back to a description like "async block" or something if that doesn't work). Failing a good way of doing that, I guess we can scan the program text for newlines and only use it if there aren't any..
Agree, we should never be using snippets in labels. The change needs to happen in You have the which lets you get the and from there use an appropriate description. I think there is an open PR that adds description to all variants.

Related discussion:
text: <ins> error: future cannot be sent between threads safely --> $DIR/issue-70935-complex-spans.rs:10:45 | LL | fn foo(tx: std::sync::mpsc::Sender<i32>) -> impl Future + Send { |                                             ^^^^^^^^^^^^^^^^^^ future created by async block is not `Send` | = help: the trait `Sync` is not implemented for `Sender<i32>` note: future is not `Send` as this value is used across an await --> $DIR/issue-70935-complex-spans.rs:13:9 | LL | /         baz(|| async{ LL | |             foo(tx.clone()); LL | |         }).await; | |________________^ first, await occurs here, with the value maybe used later... note: the value is later dropped here --> $DIR/issue-70935-complex-spans.rs:15:17 | LL |         }).await; |                 ^ note: this has type `[closure@$DIR/issue-70935-complex-spans.rs:13:13: 15:10]` which is not `Send` --> $DIR/issue-70935-complex-spans.rs:13:13 | LL |           baz(|| async{ |  _____________^ LL | |             foo(tx.clone()); LL | |         }).await; | |_________^ error: aborting due to previous error </ins>
Code change:
Especially the fact that the lines are broken up seems like a bug. () Errors: modify labels: A-diagnostics, C-bug, D-papercut, T-compiler
There are two things here have a label that has embedded newlines which causes the broken down ASCII art should find a way to reverse the order in which multiline spans are sorted, but this will require handling multiple labels. The current order is optimized for not having to tweak the label positions, but when no labels are involved, we could do much better.
So, using raw text from the program as part of our label feels like a hack. We should try to come up with another way of getting a name (and falling back to a description like "async block" or something if that doesn't work). Failing a good way of doing that, I guess we can scan the program text for newlines and only use it if there aren't any..
Agree, we should never be using snippets in labels. The change needs to happen in You have the which lets you get the and from there use an appropriate description. I think there is an open PR that adds description to all variants.

Related discussion:
text: --> $DIR/issue-65436-raw-ptr-not-send.rs:14:9 | LL |         bar(Foo(std::ptr::null())).await; <del> |         ^^^^^^^^----------------^^^^^^^^- `std::ptr::null()` is later dropped here |         |       | |         |       has type `*const u8` which is not `Send` |         await occurs here, with `std::ptr::null()` maybe used later </del> <ins> |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ first, await occurs here, with `std::ptr::null()` maybe used later... note: `std::ptr::null()` is later dropped here --> $DIR/issue-65436-raw-ptr-not-send.rs:14:41 | LL |         bar(Foo(std::ptr::null())).await; |                 ----------------        ^ |                 | |                 has type `*const u8` which is not `Send` </ins> help: consider moving this into a `let` binding to create a shorter lived borrow --> $DIR/issue-65436-raw-ptr-not-send.rs:14:13 |