jiebi/CodeConvo huggingface dataset:
Change:
Hi, I appear to have found this ICE that only occurs on nightly. Reproducing it is as simple as the below example:
Backtrace:
I'd like to give this a try. The failing code is this when ABI is RustCall it assumes two things: There will be at least one argument to the function The last argument will be a tuple For example if I change function type and add an argument, I get a different panic saying that the last argument should be a tuple: But if I turn that argument into a tuple it works: I don't know anything about RustCall ABI but assuming these restrictions are correct I guess there will be a check (maybe in the type checker?) that checks the function type and reject the program with a proper error message when the function is not valid according to RustCall ABI. That means a special case for . Does this make sense? Where is a good place to add this check? OP says this only happens in nightly, but is not supported on stable, so I'm not sure what they mean exactly. Did this ever work on older nightlies?
As of , it will still ICE, but deliberately (as the is incomplete).

Discussion:
let extra_args = if sig.abi == RustCall { assert!(!sig.c_variadic && extra_args.is_empty()); <del> match sig.inputs().last().unwrap().kind { ty::Tuple(tupled_arguments) => { </del> <ins> if let Some(input) = sig.inputs().last() { if let ty::Tuple(tupled_arguments) = input.kind { </ins> inputs = &sig.inputs()[0..sig.inputs().len() - 1]; tupled_arguments.iter().map(|k| k.expect_ty()).collect() <del> } _ => { </del> <ins> } else { </ins> bug!( "argument to function with "rust-call" ABI  <del> is not a tuple" </del> <ins> is not a tuple" </ins> ); } <ins> } else { bug!( "argument to function with "rust-call" ABI  is not a tuple" ); </ins> } } else { assert!(sig.c_variadic || extra_args.is_empty());
Change:
The following code ICE's on stable, beta and nightly: <details<summaryBacktrace:</summary</details
reduced
This is not an bug, here's another reproducer for the same bug: EDIT: Fix coming ...
A closure is just enough: modify labels: -A-async-await +A-closures

Discussion:
// If this is a break with a value, we need to type-check // the expression. Get an expected type from the loop context. let opt_coerce_to = { <ins> // We should release `enclosing_breakables` before the `check_expr_with_hint` // below, so can't move this block of code to the enclosing scope and share // `ctxt` with the second `encloding_breakables` borrow below. </ins> let mut enclosing_breakables = self.enclosing_breakables.borrow_mut(); <del> enclosing_breakables.find_breakable(target_id) .coerce .as_ref() .map(|coerce| coerce.expected_ty()) </del> <ins> match enclosing_breakables.opt_find_breakable(target_id) { Some(ctxt) => ctxt.coerce.as_ref().map(|coerce| coerce.expected_ty()), None => { // Avoid ICE when `break` is inside a closure (#65383). self.tcx.sess.delay_span_bug( expr.span, "break was outside loop, but no error was emitted", ); return tcx.types.err; } } </ins> }; // If the loop context is not a `loop { }`, then break with

<ins> // Breaks with values inside closures used to ICE (#66863) fn main() { 'some_label: loop { || break 'some_label (); //~ ERROR: `break` inside of a closure } } </ins>

<ins> error[E0267]: `break` inside of a closure --> $DIR/issue-66702-break-outside-loop-val.rs:5:12 | LL |         || break 'some_label (); |         -- ^^^^^^^^^^^^^^^^^^^^ cannot `break` inside of a closure |         | |         enclosing closure error: aborting due to previous error For more information about this error, try `rustc --explain E0267`. </ins>
Change:
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 compiler team prioritization.

Discussion:
<del> Subproject commit 60e8413a4e5b7c67001176783893b12411ce355e </del> <ins> Subproject commit 7b8e8293d08d298579470f9d6c74731043c6601a </ins>
Change:
This code: gives the following error: It's not clear or even close to what the actual problem is. I think it should throw the E0067 error code. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

Discussion:
Ok(P(ast::Local { ty, pat, init, id: DUMMY_NODE_ID, span: lo.to(hi), attrs, tokens: None })) } <del> /// Parses the RHS of a local variable declaration (e.g., '= 14;'). </del> <ins> /// Parses the RHS of a local variable declaration (e.g., `= 14;`). </ins> fn parse_initializer(&mut self, eq_optional: bool) -> PResult<'a, Option<P<Expr>>> { let eq_consumed = match self.token.kind { token::BinOpEq(..) => {

"=".to_string(), Applicability::MaybeIncorrect, ) <ins> .help("if you meant to overwrite, remove the `let` binding") </ins> .emit(); self.bump(); true

| LL |     let a: i8 *= 1; |               ^^ help: initialize the variable <ins> | = help: if you meant to overwrite, remove the `let` binding </ins> error: can't reassign to an uninitialized variable --> $DIR/let-binop.rs:6:11 | LL |     let b += 1; |           ^^ help: initialize the variable <ins> | = help: if you meant to overwrite, remove the `let` binding </ins> error: can't reassign to an uninitialized variable --> $DIR/let-binop.rs:8:11 | LL |     let c *= 1; |           ^^ help: initialize the variable <ins> | = help: if you meant to overwrite, remove the `let` binding </ins> error: aborting due to 3 previous errors
Change:
Example: CC: ,
The error is emitted from . Adding does enable the example above. Interestingly, no terminator appears in the MIR for that function. This suggests that we are running const checks before a cleanup pass that removes terminators for exhaustive expressions. We have a few choices here. I am leaning towards just removing from the checks. What do you think? cc
Let's gate the removal on for now to make sure we don't accidentally allow anything on stable.
Oh yea, I just left it in there so we don't accidentally allow something. I couldn't figure out how to trigger it, so I preferred to deny it.

Discussion:
check_operand(tcx, discr, span, def_id, body) } <ins> // FIXME(ecstaticmorse): We probably want to allow `Unreachable` unconditionally. TerminatorKind::Unreachable if tcx.features().const_if_match => Ok(()), </ins> | TerminatorKind::Abort | TerminatorKind::Unreachable => { Err((span, "const fn with unreachable code is not stable".into())) }

<ins> // Test for <https://github.com/rust-lang/rust/issues/66756> // check-pass #![feature(const_if_match)] enum E { A, B, C } const fn f(e: E) { match e { E::A => {} E::B => {} E::C => {} } } fn main() {} </ins>
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri 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 compiler team prioritization.
triage: P-medium, removing nomination label.

Discussion:
"cargo_metadata 0.9.0", "clippy-mini-macro-test", "clippy_lints", <del> "compiletest_rs 0.4.0", </del> <ins> "compiletest_rs", </ins> "derive-new", "lazy_static 1.3.0", "regex",

"rustc_tools_util 0.2.0", "semver", "serde", <del> "tester 0.7.0", </del> <ins> "tester", </ins> ] [[package]]

[[package]] name = "compiletest_rs" <del> version = "0.3.26" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "d7d8975604ebad8b6660796802377eb6495045c5606168fc1b8d19a4dd9bfa46" dependencies = [ "diff", "filetime", "getopts", "libc", "log", "miow 0.3.3", "regex", "rustfix", "serde", "serde_derive", "serde_json", "tempfile", "tester 0.6.0", "winapi 0.3.8", ] [[package]] name = "compiletest_rs" </del> version = "0.4.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "d7b678957210a00ba0fbeacc23d38cbfbf29895564da1616564634351e1dac5e"

"serde_derive", "serde_json", "tempfile", <del> "tester 0.7.0", </del> <ins> "tester", </ins> "winapi 0.3.8", ]

"byteorder", "cargo_metadata 0.9.0", "colored", <del> "compiletest_rs 0.3.26", </del> <ins> "compiletest_rs", </ins> "directories", "env_logger 0.7.1", "getrandom",

[[package]] name = "tester" <del> version = "0.6.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "7647e6d732eb84375d8e7abda37818f81861ddbfc7235e33f4983cb254b71e4f" dependencies = [ "getopts", "libc", "term 0.6.0", ] [[package]] name = "tester" </del> version = "0.7.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "ee72ec31009a42b53de9a6b7d8f462b493ab3b1e4767bda1fcdbb52127f13b6c"

<del> Subproject commit 644e2a76a87a129f597dc40b47593fc8f72539cb </del> <ins> Subproject commit 3bf51f591f7ffdd45f51cd1d42a4002482af2bd5 </ins>
Change:
E.g. in we had to use weird code to check that the iterator is the same length as a slice. After changing the function to have an ExactSizeIterator bound, we should undo the hack <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
What do you mean by "many"? Is this about grepping returns in and replacing them with whenever possible? I'd like to give this a try but not sure what exactly this is asking.
Ah, not libstd, just in the compiler. But yea, you got the right idea, grep for it, see if it can be ExactSizeIterator, if not leave it
Hi, this looks pretty easy and I would actually try to get involved into rustc - could I take this one as starting point for incoming weekend?
Go for it. Just search for returns in the compiler source code and replace them with whenever possible.
claim

Discussion:
/// Returns an iterator over all function arguments. #[inline] <del> pub fn args_iter(&self) -> impl Iterator<Item = Local> { </del> <ins> pub fn args_iter(&self) -> impl Iterator<Item = Local> + ExactSizeIterator { </ins> let arg_count = self.arg_count; <del> (1..=arg_count).map(Local::new) </del> <ins> (1..arg_count + 1).map(Local::new) </ins> } /// Returns an iterator over all user-defined variables and compiler-generated temporaries (all /// locals that are neither arguments nor the return place). #[inline] <del> pub fn vars_and_temps_iter(&self) -> impl Iterator<Item = Local> { </del> <ins> pub fn vars_and_temps_iter(&self) -> impl Iterator<Item = Local> + ExactSizeIterator { </ins> let arg_count = self.arg_count; let local_count = self.local_decls.len(); (arg_count + 1..local_count).map(Local::new)

UserTypeProjections { contents: projs.collect() } } <del> pub fn projections_and_spans(&self) -> impl Iterator<Item = &(UserTypeProjection, Span)> { </del> <ins> pub fn projections_and_spans(&self) -> impl Iterator<Item = &(UserTypeProjection, Span)> + ExactSizeIterator { </ins> self.contents.iter() } <del> pub fn projections(&self) -> impl Iterator<Item = &UserTypeProjection> { </del> <ins> pub fn projections(&self) -> impl Iterator<Item = &UserTypeProjection> + ExactSizeIterator { </ins> self.contents.iter().map(|&(ref user_type, _span)| user_type) }
Change:
While being strict to the letter of , this comment looks to me as a little too abstract and therefore unnecessarily fear-inducing. Maybe it would make sense to expand it by saying that at least some of the major Unix-like systems do make sure to always close the FD, even when is interrupted, and that this is a pretty rare situation anyway, because it may happen only if a custom signal handler is set by the process. Maybe even provide some illuminating links like . Making so might save time for people, who are not aware of the details of this issue, but nevertheless care enough about their FDs always being closed to start digging the Web for answers :) Thank you for reading. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Looks like this piece of code got moved over the last 4 years. Currently the comment in question resides here:
claim

Discussion:
// the file descriptor was closed or not, and if we retried (for // something like EINTR), we might close another valid file descriptor // opened after we closed ours. <ins> // However, this is usually justified, as some of the major Unices // do make sure to always close the FD, even when `close()` is interrupted, // and the scenario is rare to begin with. // Helpful link to an epic discussion by POSIX workgroup: // http://austingroupbugs.net/view.php?id=529 </ins> #[cfg(not(target_os = "hermit"))] { #[cfg(unix)]
Change:
results in an ICE (): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

Discussion:
// figure out which generic parameter it corresponds to and return // the relevant type. let generics = match path.res { <del> Res::Def(DefKind::Ctor(..), def_id) => { </del> <ins> Res::Def(DefKind::Ctor(..), def_id) | Res::Def(DefKind::AssocTy, def_id) => { </ins> tcx.generics_of(tcx.parent(def_id).unwrap()) } Res::Def(_, def_id) => tcx.generics_of(def_id), <del> Res::Err => return tcx.types.err, </del> res => { tcx.sess.delay_span_bug( DUMMY_SP, <del> &format!("unexpected const parent path def {:?}", res,), </del> <ins> &format!( "unexpected const parent path def, parent: {:?}, def: {:?}", parent_node, res ), </ins> ); return tcx.types.err; }

.map(|param| tcx.type_of(param.def_id)) // This is no generic parameter associated with the arg. This is // probably from an extra arg where one is not needed. <del> .unwrap_or(tcx.types.err) </del> <ins> .unwrap_or_else(|| { tcx.sess.delay_span_bug( DUMMY_SP, &format!( "missing generic parameter for `AnonConst`, parent {:?}", parent_node ), ); tcx.types.err }) </ins> } else { tcx.sess.delay_span_bug( DUMMY_SP,

<ins> // check-pass #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash pub struct Tuple; pub trait Trait<const I: usize> { type Input: From<<Self as Trait<I>>::Input>; } fn main() {} </ins>

<ins> warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/issue-66906.rs:3:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default </ins>

<ins> // check-pass #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash pub trait Trait<const N: usize>: From<<Self as Trait<N>>::Item> { type Item; } fn main() {} </ins>

<ins> warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/issue-70167.rs:3:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default </ins>
Change:
Minimal reproducer: Make sure to run rustc with to reproduce! Using doesn't fix this.
Minimal repro:
Other failure with code causing the above problem: This one is observable by printing the whole mir using , unlike the other, which requires you to debug print every statement.
cc
That second one is a miri assertion: Interestingly, there's an afterwards that would be more helpful if it were before: cc
It seems like no longer ICE with latest nightly, I guess fixed this (CC: Marked as E-needstest
points out hasn't been fixed yet, dropping E-needstest.
Is the issue description still accurate? "Can't debug format a mir stmt in DefId" reminds me of a after we had some ICE issues with debug-printing DefIds. But as far as I can see, no example mentioned here even triggers an ICE with that message. The ICEs described here sound very different than that, they look like CTFE is not handling ZSTs properly somewhere.
I cannot on beta or nightly, so it looks pretty fixed to me. can you still reproduce this issue with latest nightly? The first backtrace has no code, so it is impossible to debug; the second backtrace (the one with self-contained code) does not seem to ICE any more.
Uhm? I don't think so, did you run with ?
Ah, I just ran on playground. It would be good to have up-to-date reproduction instructions in the first post, and not just in the third post below a huge stacktrace.
Yeah, but I don't have write access :/
Ouch, sorry. :( I didn't know. I will update the OP.
<details<summaryHere's a backtrace with debug info</summary</details Looks like the is wrong.
Triage: I think that ICE is fixed by , no longer occurs with the latest nightly. Marking as E-needs-test.

Discussion:
<ins> // check-pass // compile-flags: --emit=mir,link // Regression test for #66930, this ICE requires `--emit=mir` flag. static UTF8_CHAR_WIDTH: [u8; 0] = []; pub fn utf8_char_width(b: u8) -> usize { UTF8_CHAR_WIDTH[b as usize] as usize } fn main() {} </ins>
Change:
Initially reported in and then My best guess is ; cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Interesting note: this does not apply to when in mode.
Regression introduced in . My bad... should have remembered that is contextual! The fix should be to make changes around here: You'll want to use look-ahead to ensure that an identifier follows . Also, add a regression test for , , and .
claim
Error: Parsing assign command in failed: claim Please let know if you're having trouble with this bot.
assign
You'll need to change to something along the lines of

Discussion:
/// Checks if current token is one of tokens which cannot be nested like `kw::Enum`. In case /// it is, we try to parse the item and report error about nested types. fn recover_nested_adt_item(&mut self, keyword: Symbol) -> PResult<'a, bool> { <del> if self.token.is_keyword(kw::Enum) || </del> <ins> if (self.token.is_keyword(kw::Enum) || </ins> self.token.is_keyword(kw::Struct) || <del> self.token.is_keyword(kw::Union) </del> <ins> self.token.is_keyword(kw::Union)) && self.look_ahead(1, |t| t.is_ident()) </ins> { let kw_token = self.token.clone(); let kw_str = pprust::token_to_string(&kw_token);

<ins> // This test checks that the union keyword // is accepted as the name of an enum variant // when not followed by an identifier // This special case exists because `union` is a contextual keyword. #![allow(warnings)] // check-pass enum A { union } enum B { union {} } enum C { union() } fn main(){} </ins>
Change:
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 compiler team prioritization.

Discussion:
<del> Subproject commit 7a943a9dfcdca98e5988da6d0b7d2f83a364b5ba </del> <ins> Subproject commit 374db5c0b7a8ebc92ecb35ee21e11961da6c754d </ins>
Change:
I stumbled on this while debugging I tried calling with an iterator which itself allocates on the arena. If that iterator has fixed size (known through ), the allocation goes in the fast path. In that case, the allocation for the range and the recursive allocations get interlaced. The returned pointers are wrong, and valid objects get overwritten. This can lead to undropped objects and infinite loops. A simple fix has been committed to A more intelligent one may be better.
Can you split out the fix (presuming it's to TypedArena itself) from the arena code? It sounds like if we're returning wrong pointers this is a "soundness" bug too, since that method is safe; which is not great. Nominating for compiler team so we can hopefully assign someone to investigate a proper fix.
triage: sounds very bad. has PR. P-high. removing nomination.

Discussion:
#[inline] pub fn alloc_from_iter<I: IntoIterator<Item = T>>(&self, iter: I) -> &mut [T] { assert!(mem::size_of::<T>() != 0); <del> let mut iter = iter.into_iter(); let size_hint = iter.size_hint(); match size_hint { (min, Some(max)) if min == max => { // We know the exact number of elements the iterator will produce here let len = min; if len == 0 { return &mut []; } self.ensure_capacity(len); let slice = self.ptr.get(); unsafe { let mut ptr = self.ptr.get(); for _ in 0..len { // Write into uninitialized memory. ptr::write(ptr, iter.next().unwrap()); // Advance the pointer. ptr = ptr.offset(1); // Update the pointer per iteration so if `iter.next()` panics // we destroy the correct amount self.ptr.set(ptr); } slice::from_raw_parts_mut(slice, len) } } _ => { cold_path(move || -> &mut [T] { let mut vec: SmallVec<[_; 8]> = iter.collect(); if vec.is_empty() { return &mut []; } // Move the content to the arena by copying it and then forgetting // the content of the SmallVec unsafe { let len = vec.len(); let start_ptr = self.alloc_raw_slice(len); vec.as_ptr().copy_to_nonoverlapping(start_ptr, len); vec.set_len(0); slice::from_raw_parts_mut(start_ptr, len) } }) } </del> <ins> let mut vec: SmallVec<[_; 8]> = iter.into_iter().collect(); if vec.is_empty() { return &mut []; } // Move the content to the arena by copying it and then forgetting // the content of the SmallVec unsafe { let len = vec.len(); let start_ptr = self.alloc_raw_slice(len); vec.as_ptr().copy_to_nonoverlapping(start_ptr, len); vec.set_len(0); slice::from_raw_parts_mut(start_ptr, len) </ins> } }
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. 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 compiler team prioritization.
Cc The error is with the following backtrace
Ah but further up the call stack we have so I think this will be fixed by

Discussion:
<del> Subproject commit c388361cc2db82568d5e90fefea864f0af8d35e9 </del> <ins> Subproject commit a0ba079b6af0f8c07c33dd8af72a51c997e58967 </ins>
Change:
I encounter an ICE: with rustc 1.41.0-nightly ( 2019-12-06) running on x86_64-pc-windows-msvc when compiling The Stable compiler outputs But Nightly crashed.
Confirmed on Linux too. <details<summaryBacktrace</summary</details
Reduced slightly:
cc
Really reduced: This comes from this unwrap: The used should be

Discussion:
let tcx = self.infcx.tcx; let generics = tcx.generics_of(self.mir_def_id); let param = generics.type_param(&param_ty, tcx); <del> if let Some(generics) = tcx.hir().get_generics(self.mir_def_id) { </del> <ins> if let Some(generics) = tcx.hir().get_generics(tcx.closure_base_def_id(self.mir_def_id)) { </ins> suggest_constraining_type_param( generics, &mut err,

<ins> fn foo<T>(t: T) { || { t; t; }; //~ ERROR: use of moved value } fn main() {} </ins>

<ins> error[E0382]: use of moved value: `t` --> $DIR/issue-67123.rs:2:13 | LL | fn foo<T>(t: T) { |        - help: consider restricting this bound: `T: Copy` LL |     || { t; t; }; |          -  ^ value used here after move |          | |          value moved here | = note: move occurs because `t` has type `T`, which does not implement the `Copy` trait error: aborting due to previous error For more information about this error, try `rustc --explain E0382`. </ins>