jiebi/CodeConvo huggingface dataset:
Change:
let mut cmd = Command::new(rustc); cmd.args(&args) <del> .arg("--cfg") .arg(format!("stage{}", stage)) </del> .env(bootstrap::util::dylib_path_var(), env::join_paths(&dylib_path).unwrap()); let mut maybe_crate = None; <ins> // Non-zero stages must all be treated uniformly to avoid problems when attempting to uplift // compiler libraries and such from stage 1 to 2. if stage == "0" { cmd.arg("--cfg").arg("bootstrap"); } </ins> // Print backtrace in case of ICE if env::var("RUSTC_BACKTRACE_ON_ICE").is_ok() && env::var("RUST_BACKTRACE").is_err() { cmd.env("RUST_BACKTRACE", "1");

Discussion:
We should only pass stage0 in general, should be sufficient for all use cases. cc for awareness and in case there's any concerns
Change:
<ins> // Copyright 2015 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(type_macros)] // (typeof used because it's surprisingly hard to find an unparsed token after a stmt) macro_rules! m { () => ( i ; typeof );   //~ ERROR `typeof` is a reserved keyword //~| ERROR macro expansion ignores token `typeof` //~| ERROR macro expansion ignores token `typeof` //~| ERROR macro expansion ignores token `;` //~| ERROR macro expansion ignores token `;` //~| ERROR macro expansion ignores token `i` } m!();               //~ NOTE the usage of `m!` is likely invalid in item context fn main() { let a: m!();    //~ NOTE the usage of `m!` is likely invalid in type context let i = m!();   //~ NOTE the usage of `m!` is likely invalid in expression context match 0 { m!() => {}  //~ NOTE the usage of `m!` is likely invalid in pattern context } m!();           //~ NOTE the usage of `m!` is likely invalid in statement context } </ins>

Discussion:
This compiles: I expected this to be rejected, simply because doesn't parse as a type.

afaik, it's because the context where you're using the macro (expr, item, etc.) stopped parsing before that token. We should mention that context.
Is this fixed? I think this was fixed the referenced pull request.
I'd prefer a message like
Change:
where T: TypeFoldable<'tcx>, { <del> struct LateBoundRegionNameCollector<'a>(&'a mut FxHashSet<Symbol>); impl<'tcx> ty::fold::TypeVisitor<'tcx> for LateBoundRegionNameCollector<'_> { </del> <ins> debug!("prepare_late_bound_region_info(value: {:?})", value); struct LateBoundRegionNameCollector<'a, 'tcx> { used_region_names: &'a mut FxHashSet<Symbol>, type_collector: SsoHashSet<Ty<'tcx>>, } impl<'tcx> ty::fold::TypeVisitor<'tcx> for LateBoundRegionNameCollector<'_, 'tcx> { type BreakTy = (); </ins> fn visit_region(&mut self, r: ty::Region<'tcx>) -> ControlFlow<Self::BreakTy> { <ins> debug!("LateBoundRegionNameCollector::visit_region(r: {:?}, address: {:p})", r, &r); </ins> if let ty::ReLateBound(_, ty::BoundRegion { kind: ty::BrNamed(_, name), .. }) = *r { <del> self.0.insert(name); </del> <ins> self.used_region_names.insert(name); </ins> } r.super_visit_with(self) } <ins> // We collect types in order to prevent really large types from compiling for // a really long time. See issue #83150 for why this is necessary. fn visit_ty(&mut self, ty: Ty<'tcx>) -> ControlFlow<Self::BreakTy> { debug!("LateBoundRegionNameCollector::visit_ty(ty: {:?}", ty); let not_previously_inserted = self.type_collector.insert(ty); if not_previously_inserted { ty.super_visit_with(self) } else { ControlFlow::CONTINUE } } </ins> } self.used_region_names.clear(); <del> let mut collector = LateBoundRegionNameCollector(&mut self.used_region_names); </del> <ins> let mut collector = LateBoundRegionNameCollector { used_region_names: &mut self.used_region_names, type_collector: SsoHashSet::new(), }; </ins> value.visit_with(&mut collector); self.region_index = 0; }

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: program either compiled successful or compiler generate an error Instead, this happened: rustc eats 100% CPU for several minutes, but nothing generated. I compile this code using both and before I began to write this issue, but compiler do not compile even after this issue is submitted. <!-- 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<summaryBacktrace</summary<p</p</details
Slightly smaller:
Actually, I am very curious that, why rustc do not reach the recursion limit.
Oh sorry, you're right, it does hit the recursion limit if I let it run long enough (about 10 seconds).
Here's a proper minimization:
Partial backtrace of the hang: <details</details
So it actually hangs while trying to print the overflow error :laughing:
Bisected:
looks suspicious.
hang but generate a failed massage:
Assigning and removing .
Change:
assert_eq!(x.get(), 1); } <ins> #[test] fn test_slice_fill_with_uninit() { // This should not UB. See #87891 let mut a = [MaybeUninit::<u8>::uninit(); 10]; a.fill(MaybeUninit::uninit()); } </ins>

Discussion:
This was reported by on Zulip: https://rust- Demo:
I think the fix should be as simple as using instead of as the type of - that will work regardless of whether or not the memory is initialized.
The other option is just removing the case entirely. Llvm is smart enough to turn that loop in the branch into a memset.
It does help the gcc codgen backend at least as it can't manage to produce a memset for u64 so I assume it would fail to do the same for u8 if it weren't for that specialization.
It also fails for the case:
It does call memset if you don't pass an array.
I'd think the intrinsic could easily have its type changed to take a , which would let one solve this problem. The stable function of course cannot be changed, though...
Reopening to track adding a test. (That's the standard procedure for this, isn't it?)
I would like to try working on adding the test, though this will be my first contribution so I'd need some guidance. I'm assuming this would be a miri test as it's related to correctness--may I DM you on Zulip? (or would someone else be more suitable?)
great. :) Miri runs the libcore test suite via So adding it as a test in libcore makes most sense, IMO.
Change:
<ins> error: unexpected token: `|| { static d: _ = || 1; }` --> $DIR/issue-90873.rs:1:6 | LL | #![u=||{static d=||1;}] |      ^^^^^^^^^^^^^^^^^ error: unexpected token: `{ impl std::ops::Neg for i8 { } }` --> $DIR/issue-90873.rs:7:6 | LL | #![a={impl std::ops::Neg for i8 {}}] |      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: cannot find attribute `u` in this scope --> $DIR/issue-90873.rs:1:4 | LL | #![u=||{static d=||1;}] |    ^ error: cannot find attribute `a` in this scope --> $DIR/issue-90873.rs:7:4 | LL | #![a={impl std::ops::Neg for i8 {}}] |    ^ error[E0601]: `main` function not found in crate `issue_90873` --> $DIR/issue-90873.rs:1:1 | LL | / #![u=||{static d=||1;}] LL | | LL | | LL | | LL | | LL | | LL | | #![a={impl std::ops::Neg for i8 {}}] | |____________________________________^ consider adding a `main` function to `$DIR/issue-90873.rs` error: missing type for `static` item --> $DIR/issue-90873.rs:1:16 | LL | #![u=||{static d=||1;}] |                ^ help: provide a type for the item: `d: <type>` error: aborting due to 6 previous errors For more information about this error, try `rustc --explain E0601`. </ins>

Discussion:
I'm seeing an internal compiler error on the following input, found by : The ICE happens after correctly reporting a few other errors, because the code is nonsense, so low priority. Affected versions: I tried nightly 2021-11-12 and stable 1.56.1 and they both show the same ICE. <details<summary<strongBacktrace</strong</summary<p</p</detailsAlso note how there is one additional error below the backtrace, not sure if that's expected.
Thanks for the bug report, could this be related to the recent HIR map/lowering refactorings?
This issue looks very similar to , but the examples from there don't panic anymore.

<!-- 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. --I got a very large poc file, and reduce it into following code. But after reducing (via a simple delta debugging tech), the code looks kind of confusing. Please let me know if anyone prefers a better-formed but long test-case, and I will try me best to get one. md5: <!-- 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. --The bug is reproduced with nightly and beta versions, but not with stable version. : The output is from nightly. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This can be "solved" by using and create a instead of panicking.
Assigning as discussed as part of the and removing .
A reproduction with fewer errors:
The provided examples do not panic anymore, can this issue be closed or does it need tests?
lets keep it open purely to track adding regression tests for these.
Change:
<ins> // run-rustfix #![allow(nonstandard_style, unused_variables, unused_mut)] #![deny(non_shorthand_field_patterns)] struct Foo { x: isize, y: isize, } fn main() { { let Foo { x, //~ ERROR the `x:` in this pattern is redundant ref y, //~ ERROR the `y:` in this pattern is redundant } = Foo { x: 0, y: 0 }; let Foo { x, ref y, } = Foo { x: 0, y: 0 }; } { const x: isize = 1; match (Foo { x: 1, y: 1 }) { Foo { x: x, ..} => {}, _ => {}, } } { struct Bar { x: x, } struct x; match (Bar { x: x }) { Bar { x: x } => {}, } } { struct Bar { x: Foo, } enum Foo { x } match (Bar { x: Foo::x }) { Bar { x: Foo::x } => {}, } } { struct Baz { x: isize, y: isize, z: isize, } let Baz { mut x, //~ ERROR the `x:` in this pattern is redundant ref y, //~ ERROR the `y:` in this pattern is redundant ref mut z, //~ ERROR the `z:` in this pattern is redundant } = Baz { x: 0, y: 0, z: 0 }; } } </ins>

Discussion:
Code: output: Note that in the attempted fix is incorrect syntax (it ate a colon). Edit: it probably actually isn't. Version info:
thanks for feedback :) it seems a rustfix bug, could you please file a issue there? cc
Will do. Is it intentional that suggests filing a bug in this repo (see the error message), or should that be changed?
This is the correct place to file the issue, it is a bug in . The issue is that the lint is providing a bad suggestion. Either the span needs to encompass the entire binding, or the suggested text needs to be the empty string.
Change:
<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. extern crate testcrate; use std::mem; #[link(name = "test", kind = "static")] extern { fn give_back(tu: testcrate::TestUnion) -> u64; } fn main() { let magic: u64 = 0xDEADBEEF; // Let's test calling it cross crate let back = unsafe { testcrate::give_back(mem::transmute(magic)) }; assert_eq!(magic, back); // And just within this crate let back = unsafe { give_back(mem::transmute(magic)) }; assert_eq!(magic, back); } </ins>

Discussion:
Spidermonkey's type is a union of size 64 bits. We represent this as in Rust. This works great on 64bit platforms. On 32bit platforms, the values get mangled when passed to the C library functions. This seems to be an ABI issue. We've encountered this before with which was about 32bit ARM. This gist contains sample programs and the generated IR for minimal test programs using rust-mozjs: Note that you will need my 32bit branch of rust-mozjs: You can put debugging printfs in in to see the value on the C side. The only notable thing I see in the IR is that the clang IR has when passing the . This seems like a Rust bug, but I'd also be interested if there is a workaround that will work on all platforms.
cc
cc me
Change:
<ins> //@ run-rustfix fn main() { let s = "123"; println!({}, "sss", s); //~^ ERROR format argument must be a string literal println!({}); //~^ ERROR format argument must be a string literal println!(s, "sss", s, {}); //~^ ERROR format argument must be a string literal println!((), s, {}); //~^ ERROR format argument must be a string literal } </ins>

Discussion:
Cargo does not seem to be detecting the {} outside brackets and provides an incredibly strange fix instead. No response the file is from here: You will need serdejson crate. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
it's worth noting that is a valid rust expression, it evaluates to the empty tuple. this is perfectly valid code: minimal repro:
huh, didn't know that. good to know ig
I think it is worth special casing this in diagnostics though, if someone wanted to print a unit type (for some reason?) they probably should use the value or just embed it directly in the format string. An empty expression as the first argument of a format macro is almost certainly a mistake.
claim
The PR that closed this doesn't seem to actually apply the wanted fix, this should be reopened.
Hello, thank you very much for the suggestion. My idea is to find a slightly more general solution instead of special treatment for rare cases. If you think it should be modified as , I completely agree with reopening the issue. :relaxed:
Change:
<ins> // Copyright 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. // Test that we are able to compile calls to associated fns like // `decode()` where the bound on the `Self` parameter references a // lifetime parameter of the trait. This example indicates why trait // lifetime parameters must be early bound in the type of the // associated item. pub enum Value<'v> { A(&'v str), B, } pub trait Decoder<'v> { fn read(&mut self) -> Value<'v>; } pub trait Decodable<'v, D: Decoder<'v>> { fn decode(d: &mut D) -> Self; } impl<'v, D: Decoder<'v>> Decodable<'v, D> for () { fn decode(d: &mut D) -> () { match d.read() { A(..) => (), B => Decodable::decode(d), } } } pub fn main() { } </ins>

Discussion:
cc I think this is related to . Here's the example code: It errors with:
I just got similar ICE with extern mod. a.rs: b.rs: Building b.rs gives (Yes, I was using .) It worked on rust revision but not on revision .
Another variant: produces:
Seems likely to be related, yes. I'll take a look today. Probably something funky in the handling of static methods. Possibly related to what was trying to address in (though maybe not -- I'm sad to say I ddn't fully understand the problem there, was too caught up in trying to finish with !)
Here's an example relevant to me:
So these examples are a mix of problems, but they are all related to . The only one of these examples I expect to not ICE is the first one. The others don't work because of . The basic problem is that you cannot have a function which has a lifetime parameter that appears in a trait bound (yet -- I want to fix this, see for details). Interestingly, the reason that we have this problem with the first example, is that static functions like get translated into functions with lifetime parameters that appear within a trait bound. That is, the type for looks to the compiler like: You can see here that appears in the bound for . Anyway, I have the fix for this. This is good because it got me thinking about and I think it's not too hard to extend the fix to cover that case as well. But I'll push the limited fix for just this bug for now.
Thanks for looking into this. I started playing around with your branch to fix this and I ran into another ICE. Is there something new, or is it also caused by ? Errors with:
On Sat, Nov 16, 2013 at 10:01:08PM -0800, Erick Tryzelaar wrote: . I will see how quickly I can prepare a fix for this. The key identifying point is: right here (I a comment)
Change:
#[inline] pub fn write_ty(&self, id: hir::HirId, ty: Ty<'tcx>) { debug!("write_ty({:?}, {:?}) in fcx {}", id, self.resolve_vars_if_possible(ty), self.tag()); <del> self.typeck_results.borrow_mut().node_types_mut().insert(id, ty); </del> <ins> let mut typeck = self.typeck_results.borrow_mut(); let mut node_ty = typeck.node_types_mut(); if let Some(ty) = node_ty.get(id) && let Err(e) = ty.error_reported() { // Do not overwrite nodes that were already marked as `{type error}`. This allows us to // silence unnecessary errors from obligations that were set earlier than a type error // was produced, but that is overwritten by later analysis. This happens in particular // for `Sized` obligations introduced in gather_locals. (#117846) self.set_tainted_by_errors(e); return; } node_ty.insert(id, ty); </ins> if let Err(e) = ty.error_reported() { self.set_tainted_by_errors(e);

Discussion:
It's underlining the wrong argument. No response No response
I'm getting an entirely different and much more helpful error:
Are you sure you minimized the code correctly? Not sure how to repro the example you shared,
Arf, sorry about that... Also important to note, I'm using: I pushed the code with this issue . However it requires a mac to enter this code. Just running is enough to trigger it.
This should be re-minimized by someone who has a Mac then. label +E-needs-mcve
Minimization: Note that: in all cases (including when I ran the original code), there is now a more sensible type error, and the unsized local error is not actually pointing at the wrong thing, it's talking about the type of the part of the tuple unrelated to the if/else type mismatch. It seems like the type mismatch is causing the compiler to fail to properly perform the deref coercion of the , even though it's not the part of the tuple that has the type mismatch. Tested on versions:
label -E-needs-mcve
Change:
let inner_parse_policy = if permit_inner { InnerAttributeParsePolicy::Permitted } else { <del> InnerAttributeParsePolicy::NotPermitted { reason: DEFAULT_UNEXPECTED_INNER_ATTR_ERR_MSG } </del> <ins> InnerAttributeParsePolicy::NotPermitted { reason: DEFAULT_UNEXPECTED_INNER_ATTR_ERR_MSG, saw_doc_comment: false, prev_attr_sp: None } </ins> }; self.parse_attribute_with_inner_parse_policy(inner_parse_policy) }

Discussion:
Given the following we currently emit We should emit at least the following We might also want to provide suggestions when it makes sense (like turning the attr into an outer attr).
Hey , I tried to solve this with a little help of on a rust meetup. I wasn't able to run because of the following message. But I started to add some code you can read here: is this going into the right direction?
thank you for taking a look at this! You should be able to run the tests with . Use to update the relevant files. The code you've written would generate the following output: Instead, we'd want this to be a single error. What you'd want to do is 1) get the span for the prior attribute from 2) expand to also hold an extra field and 3) change the following to be This lets you point at the prior span in the same error. The second part of this ticket is changing the linked code to no longer use , but rather synthesize a new span from the first 's span to the closing . You can use to do so. Finally, we change the above to be something like
Are you still working on this? I'm thinking of giving it a try.
Go on! I don’t have so much time atm so just go there step by step while learning rust. If you want so solve it - awesome
Change:
for elts.each |elt| { check_pat(pcx, *elt, ty::mk_err()); } <del> let actual = ty::mk_tup(tcx, elts.map(|pat_var| { fcx.node_ty(pat_var.id) })); </del> // use terr_tuple_size if both types are tuples let type_error = match s { ty::ty_tup(ref ex_elts) =>

Discussion:
This program generates: Additionally, a similar program yields
+1, I'm running into this, too.
in my case, it turned out to be a missing ampersand on the pattern match for the tuple. I spent a bit of time digging around in the compiler to figure out whether it would be possible to at least attach some span info to the error message, but I came up empty.
This seems like a missing error report to me. Clearly these programs should not be type checking, and those ICEs I believe come from passes that follow type checking. Perhaps an over-suppressed error?
nominating for Production Ready
I found this error in a different context, and another ICE in a related context (both for code that shouldn't pass the type checker):
I've fixed this in a branch. Just testing now.
Fixed pending
Fixed in
Change:
<ins> //@ needs-asm-support #![deny(unsafe_code)] use std::arch::global_asm; #[allow(unsafe_code)] mod allowed_unsafe { std::arch::global_asm!(""); } macro_rules! unsafe_in_macro { () => { global_asm!(""); //~ ERROR: usage of `core::arch::global_asm` }; } global_asm!(""); //~ ERROR: usage of `core::arch::global_asm` unsafe_in_macro!(); fn main() {} </ins>

Discussion:
Similar to how deny(unsafecode) prevents from being used, it should also prevent blocks from being allowed. If misused, they can do any number of strange and horrible thing simply by being within the crate. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
label +C-bug +T-compiler
I suppose it's probably too late to actually make it require ?
that isn't even currently possible from a syntax perspective because blocks only work as expressions, you can't just put them around a top level item. It would take a whole RFC thing, even separately from global_asm already being stable.
Change:
idx_vec: IndexVec<BorrowIndex, BorrowData<'tcx>>, location_map: FxHashMap<Location, BorrowIndex>, assigned_map: FxHashMap<Place<'tcx>, FxHashSet<BorrowIndex>>, <del> activation_map: FxHashMap<Location, BorrowIndex>, </del> <ins> activation_map: FxHashMap<Location, FxHashSet<BorrowIndex>>, </ins> region_map: FxHashMap<Region<'tcx>, FxHashSet<BorrowIndex>>, local_map: FxHashMap<mir::Local, FxHashSet<BorrowIndex>>, region_span_map: FxHashMap<RegionKind, Span>,

Discussion:
This program : See also , which I believe to be relevant. I'm refactoring some of this code, trying to explore the new NLL approach, so I will probably wind up fixing this. But obviously we should have this as a test! cc
Is this similar to this ICE?
Change:
/// Parse a single function argument crate fn parse_arg(&mut self) -> PResult<'a, Arg> { <del> self.parse_arg_general(true) </del> <ins> self.parse_arg_general(true, false) </ins> } /// Parse an argument in a lambda header e.g. |arg, arg|

Discussion:
This code works correctly on nightly and stable but not on 2018 edition, where it returns the error Changing it to solves it. Is this an intended change? I couldn't find anything about it in the edition guide.
Yes, this was done in
So apparently it was part of . In that case we should at least fix the error message, since it doesn't explain the source of the error at all.