jiebi/CodeConvo huggingface dataset:
Code change:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: Unexpected coroutine/closure type in variance computation', 'error: internal compiler error: Unexpected coroutine/closure type in variance computation' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [cratevariances] computing the variances for items in this crate [variancesof] computing the variances of [mirborrowck] borrow-checking [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
smaller
ice since it seems
i can look into this claim

Related discussion:
text: // Don't leak types into signatures unless they're nameable! // For example, if a function returns itself, we don't want that // recursive function definition to leak out into the fn sig. <del> let mut should_recover = false; </del> <ins> let mut recovered_ret_ty = None; </ins> <del> if let Some(ret_ty) = ret_ty.make_suggestable(tcx, false, None) { </del> <ins> if let Some(suggestable_ret_ty) = ret_ty.make_suggestable(tcx, false, None) { </ins> diag.span_suggestion( ty.span, "replace with the correct return type", <del> ret_ty, </del> <ins> suggestable_ret_ty, </ins> Applicability::MachineApplicable, ); <del> should_recover = true; </del> <ins> recovered_ret_ty = Some(suggestable_ret_ty); </ins> } else if let Some(sugg) = suggest_impl_trait(&tcx.infer_ctxt().build(), tcx.param_env(def_id), ret_ty) {
Code change:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: Unexpected coroutine/closure type in variance computation', 'error: internal compiler error: Unexpected coroutine/closure type in variance computation' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [cratevariances] computing the variances for items in this crate [variancesof] computing the variances of [mirborrowck] borrow-checking [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
smaller
ice since it seems
i can look into this claim

Related discussion:
text: } let guar = diag.emit(); <del> if should_recover { ty::Binder::dummy(fn_sig) } else { ty::Binder::dummy(tcx.mk_fn_sig( fn_sig.inputs().iter().copied(), Ty::new_error(tcx, guar), fn_sig.c_variadic, fn_sig.unsafety, fn_sig.abi, )) } </del> <ins> ty::Binder::dummy(tcx.mk_fn_sig( fn_sig.inputs().iter().copied(), recovered_ret_ty.unwrap_or_else(|| Ty::new_error(tcx, guar)), fn_sig.c_variadic, fn_sig.unsafety, fn_sig.abi, )) </ins> } None => icx.lowerer().lower_fn_ty( hir_id,
Code change:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: Unexpected coroutine/closure type in variance computation', 'error: internal compiler error: Unexpected coroutine/closure type in variance computation' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [cratevariances] computing the variances for items in this crate [variancesof] computing the variances of [mirborrowck] borrow-checking [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
smaller
ice since it seems
i can look into this claim

Related discussion:
text: } ty::FnDef(..) | ty::Coroutine(..) | ty::Closure(..) | ty::CoroutineClosure(..) => { <del> bug!("Unexpected coroutine/closure type in variance computation"); </del> <ins> bug!("Unexpected unnameable type in variance computation: {ty}"); </ins> } ty::Ref(region, ty, mutbl) => {
Code change:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: Unexpected coroutine/closure type in variance computation', 'error: internal compiler error: Unexpected coroutine/closure type in variance computation' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [cratevariances] computing the variances for items in this crate [variancesof] computing the variances of [mirborrowck] borrow-checking [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
smaller
ice since it seems
i can look into this claim

Related discussion:
text: <ins> // Test variance computation doesn't explode when we leak unnameable // types due to `-> _` recovery. pub struct Type<'a>(&'a ()); pub fn g() {} pub fn f<T>() -> _ { //~^ ERROR the placeholder `_` is not allowed within types on item signatures g } fn main() {} </ins>
Code change:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: Unexpected coroutine/closure type in variance computation', 'error: internal compiler error: Unexpected coroutine/closure type in variance computation' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [cratevariances] computing the variances for items in this crate [variancesof] computing the variances of [mirborrowck] borrow-checking [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
smaller
ice since it seems
i can look into this claim

Related discussion:
text: <ins> error[E0121]: the placeholder `_` is not allowed within types on item signatures for return types --> $DIR/leaking-unnameables.rs:8:18 | LL | pub fn f<T>() -> _ { |                  ^ |                  | |                  not allowed in type signatures |                  help: replace with the correct return type: `fn()` error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0121`. </ins>
Code change:
This happens when compiling the crate with . : The backtrace and output here are obtained during cross-compilation (host , target , build-std), but the panic also happens when the host is Windows and without build-std. <details<summary<strongBacktrace</strong</summary<p</p</details
Minimized:

Related discussion:
text: submit_post_lto_module_to_llvm, submit_pre_lto_module_to_llvm, ComputedLtoType, OngoingCodegen, }; use crate::common::{self, IntPredicate, RealPredicate, TypeKind}; <ins> use crate::meth::load_vtable; </ins> use crate::mir::operand::OperandValue; use crate::mir::place::PlaceRef; use crate::traits::*;
Code change:
This happens when compiling the crate with . : The backtrace and output here are obtained during cross-compilation (host , target , build-std), but the panic also happens when the host is Windows and without build-std. <details<summary<strongBacktrace</strong</summary<p</p</details
Minimized:

Related discussion:
text: if let Some(entry_idx) = vptr_entry_idx { let ptr_size = bx.data_layout().pointer_size; <del> let ptr_align = bx.data_layout().pointer_align.abi; </del> let vtable_byte_offset = u64::try_from(entry_idx).unwrap() * ptr_size.bytes(); <del> let gep = bx.inbounds_ptradd(old_info, bx.const_usize(vtable_byte_offset)); let new_vptr = bx.load(bx.type_ptr(), gep, ptr_align); bx.nonnull_metadata(new_vptr); // VTable loads are invariant. bx.set_invariant_load(new_vptr); new_vptr </del> <ins> load_vtable(bx, old_info, bx.type_ptr(), vtable_byte_offset, source, true) </ins> } else { old_info }
Code change:
This happens when compiling the crate with . : The backtrace and output here are obtained during cross-compilation (host , target , build-std), but the panic also happens when the host is Windows and without build-std. <details<summary<strongBacktrace</strong</summary<p</p</details
Minimized:

Related discussion:
text: let llty = bx.fn_ptr_backend_type(fn_abi); let ptr_size = bx.data_layout().pointer_size; <del> let ptr_align = bx.data_layout().pointer_align.abi; </del> let vtable_byte_offset = self.0 * ptr_size.bytes(); <del> if bx.cx().sess().opts.unstable_opts.virtual_function_elimination && bx.cx().sess().lto() == Lto::Fat { let typeid = bx .typeid_metadata(typeid_for_trait_ref(bx.tcx(), expect_dyn_trait_in_self(ty))) .unwrap(); let func = bx.type_checked_load(llvtable, vtable_byte_offset, typeid); func } else { let gep = bx.inbounds_ptradd(llvtable, bx.const_usize(vtable_byte_offset)); let ptr = bx.load(llty, gep, ptr_align); // VTable loads are invariant. bx.set_invariant_load(ptr); if nonnull { bx.nonnull_metadata(ptr); } ptr } </del> <ins> load_vtable(bx, llvtable, llty, vtable_byte_offset, ty, nonnull) </ins> } pub(crate) fn get_optional_fn<Bx: BuilderMethods<'a, 'tcx>>(
Code change:
This happens when compiling the crate with . : The backtrace and output here are obtained during cross-compilation (host , target , build-std), but the panic also happens when the host is Windows and without build-std. <details<summary<strongBacktrace</strong</summary<p</p</details
Minimized:

Related discussion:
text: self, bx: &mut Bx, llvtable: Bx::Value, <ins> ty: Ty<'tcx>, </ins> ) -> Bx::Value { // Load the data pointer from the object. debug!("get_int({:?}, {:?})", llvtable, self); let llty = bx.type_isize(); let ptr_size = bx.data_layout().pointer_size; <del> let ptr_align = bx.data_layout().pointer_align.abi; </del> let vtable_byte_offset = self.0 * ptr_size.bytes(); <del> let gep = bx.inbounds_ptradd(llvtable, bx.const_usize(vtable_byte_offset)); let ptr = bx.load(llty, gep, ptr_align); // VTable loads are invariant. bx.set_invariant_load(ptr); ptr </del> <ins> load_vtable(bx, llvtable, llty, vtable_byte_offset, ty, false) </ins> } } /// This takes a valid `self` receiver type and extracts the principal trait <del> /// ref of the type. fn expect_dyn_trait_in_self(ty: Ty<'_>) -> ty::PolyExistentialTraitRef<'_> { </del> <ins> /// ref of the type. Return `None` if there is no principal trait. fn dyn_trait_in_self(ty: Ty<'_>) -> Option<ty::PolyExistentialTraitRef<'_>> { </ins> for arg in ty.peel_refs().walk() { if let GenericArgKind::Type(ty) = arg.unpack() && let ty::Dynamic(data, _, _) = ty.kind() { <del> return data.principal().expect("expected principal trait object"); </del> <ins> return data.principal(); </ins> } }
Code change:
This happens when compiling the crate with . : The backtrace and output here are obtained during cross-compilation (host , target , build-std), but the panic also happens when the host is Windows and without build-std. <details<summary<strongBacktrace</strong</summary<p</p</details
Minimized:

Related discussion:
text: cx.vtables().borrow_mut().insert((ty, trait_ref), vtable); vtable } <ins> /// Call this function whenever you need to load a vtable. pub(crate) fn load_vtable<'a, 'tcx, Bx: BuilderMethods<'a, 'tcx>>( bx: &mut Bx, llvtable: Bx::Value, llty: Bx::Type, vtable_byte_offset: u64, ty: Ty<'tcx>, nonnull: bool, ) -> Bx::Value { let ptr_align = bx.data_layout().pointer_align.abi; if bx.cx().sess().opts.unstable_opts.virtual_function_elimination && bx.cx().sess().lto() == Lto::Fat { if let Some(trait_ref) = dyn_trait_in_self(ty) { let typeid = bx.typeid_metadata(typeid_for_trait_ref(bx.tcx(), trait_ref)).unwrap(); let func = bx.type_checked_load(llvtable, vtable_byte_offset, typeid); return func; } else if nonnull { bug!("load nonnull value from a vtable without a principal trait") } } let gep = bx.inbounds_ptradd(llvtable, bx.const_usize(vtable_byte_offset)); let ptr = bx.load(llty, gep, ptr_align); // VTable loads are invariant. bx.set_invariant_load(ptr); if nonnull { bx.nonnull_metadata(ptr); } ptr } </ins>
Code change:
This happens when compiling the crate with . : The backtrace and output here are obtained during cross-compilation (host , target , build-std), but the panic also happens when the host is Windows and without build-std. <details<summary<strongBacktrace</strong</summary<p</p</details
Minimized:

Related discussion:
text: sym::vtable_align => ty::COMMON_VTABLE_ENTRIES_ALIGN, _ => bug!(), }; <del> let value = meth::VirtualIndex::from_index(idx).get_usize(bx, vtable); </del> <ins> let value = meth::VirtualIndex::from_index(idx).get_usize(bx, vtable, callee_ty); </ins> match name { // Size is always <= isize::MAX. sym::vtable_size => {
Code change:
This happens when compiling the crate with . : The backtrace and output here are obtained during cross-compilation (host , target , build-std), but the panic also happens when the host is Windows and without build-std. <details<summary<strongBacktrace</strong</summary<p</p</details
Minimized:

Related discussion:
text: // Load size/align from vtable. let vtable = info.unwrap(); let size = meth::VirtualIndex::from_index(ty::COMMON_VTABLE_ENTRIES_SIZE) <del> .get_usize(bx, vtable); </del> <ins> .get_usize(bx, vtable, t); </ins> let align = meth::VirtualIndex::from_index(ty::COMMON_VTABLE_ENTRIES_ALIGN) <del> .get_usize(bx, vtable); </del> <ins> .get_usize(bx, vtable, t); </ins> // Size is always <= isize::MAX. let size_bound = bx.data_layout().ptr_sized_integer().signed_max() as u128;
Code change:
This happens when compiling the crate with . : The backtrace and output here are obtained during cross-compilation (host , target , build-std), but the panic also happens when the host is Windows and without build-std. <details<summary<strongBacktrace</strong</summary<p</p</details
Minimized:

Related discussion:
text: <del> //@ known-bug: #123955 //@ compile-flags: -Clto -Zvirtual-function-elimination //@ only-x86_64 pub fn main() { _ = Box::new(()) as Box<dyn Send>; } </del>
Code change:
This happens when compiling the crate with . : The backtrace and output here are obtained during cross-compilation (host , target , build-std), but the panic also happens when the host is Windows and without build-std. <details<summary<strongBacktrace</strong</summary<p</p</details
Minimized:

Related discussion:
text: <del> //@ known-bug: #124092 //@ compile-flags: -Zvirtual-function-elimination=true -Clto=true //@ only-x86_64 const X: for<'b> fn(&'b ()) = |&()| (); fn main() { let dyn_debug = Box::new(X) as Box<fn(&'static ())> as Box<dyn Send>; } </del>
Code change:
This happens when compiling the crate with . : The backtrace and output here are obtained during cross-compilation (host , target , build-std), but the panic also happens when the host is Windows and without build-std. <details<summary<strongBacktrace</strong</summary<p</p</details
Minimized:

Related discussion:
text: <ins> //@ build-pass //@ compile-flags: -Zvirtual-function-elimination=true -Clto=true //@ only-x86_64 //@ no-prefer-dynamic // issue #123955 pub fn test0() { _ = Box::new(()) as Box<dyn Send>; } // issue #124092 const X: for<'b> fn(&'b ()) = |&()| (); pub fn test1() { let _dyn_debug = Box::new(X) as Box<fn(&'static ())> as Box<dyn Send>; } fn main() {} </ins>
Code change:
As of current nightly, produces this: which is not valid Rust syntax. The correct output would contain . tracking issue:

Related discussion:
text: self.space(); } MatchKind::Postfix => { <del> self.print_expr_as_cond(expr); </del> <ins> self.print_expr_maybe_paren(expr, parser::PREC_POSTFIX, fixup); </ins> self.word_nbsp(".match"); } }
Code change:
As of current nightly, produces this: which is not valid Rust syntax. The correct output would contain . tracking issue:

Related discussion:
text: <del> #![feature(postfix_match)] fn main() { let val = Some(42); val.match { Some(_) => 2, _ => 1 }; Some(2).match { Some(_) => true, None => false }.match { false => "ferris is cute", true => "I turn cats in to petted cats", }.match { _ => (), } } </del>
Code change:
As of current nightly, produces this: which is not valid Rust syntax. The correct output would contain . tracking issue:

Related discussion:
text: <ins> #![feature(prelude_import)] #![no_std] #![feature(postfix_match)] #[prelude_import] use ::std::prelude::rust_2015::*; #[macro_use] extern crate std; use std::ops::Add; //@ pretty-mode:expanded //@ pp-exact:precedence.pp macro_rules! repro { ($e:expr) => { $e.match { _ => {} } }; } struct Struct {} impl Add<Struct> for usize { type Output = (); fn add(self, _: Struct) -> () { () } } pub fn main() { let a; ( { 1 } + 1).match { _ => {} }; (4 as usize).match { _ => {} }; (return).match { _ => {} }; (a = 42).match { _ => {} }; (|| {}).match { _ => {} }; (42..101).match { _ => {} }; (1 + Struct {}).match { _ => {} }; } </ins>
Code change:
As of current nightly, produces this: which is not valid Rust syntax. The correct output would contain . tracking issue:

Related discussion:
text: <ins> #![feature(postfix_match)] use std::ops::Add; //@ pretty-mode:expanded //@ pp-exact:precedence.pp macro_rules! repro { ($e:expr) => { $e.match { _ => {} } }; } struct Struct {} impl Add<Struct> for usize { type Output = (); fn add(self, _: Struct) -> () { () } } pub fn main() { let a; repro!({ 1 } + 1); repro!(4 as usize); repro!(return); repro!(a = 42); repro!(|| {}); repro!(42..101); repro!(1 + Struct {}); } </ins>
Code change:
As of current nightly, produces this: which is not valid Rust syntax. The correct output would contain . tracking issue:

Related discussion:
text: <ins> #![feature(postfix_match)] fn main() { let val = Some(42); val.match { Some(_) => 2, _ => 1 }; Some(2).match { Some(_) => true, None => false }.match { false => "ferris is cute", true => "I turn cats in to petted cats", }.match { _ => (), } } </ins>
Code change:
Sometimes when things go really wrong the compiler emits a ton of error messages. This can actually take a while to render them all. And since somewhat recently, hitting Ctrl-C no longer interrupts that, I get a thousand error messages displayed after Ctrl-C. I suspect this may have to do with The Ctrl-C handler does nothing at all on the first Ctrl-C unless the compiler is in the middle of const-eval. Cc
Do you have a reproducer? I have not run into this myself. The implementation should also ensure that the compiler exits promptly if you hit ctrl+c again. Does it?
if stuff keeps going on ctrl+c, sometimes suspending the process (ctrl+z) and then killing the terminal does the trick somehow :sweat_smile:
Unfortunately no, I encountered this during some rustc hacking where I ended up getting well over 1k error messages in the standard library build and that turned out to be hard to cancel. I thought I had tried that, but I am not entirely sure.
Is it possible the shell is part of the problem? If, by the time you hit ctrl-c, it's working through a large amount of output it still has buffered then it might be awhile before you see a response.
It's possible, sure -- but usually it reacts to Ctrl-C immediately even when there's tons of output.
Have you tried reverting to check if that fixes it?
No. At the time I was busy getting a PR done and now I don't have a reproducing example any more.
only checks for ctrl-c during const eval, so if no const eval runs for an extended period of time, the ctrl-c will be silently ignored. This is not the only problem with that PR. It also caused , and shows the "compilation was interrupted" error after the prompt is already drawn by bash.
is there a good way to make rustc loop endlessly without ever touching const eval? maybe via the trait solver? :thinking: it would help for debugging this.
Yeah, just take any issue (none are anyway). I can reproduce this issue with for example: nightly-2024-03-26 (before ): Exits after a single ^C nightly-2024-03-27 (after ): Requires ^C^C to exit bjorn3's analysis checks out.
cool! I wasn't sure how much of the compiler's code flowed through const-eval, is why I asked.
Another case where this is observed: IMO we should revert or at least make the signal handler run after a short timeout.
I'll post a PR that adds a timeout later today, but by all means if you feel strongly just put up a PR. The initial handler here was just through the normal PR process, there's no reason to be more cautious on reverting or modifying it.

Related discussion:
text: use std::str; use std::sync::atomic::{AtomicBool, Ordering}; use std::sync::{Arc, OnceLock}; <del> use std::time::{Instant, SystemTime}; </del> <ins> use std::time::{Duration, Instant, SystemTime}; </ins> use time::OffsetDateTime; use tracing::trace;
Code change:
These types are now, however, the docs don't properly mention them everywhere yet: lists OnceCell in the overview, but not LazyCell. The docs should also explain when I should use which of these types, as they are superficially pretty similar. lists Once and OnceLock, but not LazyLock. The same point about "when to use which type" applies. (It seems like is basically the same as , but I am not sure.) Cc
thatnks for the PR! The question of Once vs OnceLock seems to remain unresolved though. If Once is to OnceLock what is to Mutex, then it should probably be considered extremely niche as one can't even safely protect any data that way?
Yeah, I do indeed have nothing useful to say about Once, basically, because it doesn't seem very useful except as a raw implementation primitive of OnceLock. I suppose we could add a comment that soft-discourages it?
Yeah I think that would be useful.

Related discussion:
text: //! //! The corresponding [`Sync`] version of `OnceCell<T>` is [`OnceLock<T>`]. //! <ins> //! ## `LazyCell<T, F>` //! //! A common pattern with OnceCell is, for a given OnceCell, to use the same function on every //! call to [`OnceCell::get_or_init`] with that cell. This is what is offered by [`LazyCell`], //! which pairs cells of `T` with functions of `F`, and always calls `F` before it yields `&T`. //! This happens implicitly by simply attempting to dereference the LazyCell to get its contents, //! so its use is much more transparent with a place which has been initialized by a constant. //! //! More complicated patterns that don't fit this description can be built on `OnceCell<T>` instead. //! //! `LazyCell` works by providing an implementation of `impl Deref` that calls the function, //! so you can just use it by dereference (e.g. `*lazy_cell` or `lazy_cell.deref()`). //! //! The corresponding [`Sync`] version of `LazyCell<T, F>` is [`LazyLock<T, F>`]. </ins> //! //! # When to choose interior mutability //!
Code change:
These types are now, however, the docs don't properly mention them everywhere yet: lists OnceCell in the overview, but not LazyCell. The docs should also explain when I should use which of these types, as they are superficially pretty similar. lists Once and OnceLock, but not LazyLock. The same point about "when to use which type" applies. (It seems like is basically the same as , but I am not sure.) Cc
thatnks for the PR! The question of Once vs OnceLock seems to remain unresolved though. If Once is to OnceLock what is to Mutex, then it should probably be considered extremely niche as one can't even safely protect any data that way?
Yeah, I do indeed have nothing useful to say about Once, basically, because it doesn't seem very useful except as a raw implementation primitive of OnceLock. I suppose we could add a comment that soft-discourages it?
Yeah I think that would be useful.

Related discussion:
text: //! [`RwLock<T>`]: ../../std/sync/struct.RwLock.html //! [`Mutex<T>`]: ../../std/sync/struct.Mutex.html //! [`OnceLock<T>`]: ../../std/sync/struct.OnceLock.html <ins> //! [`LazyLock<T, F>`]: ../../std/sync/struct.LazyLock.html </ins> //! [`Sync`]: ../../std/marker/trait.Sync.html //! [`atomic`]: crate::sync::atomic