jiebi/CodeConvo huggingface dataset:
Change:
use rustc_middle::ty::{ConstVid, EffectVid, FloatVid, IntVid, TyVid}; use rustc_middle::ty::{GenericArg, GenericArgKind, GenericArgs, GenericArgsRef}; use rustc_span::symbol::Symbol; <del> use rustc_span::Span; </del> <ins> use rustc_span::{Span, DUMMY_SP}; </ins> use std::cell::{Cell, RefCell}; use std::fmt;

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
label +E-needs-mcve
Minimized to:
might be similar to , cc who self-assigned and probably knows more about this stuff ^^
in case we need more code snippets, here are 60 of them that that can trigger the ice in some way or another :upsidedownface:
I'm pretty sure all (or at least most) of these examples are not related. This issue is specifically the case where the code used to emit: and now ICEs. is unrelated except for the ICE message.
Ah so this () is a new one? Need to put some though into automatic ice distinction (perhaps based on query stack?)
Yeah, there's a class of ICEs that have the same name and often very different root causes (i.e. ICEs in snapshot-vec) and this is one of them.
Change:
} impl fmt::Debug for Command { <ins> // show all attributes but `self.closures` which does not implement `Debug` // and `self.argv` which is not useful for debugging </ins> fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { <del> if self.program != self.args[0] { write!(f, "[{:?}] ", self.program)?; } write!(f, "{:?}", self.args[0])?; </del> <ins> if f.alternate() { let mut debug_command = f.debug_struct("Command"); debug_command.field("program", &self.program).field("args", &self.args); if !self.env.is_unchanged() { debug_command.field("env", &self.env); } if self.cwd.is_some() { debug_command.field("cwd", &self.cwd); } if self.uid.is_some() { debug_command.field("uid", &self.uid); } if self.gid.is_some() { debug_command.field("gid", &self.gid); } if self.groups.is_some() { debug_command.field("groups", &self.groups); } if self.stdin.is_some() { debug_command.field("stdin", &self.stdin); } if self.stdout.is_some() { debug_command.field("stdout", &self.stdout); } if self.stderr.is_some() { debug_command.field("stderr", &self.stderr); } if self.pgroup.is_some() { debug_command.field("pgroup", &self.pgroup); } #[cfg(target_os = "linux")] { debug_command.field("create_pidfd", &self.create_pidfd); } </ins> <del> for arg in &self.args[1..] { write!(f, " {:?}", arg)?; </del> <ins> debug_command.finish() } else { if let Some(ref cwd) = self.cwd { write!(f, "cd {cwd:?} && ")?; } for (key, value_opt) in self.get_envs() { if let Some(value) = value_opt { write!(f, "{}={value:?} ", key.to_string_lossy())?; } } if self.program != self.args[0] { write!(f, "[{:?}] ", self.program)?; } write!(f, "{:?}", self.args[0])?; for arg in &self.args[1..] { write!(f, " {:?}", arg)?; } Ok(()) </ins> } <del> Ok(()) </del> } }

Discussion:
currently only outputs the program and it's arguments. It should also output the environment variables and the current path, as set by , and . This would help with figuring out what's going on :-)
We also currently have no way to extract most of this information without utilizing Debug, so out of tree implementations can't be implemented.
Would/should this be the specific additions to the environment set by , or the actual environment? The most straightforward implementation of this (debug-printing the individual fields of the internal struct) seems to do the latter. That is, this patch (in )— results in program behavior like this (scroll right to see the very bulky output; should be verbose, but how verbose is too verbose??):
I'd be fine with the verbose output. The debug output is only meant for debug purposes and generating the full environment saves us from oh-that's-why-it's-not-working-this-stupid-thing moments
Seems reasonable. I would be ready to consider a PR implementing this.
Triage: no changes here. I've actually wanted this too, but don't have the bandwidth to work on it, personally.
Change:
<ins> #![feature(type_alias_impl_trait)] #![feature(generic_associated_types)] // See https://github.com/rust-lang/rust/issues/87258#issuecomment-883293367 trait Trait1 {} struct Struct<'b>(&'b ()); impl<'d> Trait1 for Struct<'d> {} pub trait Trait2 { type FooFuture<'a>: Trait1; fn foo<'a>() -> Self::FooFuture<'a>; } type Helper<'xenon, 'yttrium, KABOOM: Trait2> = impl Trait1; impl<'c, S: Trait2> Trait2 for &'c mut S { type FooFuture<'a> = Helper<'c, 'a, S>; fn foo<'a>() -> Self::FooFuture<'a> { //~ ERROR Struct(unimplemented!()) } } fn main() {} </ins>

Discussion:
: (Also ) <details<summary<strongBacktrace</strong</summary<p</p</details
Issue might be related (or this may be a duplicate of it).
This seems to be caused by Re-inserting gets rid of the ICE. What was the rationale for deleting that function?
It was replacing inference lifetimes with concrete ones (but wrong ones, as it was using lifetimes from a completely different item). This avoided certain ICEs and was even correct by accident for the example in the doc comment, but it was just papering over the ICEs causing other examples (where the impl trait is outside the current impl block) to fail. I am looking into this new ICE now
I am getting locally before the ICE, so likely the ICE just hides actual errors. Should still fix that of course, but needs more looking into it
I think you need to use 2018 or 2021 edition.
minimized and edition-free: The problem is that typeck runs some of old borrowck/regionck and that just can't handle GAT and associated TAIT being used together. While worked in this specific case, that function won't work if the TAIT were declared outside the impl block and only used, so the following would just hit a different ICE, even though it should be equivalent (except that the defining use scope is the surrounding module instead of just the impl block).
So... turns out this works just fine with nll... I'd say we just wait for that, nll is only blocked on diagnostics, and those are actively being worked on:
I've found this does work if adding a bound on the TAIT: . It seems to me that should be required, so accepting code without it was actually a bug? Also, how does this work with NLL? I add and it still ICEs. (see the playground). Is there anything else needed for enabling NLL?
It seems the linked example on the playground does not ICE on the 2021-08-03 nightly.
that's with the fixed . Without it it ICEs, both with and without NLL
Hum, indeed, the 2 minimized examples Oli mentioned in do ICE with or without .
oof, not sure what I tested here -.- I'll investigate again. But yea, we can just error out instead of ICEing.
This, and no longer ICE since
GATs issue triage: not blocking. Fixed; needs test.
Change:
) { let span = cx .tcx <del> .get_attr(instance.def_id(), sym::target_feature) </del> <ins> .get_attrs(instance.def_id(), sym::target_feature) .next() </ins> .map_or_else(|| cx.tcx.def_span(instance.def_id()), |a| a.span); let msg = format!( "the target features {} must all be either enabled or disabled together",

Discussion:
currently happily ignores any additional attributes in case there are more than one. While this is fine for attributes which don't care about duplicates or emit a warning/error in case there are more than one, this isn't currently checked in the compiler, potentially causing bugs. similar to the check in we should check that the attr declaration in has an acceptable way of dealing with duplicates. in case there are any questions on how to implement this, feel free to open a thread on zulip and pinging me there. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
} /// Iterates over the language items in the given crate. <del> fn get_lang_items(self, tcx: TyCtxt<'tcx>) -> &'tcx [(DefId, usize)] { tcx.arena.alloc_from_iter( self.root .lang_items .decode(self) .map(|(def_index, index)| (self.local_def_id(def_index), index)), ) </del> <ins> fn get_lang_items(self) -> impl Iterator<Item = (DefId, usize)> + 'a { self.root .lang_items .decode(self) .map(move |(def_index, index)| (self.local_def_id(def_index), index)) </ins> } /// Iterates over the diagnostic items in the given crate.

Discussion:
(Using + ) (Minimized from ) : <details<summary<strongBacktrace</strong</summary<p</p</detailscc
One thing I forgot to do is check that my minimization is exhaustive. After deleting all the from the original crate it still ICEs, so there must be another way that it is triggering this too.
Could this issue be related/duplicate of (and therefore fixed by )? Also, perhaps replace the team label with ?
I assume you meant ? That was included in which I tested with (we have a collection of failing crates in that I am rebuilding as each fix for the fallout from lands).
Fixed in
Change:
// We encode uses of statics as a `*&STATIC` where the `&STATIC` part is // a constant reference (or constant raw pointer for `static mut`) in MIR Res::Def(DefKind::Static, id) => { <del> let ty = cx.tcx.type_of(id); let ty = if cx.tcx.is_mutable_static(id) { cx.tcx.mk_mut_ptr(ty) } else if cx.tcx.is_foreign_item(id) { cx.tcx.mk_imm_ptr(ty) } else { cx.tcx.mk_imm_ref(cx.tcx.lifetimes.re_static, ty) }; </del> <ins> let ty = cx.tcx.static_ptr_ty(id); </ins> let ptr = cx.tcx.alloc_map.lock().create_static_alloc(id); let temp_lifetime = cx.region_scope_tree.temporary_scope(expr.hir_id.local_id); ExprKind::Deref { arg: Expr {

Discussion:
I have some code which asynchronously computes an integer, and selects an item from a static slice in the same expression. This used to work (it does on stable), but after a nightly update the compiler ICEs when computing generator layout. The bug stops reproducing if I change the static to a local variable, or extract the index into a separate variable. rustc 1.41.0-nightly ( 2019-11-23) binary: rustc commit-hash: commit-date: 2019-11-23 host: x86_64-unknown-linux-gnu release: 1.41.0-nightly LLVM version: 9.0
De-nominating from compiler team as we have a fix pending.
triage: P-high.
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. fn foo1<T:Copy<U>, U>(x: T) {} //~^ ERROR: wrong number of type arguments: expected 0, found 1 trait Trait: Copy<Send> {} //~^ ERROR: wrong number of type arguments: expected 0, found 1 struct MyStruct1<T: Copy<T>>; //~^ ERROR wrong number of type arguments: expected 0, found 1 struct MyStruct2<'a, T: Copy<'a>>; //~^ ERROR: wrong number of lifetime parameters: expected 0, found 1 fn foo2<'a, T:Copy<'a, U>, U>(x: T) {} //~^ ERROR: wrong number of type arguments: expected 0, found 1 //~^^ ERROR: wrong number of lifetime parameters: expected 0, found 1 fn main() { } </ins>

Discussion:
Example: I left a FIXME at the relevant part of the code.
Nominating for something.
I can mentor...
I'm willing to have a look if the mentor offer stands
I already have a proposed fix, I just need to clean it up and add a test.
thanks for volunteering. The offer is still up but has been working on it. I'm happy to help with other bugs too.
Change:
ecx.read_discriminant(op).unwrap().1 } <ins> /// Turn an interpreter error into something to report to the user. /// As a side-effect, if RUSTC_CTFE_BACKTRACE is set, this prints the backtrace. /// Should be called only if the error is actually going to to be reported! </ins> pub fn error_to_const_error<'mir, 'tcx>( ecx: &InterpCx<'mir, 'tcx, CompileTimeInterpreter<'mir, 'tcx>>, mut error: InterpErrorInfo<'tcx>,

Discussion:
The idea behind was that it should only show a backtrace (of where a Miri error originates) when an error is actually shown to the user. And that worked fine when I implemented it. But since then, something changed in constprop, and now I get thousands of backtraces even for crates with no errors, making the env var basically unusable. That is a big problem for debugging of the Miri engine. Even shouldn't show so many errors, but that will be harder to do for constprop which runs the CTFE engine on broken and non-monomorphized MIR (causing tons of problems, not just this). AFAIK you did a bunch of const_prop changes over the last few weeks/months; likely some of what you did is the culprit here. Any ideas?
Well. Const prop tries to eval things and if it fails it doesn't prop. The reason why there are many errors now is that we are actually using the interpcx instead of reimplementing its logic
I'm not sure how to reduce your noise. Maybe we can disable the env var before const prop and reenable after?
only prints when  is explicitly called -- somehow constprop must be triggering that. If that was fixed, things would still be slow because so many backtraces are captured, but at least the result should be readable.
The really fancy solution, but probably too magic, would be to determine if we are running inside a const_prop query and let that alter the behavior. AFAIK rustc uses thread-local storage so this could actually be done, but it might not be how that TLS is supposed to be used.
my guess is that the printing originates here: calls , but that line does not always result in an error to be shown, right?
Change:
<del> //@ known-bug: #122914 use std::future::Future; use std::pin::Pin; impl<'a, F> Poll { fn project<'_>(self: Pin<&'pin mut Future>) -> Projection<'pin, 'a, F> { me.local_set.with(|| { let _ = self.poll(cx); }) } } </del>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: self-type for ObjectPick never dereferenced to an object', 'error: internal compiler error: self-type for ObjectPick never dereferenced to an object' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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: [typeck] type-checking [analysis] running analysis passes on this crate --
bisects to cc
Change:
<ins> // check-pass // edition:2015 use {}; use {{}}; use ::{}; use {::{}}; 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
Regression from
Fixed in
Change:
assert::is_transmutable::<Pair<V1, MaybeUninit<u8>>, OptionLike>(); assert::is_transmutable::<Pair<V2, MaybeUninit<u8>>, OptionLike>(); } <ins> fn niche_fields() { enum Kind { A(bool, bool), B(bool), } assert::is_maybe_transmutable::<u16, Kind>(); } </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'Size::sub: 0 - 1 would result in negative size'', 'thread 'rustc' panicked at 'Size::sub: 0 - 1 would result in negative size'' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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: [evaluateobligation] evaluating trait selection obligation [typeck] type-checking [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
On it! Thanks for the report.
Further minimized:
The cause here is neat. here is niche optimizable, with its second variant being subject to niche optimization. Typically, a niche-optimized enum has one tagless variant, and zero or more tagged variants laid out in the usual manner: the tag is placed, and then the rest of the fields follow. But reveals that's not what happens here. Because is a ZST, is placed at offset , rather than (following the tag). In other words: the tag is co-located with the field. This produces an ICE, because our assumption that fields follow tag is violated (a checked sub panics).
claim
Change:
}; // since CopyNonOverlapping is parametrized by 1 type, // we only need to check that they are equal and not keep an extra parameter. <del> if op_src_ty != op_dst_ty { </del> <ins> if !self.mir_assign_valid_types(op_src_ty, op_dst_ty) { </ins> self.fail(location, format!("bad arg ({:?} != {:?})", op_src_ty, op_dst_ty)); }

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 from glacier / <!-- 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
another case 
Probably caused by cc
Oops. That's my b, I'll have a PR up in 10 minutes
Change:
use std::collections::HashSet; use std::io::{fs, TempDir, Command}; use std::io; <ins> use std::mem; </ins> use std::ptr; use std::str; use std::string::String;

Discussion:
There's another bug in LLDB that causes it to segfault when reading archive files. This one has already been fixed in May () but it still exists in a lot of LLDB binaries out there. As far as I can tell, the bug occurs when a number of object files are stored in an archive and the last one ends at an uneven byte offset. This often seems to be the case for compressed byte-code archives in rlibs (maybe regular object files are always padded to an even size?). I'm currently compiling a possible workaround (pad the bytecode objects to an even size). It would be good if we could allow for rust code to be debugged with older LLDB versions too.
Update: Padding all archives entries to an even size seems to prevent the crash in LLDB and I have not seen any detrimental side effects to this approach so far. Any idea if the additional padding byte at the end of the compressed LLVM IR object in an archive could potentially lead to a problem?
I'm not familiar enough with the format of object files or bytecode files to know whether an extra byte or two at the end would corrupt them, but if it's working ok currently then I'd just ship it!
I doubt that the containing archive will care about the padding byte, but either the decompression algorithm or the LLVM bitcode reader could trip over it. The safe way to do this would probably be to prepend the actual size of the compressed data, so we always know how much data to pass to . I guess, I'll implement this and make a pull request.
Thinking about it, changing the format here is not as so trivial since the compiler must handle libs with the old format differently from libs with the new format. I see two options: (1) Just add the padding byte and hope for the best (2) Introduce some kind of header (including a version byte) before the compressed bitcode, in order to future-proof this against other changes to the encoding. I think I'd favor option (2).
Is this only a problem for the bytecode in archives, or is it also a problem for object files?
So far it has only occurred for bytecode. All object files I came across had a size dividable by 2. I don't know if that's a coincidence...
Interesting!

I'm all for putting the bytecode in whatever format we want (it's already just a huge deflated stream)
I'll come up with something and then we can discuss the matter further when we have some code to look at in a PR, OK?
Sounds good to me!
Change:
<ins> error[E0317]: if may be missing an else clause --> $DIR/issue-66387-if-without-else.rs:3:5 | LL | /     if true { LL | |         return 0; LL | |     } | |_____^ expected (), found i32 | = note: expected type `()` found type `i32` = note: `if` expressions without `else` evaluate to `()` = help: consider adding an `else` block that evaluates to the expected type error: aborting due to previous error For more information about this error, try `rustc --explain E0317`. </ins>

Discussion:
() Triggers on playground on beta and nightly channels, not on stable. Stacktrace:
Even smaller sample (from
triage: P-high. Removing nomination.
triage: P-high, removing nomination label.
Change:
<ins> error[E0700]: hidden type for `impl Future<Output = impl Sized>` captures lifetime that does not appear in bounds --> $DIR/nested-return-type4.rs:4:5 | LL | fn test<'s: 's>(s: &'s str) -> impl std::future::Future<Output = impl Sized> { |         -- hidden type `[async block@$DIR/nested-return-type4.rs:4:5: 4:31]` captures the lifetime `'s` as defined here LL |     async move { let _s = s; } |     ^^^^^^^^^^^^^^^^^^^^^^^^^^ | help: to declare that `impl Future<Output = impl Sized>` captures `'s`, you can add an explicit `'s` lifetime bound | LL | fn test<'s: 's>(s: &'s str) -> impl std::future::Future<Output = impl Sized> + 's { |                                                                              ++++ help: to declare that `impl Sized` captures `'s`, you can add an explicit `'s` lifetime bound | LL | fn test<'s: 's>(s: &'s str) -> impl std::future::Future<Output = impl Sized + 's> { |                                                                             ++++ error: aborting due to previous error For more information about this error, try `rustc --explain E0700`. </ins>

Discussion:
The following compiles on the current nightly (1.67.0-nightly (2022-12-03 )) although it shouldn't: It is correctly rejected by the current beta: 1.66.0-beta.2 (2022-11-20 ). This is most likely (I haven't bisected though!). Cc label C-bug T-compiler I-unsound regression-from-stable-to-nightly A-impl-trait
WG-prioritization assigning priority (). label -I-prioritize +P-high