jiebi/CodeConvo huggingface dataset:
Change:
<ins> // Regression test for #83621. extern "C" { static x: _; //~ ERROR: [E0121] } fn main() {} </ins>

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
The ICE happens because the type placeholder error has been gone since 1.43.
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-medium
Change:
// declaration, we want to make sure that they are, in fact, // from the same scope if sr.scope_id != common_scope_id { <ins> debug!("returning empty result from process_errors because {} != {}", sr.scope_id, common_scope_id); </ins> return vec!(); } } let pe = ProcessedErrors(var_origins, trace_origins, same_regions); <ins> debug!("errors processed: {:?}", pe); </ins> processed_errors.push(pe); } return processed_errors;

Discussion:
For the input file below, the two distinct invocations of (but with identical arguments) are non-deterministically deciding whether or not to prompt with the "consider using an explicit lifetime parameter" hint. Input file (): Transcript: (See also for a problem with the suggestion actually provided by when it chooses to actually provide one.)
I tested it a bit, and the issue seems to be is fed slightly different information each time. In the first case we have a and in the second . In the constraint graph for some node we are trying to infer, there are multiple incoming edges and outgoing edges to and from . From my understanding the compiler only picks one node from these incoming edges and one node from these outgoing edges, and it doesn't pick the same pair each time (what I don't understand is why I didn't see the and variations).
I'm getting a non-deterministic error message using the latest nightlies: It's non-deterministic on my Fedora 20 machine but not my OSX machine.
Change:
attrs: AttrVec, ) -> PResult<'a, FieldDef> { let name = self.parse_field_ident(adt_ty, lo)?; <del> // Parse the macro invocation and recover </del> if self.token.kind == token::Not { if let Err(mut err) = self.unexpected::<FieldDef>() { <del> err.subdiagnostic(MacroExpandsToAdtField { adt_ty }).emit(); self.bump(); self.parse_delim_args()?; return Ok(FieldDef { span: DUMMY_SP, ident: None, vis, id: DUMMY_NODE_ID, ty: self.mk_ty(DUMMY_SP, TyKind::Err), attrs, is_placeholder: false, }); </del> <ins> // Encounter the macro invocation err.subdiagnostic(MacroExpandsToAdtField { adt_ty }); return Err(err); </ins> } } self.expect_field_ty_separator()?;

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 nightly-2023-08-05 Regression in cc
This is probably because it recovers from it and gives the field no name. We should probably give it the macro's name instead I believe this is the offending line:
An alternative approach would be to directly throw an error instead of allowing the parser to continue, imo.
label -needs-triage
Change:
[install] # Instead of installing to /usr/local, install to this path instead. <del> #prefix = "/path/to/install" </del> <ins> #prefix = "/usr/local" # Where to install libraries in `prefix` above #libdir = "lib" # Where to install man pages in `prefix` above #mandir = "share/man" # Where to install documentation in `prefix` above #docdir = "share/doc/rust" </ins> # ============================================================================= # Options for compiling Rust code itself

Discussion:
No destdir is passed to in
That causes fail in Gentoo build
As far as I understand, we need to to pass to function and add value of to prefix here
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. // This test ensures that vec.into_iter does not overconstrain element lifetime. pub fn main() { original_report(); revision_1(); revision_2(); } fn original_report() { drop(vec![&()].into_iter()) } fn revision_1() { // below is what above `vec!` expands into at time of this writing. drop(<[_]>::into_vec(::std::boxed::Box::new([&()])).into_iter()) } fn revision_2() { drop((match (Vec::new(), &()) { (mut v, b) => { v.push(b); v } }).into_iter()) } </ins>

Discussion:
The following code compiles on stable and beta, but not nightly: For reference, the error produced by the above is: The original test case was reduced down to the above thanks to eddyb and bluss. The original problematic line was (clap → → → boom). Specifically, the issue was with the method, though the error pointed to an earlier temporary as not living long enough. If desired, I can provide a complete, in-context example of this going awry. bluss suggested that this was related to .
cc
Hmm I wonder if the iterators involved need to have the escape hatch for dropck to them.
Here is a variant (that has also regressed) that does not use the macro:
(It looks like may need similar treatment too, but I am having trouble actually making a concrete test illustrating the necessity there -- it seems when I call instead of in the above test case, even stable and beta complain about lifetime issues. Maybe the old dropck is catching something I'm missing in my manual analysis of , so I'm not going to lump that in until I see evidence that it is warranted.) Update: Oh, duh, has a lifetime bound (and a impl), so of course the old dropck was going to reject it.
Change:
use hir::def::CtorKind; use hir::intravisit::{walk_expr, walk_stmt, Visitor}; use rustc_data_structures::fx::FxIndexSet; <del> use rustc_errors::Diagnostic; </del> <ins> use rustc_errors::{Applicability, Diagnostic}; </ins> use rustc_hir as hir; use rustc_middle::traits::{ IfExpressionCause, MatchExpressionArmCause, ObligationCause, ObligationCauseCode, StatementAsExpression, }; use rustc_middle::ty::print::with_no_trimmed_paths; <del> use rustc_middle::ty::{self as ty, IsSuggestable, Ty, TypeVisitableExt}; </del> <ins> use rustc_middle::ty::{self as ty, GenericArgKind, IsSuggestable, Ty, TypeVisitableExt}; </ins> use rustc_span::{sym, BytePos, Span}; use rustc_target::abi::FieldIdx;

Discussion:
a new project with (in my case, it used pathfinding version 4.0.0 or 4.0.1) with: produces the following output: For the two closures ( and ), if I add a type for the parameter by changing to , it builds without any errors. If it had told me that it needed type annotations, I would have understood the problem and been able to fix it right away. (I assumed that there was enough type information for it to infer the correct types.) The first confusing bit is that both errors highlight the entire call to , including all parameters. This makes it harder to figure out which one it is complaining about (though the second note contains the line number). Does the first argument have something to do with the lifetimes it is complaining about? I found this part of the message hard to understand: The type parameters look almost identical, and the didn't make sense to me. Could it somehow indicate the bounds of that lifetime (2), or better explain why that lifetime doesn't last long enough? FYI: found as part of solving Advent of Code 2022, Day 12. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
A smaller MCVE:
I'm thinking whether we should fix this as a compiler bug (i.e., make it compile) or suggesting people write explicit type here
maybe related:
Also if we move the closure to the parameter: This will also compile. Combined with , I guess something is wrong with propagating lifetime of closures when we store it in a variable...
claim
Change:
#![feature(if_let_guard)] #![feature(iter_order_by)] #![feature(let_chains)] <del> #![cfg_attr(not(bootstrap), feature(trait_upcasting))] </del> #![feature(min_specialization)] #![feature(rustc_attrs)] <ins> #![feature(trait_upcasting)] </ins> #![deny(rustc::untranslatable_diagnostic)] #![deny(rustc::diagnostic_outside_of_impl)] #![allow(internal_features)]

Discussion:
hello everyone, I got this error when I bootstrap the current rust-beta branch: There was a lot of pushing and reverting changesets relevant to the c literals stabilization, I tried to get an overview of what backport might be missing here, but I failed and am at a loss. I am on linux x86_64, with musl as my libc, I doubt the later is causing the issues.
What are you using as your bootstrap compiler? We only support using the previous release.
I think I understand what is going on. If you try to bootstrap 1.77 from 1.76, it will fail. We were intending to have c-string literals stabilized in 1.76, but that got reverted. However, the revert did not include the appropriate parts of I can probably put something together to fix it.
Posted with a fix.
Change:
<ins> // Regression test for #51446. // check-pass trait Foo { type Item; fn get(&self) -> Self::Item; } fn blah<T, F>(x: T, f: F) -> B<T::Item, impl Fn(T::Item)> where T: Foo, F: Fn(T::Item), { B { x: x.get(), f } } pub struct B<T, F> where F: Fn(T), { pub x: T, pub f: F, } impl Foo for i32 { type Item = i32; fn get(&self) -> i32 { *self } } fn main() { let _ = blah(0, |_| ()); } </ins>

Discussion:
This may be related/identical to and . The following code fails to compile with a dubious error. This is a simplified reproduction example based on code on IRC. Note that commenting the clause in the definition of makes the code compile.
This code now compiles. It just needs a test to close.
Change:
--> $DIR/issue-28344.rs:4:17 | LL |     let x: u8 = BitXor::bitor(0 as u8, 0 as u8); <del> |                 ^^^^^^ help: specify the associated type: `BitXor<Output = Type>` </del> <ins> |                 ^^^^^^ help: specify the associated type: `BitXor::<Output = Type>` </ins> error[E0599]: no function or associated item named `bitor` found for trait object `dyn BitXor<_>` in the current scope --> $DIR/issue-28344.rs:4:25

Discussion:
Given the following code: %20%7B%0A%20%20%20%20let%20%20%3D%20MyIterator%3A%3Anext%3B%0A%20%20%20%20%2F%2Flet%20%20%3D%20MyIterator%3CItem%3D()%3E%3A%3Anext%3B%0A%7D) The current output is: But when when I write , it gets interpreted as comparison expressions like and it fails to compile with a lot of "cannot find value in this scope" and "cannot find crate in the list of imported crates". The suggestion is confusing because it is unclear how to apply it. The error goes away if you use directly: produces the error one would expect: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think it gets evaluated as an expression because you are missing a . If you add them, then you get a new error message ():
I see, let me rephrase the issue: The suggestion is "help: specify the associated type: " where "help: specify the associated type: " with a double colon would be correct.
Triage: Suggestion is correct for code using (which all code written in Rust =2021 uses). For code written without in Rust <2021: No change. As mentioned, the suggestion should use an expression-style path (i.e., one with turbofishes).
claim
Working on tests before creating a PR. Multiple tests exist already that have an odd hardcoded expectation for error output, so I'll be double checking those make sense with these changes, and adding a few tests of my own. Otherwise, this really does seem like it was a simple two character fix, unless I missed something somewhere.
Yeah, it's a pretty easy one. Adding before is always correct — not only in expression contexts but also in type contexts since turbofish is also possible in type positions (e.g., ) — albeit redundant. Omitting before in type contexts would be a possible "optimization". However, it really isn't worth doing here.

Consider the following code which is ill-formed even after specifying the assoc ty. () would only be well-formed if we defined an inherent associated type () on which doesn't work yet anyway () and is pretty niche) or once we support arbitrary shorthand projections ().
Change:
// FIXME(const_generics): we should either handle `Scalar::Ptr` or add a comment // saying that we're not handling it intentionally. <del> // FIXME(const_generics): handle `ConstValue::ByRef` and `ConstValue::Slice`. </del> <ins> (a_val @ ConstValue::Slice { .. }, b_val @ ConstValue::Slice { .. }) => { let a_bytes = get_slice_bytes(&tcx, a_val); let b_bytes = get_slice_bytes(&tcx, b_val); if a_bytes == b_bytes { Ok(tcx.mk_const(ty::Const { val: a_val, ty: a.ty, })) } else { Err(TypeError::ConstMismatch(expected_found(relation, &a, &b))) } } // FIXME(const_generics): handle `ConstValue::ByRef`. </ins> // FIXME(const_generics): this is wrong, as it is a projection (ConstValue::Unevaluated(a_def_id, a_substs),

Discussion:
Results in cc
modify labels: I-ICE C-Bug T-compiler A-const-generics
I'm looking into this currently.
Partially as a note to myself and partially as an update to anyone interested The root cause of this bug seems to be the fact that we currently don't explicitly handle slice const values in , and therefore we always say they cannot match. This error eventually bubbles up to to produce all three errors.
Change:
NonZeroIsize, ); <ins> macro_rules! impl_is_zero_option_of_num { ($($t:ty,)+) => {$( unsafe impl IsZero for Option<$t> { #[inline] fn is_zero(&self) -> bool { const { let none: Self = unsafe { core::mem::MaybeUninit::zeroed().assume_init() }; assert!(none.is_none()); } self.is_none() } } )+}; } impl_is_zero_option_of_num!(u8, u16, u32, u64, u128, i8, i16, i32, i64, i128, usize, isize,); </ins> unsafe impl<T: IsZero> IsZero for Wrapping<T> { #[inline] fn is_zero(&self) -> bool {

Discussion:
I want to initialize a large with . Compiling with Rust 1.66 generates instructions. However, after initializing with the code gets vectorized as expected: The generated assembly contains instructions. Now, the weird thing is that if I have both functions in the same file, both get vectorized. See this . As long as is commented out, is not vectorized. As soon as you remove the comment, both functions are vectorized.
Easiest fix for specifically would be to update , I think. We don't guarantee a layout for it, but internally for optimizations I think we'd be safe doing this. (We can put some tests like in non-public stuff to help double-check it.)
When is , couldn't the part of the memory layout be anything since it shouldn't be accessed? Couldn't we use that for optimization? So for example, if sets the discriminator bit to 0, couldn't we always zero out the entire memory no matter what is? Or if the discriminator is represented with a non-zero value, couldn't the whole data structure be filled up with that value (or just left unitialized depending on which is faster)?
Unfortunately not, because there can be other niches than 0. For instance, has the value 0xffff_ffff on Unix platforms.
Can we at least assume that two -s will always have the same bytes in memory for any fixed ? If so, couldn't we vectorize filling up the with those bytes?
I think similar to . iirc the main issue is that LLVM's InstCombine removes the instructions before reaching the passes that could use this information to optimize - at this point, it generally becomes a series of stores with gaps between which LLVM no longer knows can be written to freely.
No, because something like is half , where "the same" isn't a meaningful question. That's exactly what I mention for -- you can use that to check that it's a value where it would be legal to zero out the whole thing, and if that function returns then uses a zeroing allocator instead of the needing initialize the memory.
Change:
<ins> use core::alloc::{Allocator, Layout}; use core::ptr::NonNull; use std::alloc::System; </ins> use std::assert_matches::assert_matches; use std::borrow::Cow; use std::cell::Cell;

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'm trying out the allocator api with the goal of being able to track memory usage for parts of a program: I expected this to work (and print 0 at the end), but instead it fails by freeing an invalid pointer: Running with miri gives a bit more context:
This seems to be a problem with the implementation of because if I do: There is no crash and no Miri error, this to me indicate that there is a problem in the implementation of . Another interesting things is the message I have locally , I don't know what it means but it's certainly interesting. label +T-libs +I-unsound
The drop guard used in the implementation of IntoIter makes a raw copy of an allocator when reconstructing RawVec. The allocator is then dropped twice, once by RawVec drop and second time by IntoIter drop. cc .
Minimal reproduction of problem: Prints:
Change:
<ins> // check-fail pub fn main() { println!("🦀%%%", 0) } //~ ERROR argument never used </ins>

Discussion:
rustc crashes on the following input, found by :
searched nightlies: from nightly-2021-01-01 to nightly-2021-12-24 regressed nightly: nightly-2021-10-02 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
The regression happened in . cc
label regression-from-stable-to-stable
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
I've been taking a look at this. It's pretty interesting. I'm not entirely sure I'll be able to work it out, but I figure I may as well assign myself for the time being while I attempt to solve it.
Another test case:
The problem seems to reside within the crate , in the files and . The function in has a macro, , which is in charge of looking for foreign substitutions - that is, someone using printf or shell style formatting rather than Rust's style. It's a macro so it can be generic over the two types of substitution. The first time this macro is called, for printf substitutions, it finds two (I think "%%" and "%", though I'm not sure it's exactly that). The code that actually detects the substitutions is in . When parsing the substitution, in the function , it is somehow finding that the second substitution has a boundary in the middle of the character. I'm not sure exactly how yet. This gets turned into a span in . The span is malformed, as it splits a character in two, so the second the code tries to use it for anything it trips an assertion and causes this ICE. The remaining problem is figuring out what's going wrong in . This sort of string manipulation is not my forte. I'll probably take another few cracks at it though.
Something is broken about . This change makes the ICE go away (but probably breaks other things):
When returns here: it seems like we should increment by , but we actually only increment it by 2:
yes, I get the exact same error. . The error disappears if you add a new line after the , so maybe your text editor did that automatically.

That was it, thanks. I'm going to unassign myself from this. I do hope my exploration ends up being helpful to whoever fixes it though. if you want to fix this yourself, you certainly seem further along than I was, though you shouldn't feel any pressure to do so if you don't want to.
I put up a PR for a
I opened a new issue for your bug, because it's not exactly the same as this one.
Change:
_ => 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, 

Discussion:
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.