jiebi/CodeConvo huggingface dataset:
Change:
# the stamp in the source dir. $$(LLVM_STAMP_$(1)): $(S)src/rustllvm/llvm-auto-clean-trigger @$$(call E, make: cleaning llvm) <del> $(Q)$(MAKE) clean-llvm </del> <ins> $(Q)$(MAKE) clean-llvm$(1) </ins> @$$(call E, make: done cleaning llvm) touch $$@

Discussion:
This happens on our nightly and dist bots periodically: Here's what configure looks like:
Presumably it's complaining that can't be found, but the makefiles look right to me. Hard to reproduce.
I've only ever seen this get reproduced during an LLVM upgrade on a multi-host builder. I've only sporadically been able to reproduce locally, and if you re-make after the error occurs it does not repeat itself. The only sequence of events I've seen to trigger this is: LLVM in the rust repo (for multiple hosts). LLVM in the rust repo. LLVM again (run make -j), see the error.
Perhaps this is because the rules for the host-specific llvm stamp call the non-host-specific target, so when the build gets to the second LLVM it deletes the just-built LLVM.
Change:
let scope = Scope::TraitRefBoundary { s: self.scope }; self.with(scope, |this| { walk_list!(this, visit_generic_param, generics.params); <del> for param in generics.params { match param.kind { GenericParamKind::Lifetime { .. } => {} GenericParamKind::Type { default, .. } => { if let Some(ty) = default { this.visit_ty(ty); } } GenericParamKind::Const { ty, default } => { this.visit_ty(ty); if let Some(default) = default { this.visit_body(this.tcx.hir().body(default.body)); } } } } </del> walk_list!(this, visit_where_predicate, generics.predicates); }) }

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
deferred_generator_interiors: RefCell::new(Vec::new()), opaque_types: RefCell::new(Default::default()), opaque_types_vars: RefCell::new(Default::default()), <del> implicit_region_bound: None, </del> body_id, } }

Discussion:
I tried this code: I expected to see this happen: On Rust 1.44.0, this compiles. Instead, this happened: :
For reproduction, the following is used.
This is a regression from stable to nightly.
Let’s bisect this and try to find an MCVE. 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
The code succeeds to compile on 1.44.1 and fails on 1.45, so this is actually a stable-to-stable regression.
Assigning as and removing .
So far I've reduced it to this, which depends only on (without the feature):
: searched nightlies: from nightly-2020-04-20 to nightly-2020-06-02 regressed nightly: nightly-2020-05-25 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsregressed in
The reproduction does not produce error in . However, I find this throws error on this nightly, as well as on 1.45.0. Here is an even shorter one: The line seems critical. Without this, there will be no reproduction with both snippets. This is also reproducible on the nightly .
cc
The PR that made my reduced code (without ) start successfully compiling again is , in case it helps show what's going on. <details<summaryFull bisect-rustc</summarysearched nightlies: from nightly-2020-05-25 to nightly-2020-07-17 regressed nightly: nightly-2020-06-24 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </summary
Single-crate repro:
I can volunteer myself for looking into the issue. I have a question about the region inference.

Is there a way to visualize, or trace the region inference? Guidance and mentoring instructions are very welcome. :smile:
Change:
} pub fn check(root_path: &Path, bless: bool, bad: &mut bool) { <ins> let issues_txt_header = r#"============================================================ ⚠️⚠️⚠️NOTHING SHOULD EVER BE ADDED TO THIS LIST⚠️⚠️⚠️ ============================================================ "#; </ins> let path = &root_path.join("tests"); check_entries(&path, bad); // the list of files in ui tests that are allowed to start with `issue-XXXX` // BTreeSet because we would like a stable ordering so --bless works <del> let issues_list = include!("issues.txt").map(|path| path.replace("/", std::path::MAIN_SEPARATOR_STR)); let issues: Vec<String> = Vec::from(issues_list.clone()); let is_sorted = issues.windows(2).all(|w| w[0] < w[1]); </del> <ins> let mut prev_line = ""; let mut is_sorted = true; let allowed_issue_names: BTreeSet<_> = include_str!("issues.txt") .strip_prefix(issues_txt_header) .unwrap() .lines() .map(|line| { if prev_line > line { is_sorted = false; } prev_line = line; line }) .collect(); </ins> if !is_sorted && !bless { tidy_error!( bad,

Discussion:
1) modify some code of 2) run =for the first ~6 seconds, tidy is being built in parallel, but for the remaining ~1 minute and 9 seconds llvm is doing some sequential work. I'm not sure what takes so long, there must be one epic cgu that it is processing or something?
I wanted to check the problem but couldn't reproduce it locally.
! :thinking:
aha lol! it boils down to , an array of ~4K static &strs which is being inlined into the code it seems. When I cut the file down to just a handful of items, compilation time reduces to 7 seconds :upsidedownface: cc I guess?
Can you check if reduces this slowness?
It does indeed.
Ah, but if people give the tests meaningful names, it will reduce the build time. :relieved:
Change:
check_cast(fcx, &**e, &**t, id, expr.span); } ast::ExprVec(ref args) => { <del> let t: ty::t = fcx.infcx().next_ty_var(); </del> <ins> let (check, t) = check_fn_for_vec_elements_expected(fcx, expected); </ins> for e in args.iter() { <del> check_expr_has_type(fcx, &**e, t); </del> <ins> check(fcx, &**e, t); </ins> } let typ = ty::mk_vec(tcx, ty::mt {ty: t, mutbl: ast::MutImmutable}, Some(args.len()));

Discussion:
fails to compile: cc
What does the l-wrong label mean here?
It means that the current behavior of the compiler is incorrect.
Change:
}); buf.push_str(&part.snippet); let cur_hi = sm.lookup_char_pos(part.span.hi()); <del> if cur_hi.line == cur_lo.line && !part.snippet.is_empty() { // Account for the difference between the width of the current code and the // snippet being suggested, so that the *later* suggestions are correctly // aligned on the screen. acc += len - (cur_hi.col.0 - cur_lo.col.0) as isize; } </del> <ins> // Account for the difference between the width of the current code and the // snippet being suggested, so that the *later* suggestions are correctly // aligned on the screen. Note that cur_hi and cur_lo can be on different // lines, so cur_hi.col can be smaller than cur_lo.col acc += len - (cur_hi.col.0 as isize - cur_lo.col.0 as isize); </ins> prev_hi = cur_hi; prev_line = sf.get_line(prev_hi.line - 1); for line in part.snippet.split('n').skip(1) {

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --code is from clippy: :warning: you need rustc build with debug assertions :warning: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Run into this while fuzzing, here is a minimized test case: Note that you need rustc with debug assertions enabled. Reproduced in nightly 2022-02-25.
Another test case:
OP and seem to be fixed on latest master (). now outputs "Span must not be empty and have no suggestion" <details<summarybacktrace</summary</details
I can confirm that both of my examples have been fixed on latest master () so this issue can be closed.
Change:
<del> Subproject commit aeadf1562c024d3c5421e61dc6b8d48c2d7902f5 </del> <ins> Subproject commit 5f28fda13efeb85097fe082af4b4827a58b0ecf6 </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and -- nominating for prioritization.
Check-in from compiler triage team: looks like we have a pending fix in , thanks !
Change:
v.sum(); }) } <ins> #[bench] pub fn no_iter(_: &mut Bencher) {} </ins> }

Discussion:
functions are run multiple times. Some benchmark functions might depend on some runtime initialisation which may fail. For example: Will print “Benchmarks on even hours are forbidden!” a lot of times. If one opts to not report set-up failure, the benchmark function just keeps processor hot for a while without actually benchmarking anything (and reporting 0ns/iter anyway). Would it be sensible to (one of possible solutions): Not run the same function multiple times, since iteration is done by ; Not run the same again if is not called at least once; Provide a method on to cancel all subsequent runs of the function? Or maybe my approach is incorrect?
If one tries to keep benchmarks in separate files and opts for to cancel further runs of the function, the panic will abort the whole benchmark process (i.e. including the benchmarks in other executables).
For , we want to run on the CI infrastructure to ensure all the tests build. However, we don't want to actually benchmark on the CI infrastructure, because the CI infrastructure isn't reliable enough for benchmarking. Thus, doing more than one iteration on the CI infrastructure just wastes time. And, that time, in particular the wall time, negatively affects my other repos, because generally CI services like Travis CI and Appveyor only allow one project to build at a time, for their free open source tiers. Further, even out side of CI infrastructure, we want contributors to run the benchmarks before sending PRs. But, it's not reasonable to expect them to wait through many minutes of perf tests before asking for a PR. Here are two ideas: a that overrides the default targeted benchmark execution time so that we can write to run tests once. a so we can write . I prefer because that also might help with
Never mind. I just learned that will do exactly what I want: run the benchmarks once each.
This was bugging me, so I implemented the first proposed option: As this is my first real rust code, I imagine its pretty bad quality. A fist attempt is here: I'll clean it up a bit, give it some more testing, then send in a pull request unless anyone offers any opinions before I get that far.
Does anyone have an example on how to use this feature ? I'd like to run a benchmark only once.
:frowning_face:
Change:
Some("std::ops::Add"), ), hir::BinOpKind::Sub => ( <del> format!("cannot substract `{}` from `{}`", rhs_ty, lhs_ty), </del> <ins> format!("cannot subtract `{}` from `{}`", rhs_ty, lhs_ty), </ins> Some("std::ops::Sub"), ), hir::BinOpKind::Mul => (

Discussion:
Got this error message when trying to compile a crate using rustc 1.42.0-nightly ( 2020-01-07). The text reads substract instead of subtract.
if you want to contribute a fix, you would just need to modify these three lines:
thanks for your response, I submitted a PR to fix this.
Change:
bb0: { StorageLive(_1);                 // scope 0 at $DIR/const_prop_miscompile.rs:+1:9: +1:14 <del> -         _1 = (const 1_i32,);             // scope 0 at $DIR/const_prop_miscompile.rs:+1:17: +1:21 +         _1 = const (1_i32,);             // scope 0 at $DIR/const_prop_miscompile.rs:+1:17: +1:21 </del> <ins> _1 = (const 1_i32,);             // scope 0 at $DIR/const_prop_miscompile.rs:+1:17: +1:21 </ins> StorageLive(_2);                 // scope 1 at $DIR/const_prop_miscompile.rs:+2:6: +2:14 _2 = &mut (_1.0: i32);           // scope 1 at $DIR/const_prop_miscompile.rs:+2:6: +2:14 (*_2) = const 5_i32;             // scope 1 at $DIR/const_prop_miscompile.rs:+2:5: +2:18

Discussion:
This code has UB under Stacked Borrows in Miri, but is fine with , and it should print However, under and above, it prints : cc
Here's a pure-surface Rust reproduction
any guess which MIR opt might be the culprit here?
Even more minimized reproducer: My first guess would be that some MIR analysis assumes that means that no pointer to can exist any more -- with Stacked Borrows that was true, but not with Tree Borrows. I usually push back against making Stacked Borrows assumptions in optimizations but looks like something slipped through? Cc
Even stranger, with Rust 1.69 we get . This goes back all the way to ; before that, we didn't have . Only beta and nightly without optimizations seem to do this correctly.
Does this look like the bad optimization?
yes, very much so. Specifically the is wrong, the rest then follows from that. Did ConstProp never learn that locals that have their address taken cannot be propagated?
I'm about to be busy for a few hours, so if someone else wants to bisect what changed with they should do that. I'll check back later.
I've been suspecting such a bug without managing to reproduce it for a few months. The bug is in the visitor, which mistreats place context. I can make a targeted fix in the hour.
I'm curious, how did you come up with this example?
I'm making a fuzzer targeting custom MIR :D It's still quite incomplete and currently hosted on an ETH Zürich private GitLab instance I guess I should make a public mirror on GitHub soon...
That is awesome! This is exactly the kind of stuff I was hoping to find with one.
Ah so should we report these? I think I read somewhere that custom mir is likely to get wrong and would always cause crashes then or something which is why I have ignored all of the / ICEs that I came across.
This isn't an ICE, this is a change in behavior due to enabling an optimization.
ah right sorry, I was confused with
Change:
/// Encodes a FnSig using the Itanium C++ ABI with vendor extended type qualifiers and types for /// Rust types that are not used at the FFI boundary. <ins> #[instrument(level = "trace", skip(tcx, dict))] </ins> fn encode_fnsig<'tcx>( tcx: TyCtxt<'tcx>, fn_sig: &FnSig<'tcx>,

Discussion:
I've got a fix for this that I'll be uploading in a minute or two, I'm filing the issue to claim an issue number for the test. : </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This seems to be a duplicate of .
Change:
|      ^ the trait `Copy` is not implemented for `T` | = note: the `Copy` trait is required because this value will be copied for each element of the array <ins> = help: consider using `core::array::from_fn` to initialize the array = help: see https://doc.rust-lang.org/stable/std/array/fn.from_fn.html# for more information </ins> help: consider restricting type parameter `T` | LL | fn g<T: std::marker::Copy, const N: usize>(x: T) -> [T; N] {

Discussion:
For this snippet (): rustc gives: Since , for const-able values, rustc suggests the creation of a constant binding. Here this is not possible because is not const fn. However, we can suggest instead.
Personally, I prefer over a separate binding. Even in the case, the generated code will call the initialization function many times. Maybe in the case where bindings are possible, we can suggest both? Where they are not possible, we don't suggest anything right now, so at the least we should suggest there. what do you think?
Once is stable we can suggest that :3. But until then sounds reasonable.
Agreed, good point about . It seems to have a stabilization PR open with an FCP, which is blocked: . Maybe there might be progress on it this month: . Even if we stabilize inline const, it might make sense to wait with suggesting it for a while so that we don't make code depend on the latest MSRV immediately. So therefore, I think that it might still make sense to implement this in the meantime.
I think this should (in the future) suggest  instead, since the function would only be called once if were , whereas calls it for every element.
Change:
<ins> // Copyright 2012-2013 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. fn main() { 1 = 2; //~ ERROR illegal left-hand side expression 1 += 2; //~ ERROR illegal left-hand side expression (1, 2) = (3, 4); //~ ERROR illegal left-hand side expression let (a, b) = (1, 2); (a, b) = (3, 4); //~ ERROR illegal left-hand side expression None = Some(3); //~ ERROR illegal left-hand side expression } </ins>

Discussion:
When compiling the following code: I get the error: Compiled with:
I also just hit this today. An even simpler test case:
Reproduced with (both cases). Interestingly, rustc warns that X0 and X1 don't need to be mutable on the first case.
Similar ICE with structs:
The simplest case I think:
It's because assumes only one of will come but it met . So seems easy to fix, but what about tuples/structs? is also not allowed, right? I initially thought it is allowed because is. But previous discussions seem that it's not: , .
My impression is that isn't supposed to be allowed. That said, it would be kinda neat if it was. Right now I'm writing the same 3 lines over and over that look like and I'd love to be able to just say
I forgot to mention about mutability; currently is obsolete, and (heard from irc) it may be because it's confusing that immutable tuples are with . I don't know any previous discussion about it. anyone? If it is true, should be disallowed in the same manner, because is immutable while and are. Anyway, I agree with it's not cool to unpack manually.
Clearly something in the compiler is not checking that the LHS of an assignment is actually an lvalue. Kind of amusing. Rather surprising that this gets through borrowck, I'll have to look at that. It's probably assuming that an earlier pass would have caught such cases. Anyway, it'd be nice to permit , certainly, but it is not currently allowed. I think that'd be a post-Rust 1.0 sort of extension. I previously thought it would introduce horrible ambiguities into parsing, but I realize now that it would not, so long as you only have two cases: , which assigns to a pattern, and which always declares new bindings, and , which always overwrites existing lvalues.
Change:
tcx.ensure().type_of(def_id); tcx.ensure().impl_trait_header(def_id); tcx.ensure().predicates_of(def_id); <ins> tcx.ensure().associated_items(def_id); </ins> } hir::ItemKind::Trait(..) => { tcx.ensure().generics_of(def_id); tcx.ensure().trait_def(def_id); tcx.at(it.span).super_predicates_of(def_id); tcx.ensure().predicates_of(def_id); <ins> tcx.ensure().associated_items(def_id); </ins> } hir::ItemKind::TraitAlias(..) => { tcx.ensure().generics_of(def_id);

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'still mutable'', 'thread 'rustc' panicked at 'still mutable'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [associatedtypesforimpltraitsinassociatedfn] creating associated items for opaque types returned by [associateditemdefids] collecting associated items or fields of [associateditems] collecting associated items of [opaquetypesdefinedby] computing the opaque types defined by [typeck] type-checking [analysis] running analysis passes on this crate --
cc , also see for a similar regression fixed by nn
Not sure that was actually fixed. The PR seems entirely unrelated
on a nighty before , this errored with
Oh I think I see how that got "fixed". It bailed out of compilation early enough not to hit the ICE anymore by emitting stashed errors earlier. So it got hidden again, and now it's back againbecause of some subtle change in query ordering. We probably need to run this query explicitly for all traits and impls before the big def id freeze.
Change:
check_suspend_tys(tcx, &generator_layout, &body); <del> generator_layout </del> <ins> Some(generator_layout) </ins> } impl<'tcx> MirPass<'tcx> for StateTransform {

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
regression in cc
Hmm, I guess that before this function just received broken MIR and carried on, but exited due to the HIR errors without trying to dump it. Now that we return an error body for broken code we're getting a panic
Change:
let origin = Point { x: 0, y: 0 }; match origin { <del> Point { y: y, .. } => println!("y is {}", y), </del> <ins> Point { y, .. } => println!("y is {}", y), </ins> } ```

Discussion:
The page doesn't explain that it's possible to match compound data in this way: Currently only this form is covered: The latter form results in compiler warnings (). I'm not sure whether it should be avoided for that reason.
fixed this
Change:
/// Otherwise, logs an error with cx.span_err and returns None. fn parse(cx: &mut ExtCtxt, tts: &[ast::TokenTree]) -> Option<String> { let mut parser = cx.new_parser_from_tts(tts); <del> let entry = cx.expand_expr(parser.parse_expr()); </del> <ins> let entry = cx.expander().fold_expr(parser.parse_expr()); </ins> let regex = match entry.node { ast::ExprLit(lit) => { match lit.node {

Discussion:
I believe this should output the string : But I get this error: Rust version:
Note that standard recursive macros work fine, e.g., And outputs . Maybe the bug here is that expanding macros within other macros is using an older environment that doesn't include the name ?
It's even worse than that. only uses the compiler built-in macros:
I think this might be a dupe of
Does fixing mean that also gets fixed? I wouldn't assume so, but it might be possible depending on the implementation. (Sorry I missed that issue. I searched for 'recursive macro' instead of 'nested macro'!)
both and use , which doesn't work with non-builtin macros.
Right. I'm referring to the recursive aspect. Wasn't sure if that would make a difference. (I just don't know enough about how macros are expanded to know. Pure guesswork on my part.)