jiebi/CodeConvo huggingface dataset:
Change:
<!-- 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. --Haven't minimized it yet, so I won't upload for now <!-- 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. --: Coredump info <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
ping llvm
Hey LLVM ICE-breakers! This bug has been identified as a good "LLVM 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
Did that coredump link expire? I get 404...
It must have, I'll reupload it: (I think this one's once use? I can't find very good sites) If Rust recommends a specific site for temporary file uploads, I'm happy to upload it to that too Edit: uploaded to too (30 days)
Hmm, I downloaded it, but my local GDB doesn't make any sense of it without all of the mapped modules, it seems. It's not even enough to have just the matching toolchain at the right path. But I did manage to line up the offsets myself to find it in the disassembly -- it's this : and that value is zero, at least in the current state of the coredump. That came from the entry , which I think is the parameter, but it may have been modified: I'm not sure whether that is build-conditional. This LLVM library is also the product of LTO itself, so we could be looking at a meta-miscompilation here... <details<summaryFull assembly of that function</summary<p</p</details
It is, our non-alt builds don't enable assertions. For this kind of issue, a particularly minimal reproducer is not needed, just anything that is publicly sharable will do.
Here's the reproducer (I minimized it a bit by removing some modules/deps, but it's otherwise as is, new coredump is attached inside zip for debugging purposes)
Thanks, I can reproduce the crash with on with current LLVM HEAD.
Reduction for :

Discussion:
<del> Subproject commit 9168e236c548d1d0e9938ee6dd4cdbd308fdfd72 </del> <ins> Subproject commit fd336816c3a6d228dcef22171c43140f6fa7656f </ins>
Change:
() Note that this works even if implements in a non- way. This seems hightly problematic, especially provided we eventually want to support constructing at compile time. Relevant PR: Of course that impl claims to be unstable, but as we all know trait implementations are never unstable, unless the trait is unstable. (For ordinary traits, implementations of are thus unstable merely due to the fact that no user can use any such implementations in stable code yet.) label regression-from-stable-to-stable The fix should be straightforward: Remove the implementation (i.e. revert it to be non-), and add a test.
cc
that impl should be illegal, shouldn't it? I would expect us to need an explicit here. But also, reverting and maybe even backporting that impl for now seems like the right choice to me
Good catch! Actually calling this leads to odd behavior: It doesn't even say what went wrong. I expected an error saying a non-const function was called as part of the drop glue.

Discussion:
} #[stable(feature = "rust1", since = "1.0.0")] <del> #[rustc_const_unstable(feature = "const_box", issue = "92521")] unsafe impl<#[may_dangle] T: ?Sized, A: Allocator> const Drop for Box<T, A> { </del> <ins> unsafe impl<#[may_dangle] T: ?Sized, A: Allocator> Drop for Box<T, A> { </ins> fn drop(&mut self) { // FIXME: Do nothing, drop is currently performed by compiler. }

*boxed = 42; assert!(*boxed == 42); <del> *boxed </del> <ins> *Box::leak(boxed) </ins> }; assert!(VALUE == 42);

<ins> const fn f<T>(_: Box<T>) {} //~^ ERROR destructors cannot be evaluated at compile-time fn main() {} </ins>

<ins> error[E0493]: destructors cannot be evaluated at compile-time --> $DIR/drop_box.rs:1:15 | LL | const fn f<T>(_: Box<T>) {} |               ^           - value is dropped here |               | |               constant functions cannot evaluate destructors error: aborting due to previous error For more information about this error, try `rustc --explain E0493`. </ins>
Change:
<!-- 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. --: with cc <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This would previously just throw an error but not "crash": `
I'll look into it. Thanks for the bug report!

Discussion:
ty::Float(float_ty) => output.push_str(float_ty.name_str()), ty::Foreign(def_id) => push_item_name(tcx, def_id, qualified, output), ty::Adt(def, substs) => { <del> let ty_and_layout = tcx.layout_of(ParamEnv::reveal_all().and(t)).expect("layout error"); </del> <ins> // `layout_for_cpp_like_fallback` will be `Some` if we want to use the fallback encoding. let layout_for_cpp_like_fallback = if cpp_like_debuginfo && def.is_enum() { match tcx.layout_of(ParamEnv::reveal_all().and(t)) { Ok(layout) => { if !wants_c_like_enum_debuginfo(layout) { Some(layout) } else { // This is a C-like enum so we don't want to use the fallback encoding // for the name. None } } Err(e) => { // Computing the layout can still fail here, e.g. if the target architecture // cannot represent the type. See https://github.com/rust-lang/rust/issues/94961. tcx.sess.fatal(&format!("{}", e)); } } } else { // We are not emitting cpp-like debuginfo or this isn't even an enum. None }; </ins> <del> if def.is_enum() && cpp_like_debuginfo && !wants_c_like_enum_debuginfo(ty_and_layout) { </del> <ins> if let Some(ty_and_layout) = layout_for_cpp_like_fallback { </ins> msvc_enum_fallback( tcx, ty_and_layout,

<ins> // Make sure the compiler does not ICE when trying to generate the debuginfo name of a type that // causes a layout error. See https://github.com/rust-lang/rust/issues/94961. // compile-flags:-C debuginfo=2 // build-fail // error-pattern: too big for the current architecture // normalize-stderr-64bit "18446744073709551615" -> "SIZE" // normalize-stderr-32bit "4294967295" -> "SIZE" #![crate_type = "rlib"] pub struct Foo<T>([T; usize::MAX]); pub fn foo() -> usize { std::mem::size_of::<Foo<u8>>() } </ins>

<ins> // Make sure the compiler does not ICE when trying to generate the debuginfo name of a type that // causes a layout error. // This version of the test already ICE'd before the commit that introduce the ICE described in // https://github.com/rust-lang/rust/issues/94961. // compile-flags:-C debuginfo=2 // build-fail // error-pattern: too big for the current architecture // normalize-stderr-64bit "18446744073709551615" -> "SIZE" // normalize-stderr-32bit "4294967295" -> "SIZE" #![crate_type = "rlib"] pub enum Foo<T> { Bar([T; usize::MAX]), } pub fn foo() -> usize { std::mem::size_of::<Foo<u8>>() } </ins>

<ins> error: values of the type `[u8; SIZE]` are too big for the current architecture error: aborting due to previous error </ins>
Change:
<!-- 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. -- rust- <!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
works fine, but crashes with ICE.
This is probably a duplicate of .
My guess is this is caused by . Specifically cc
(That might not be the cause though)
No, you're probably right I'll either erase regions during candidate assembly or use something infcx-local to probe if something is Copy. claim
Compiling with debug assertions on should be able to pinpoint exactly where things go wrong.
Bisecting this lead to though cc
Actually, I do agree that this is probably not due to . I can still fix this though, unless you're gonna take a look at it?
feel free to take a look. might be relevant here too (although it does look like a different problem).
Welp sorry
For either of the two Michaels looking at this: big thanks to for the from . ()
Here's a minimization I left on a duplicate issue: Note that without this does not ICE.
Marking as P-critical, since this seems to be getting hit by several people.
Also changing title and pinning to try to help curb some duplicates.
any solution!, I am still facing same error when i try to build
No, the PR that fixes this is blocked on a CI issue, which will not likely be resolved until tomorrow at this rate. You may find a temporary fix by downloading an old nightly revision with (e.g.) and setting that as your default for the time being, but please make sure to set it back later. Or, if your project does not use any nightly-only features, I recommend using or releases for now.
Thanks!
Same error! thread 'rustc' panicked at 'assertion failed: !value.hasescapingboundvars()', /rustc/compilerrustcmiddlesrcty note: rustc 1.61.0-nightly ( 2022-03-16) running on x86_64-pc-windows-msvc note: compiler flags: --crate-type lib -C embed-bitcode=no -C debuginfo=2
Pinning this at least for a day or so, since the nightly with the fix hasn't even been released.

Discussion:
let projection_bounds: SmallVec<[_; 4]> = trait_data .projection_bounds() .map(|bound| { <del> let ExistentialProjection { item_def_id, term, .. } = bound.skip_binder(); </del> <ins> let ExistentialProjection { item_def_id, term, .. } = tcx.erase_late_bound_regions(bound); </ins> // FIXME(associated_const_equality): allow for consts here (item_def_id, term.ty().unwrap()) })

<ins> // build-pass // compile-flags: -Cdebuginfo=2 --crate-type=rlib // Fixes issue #94998 pub trait Trait {} pub fn run(_: &dyn FnOnce(&()) -> Box<dyn Trait + '_>) {} </ins>
Change:
Load Open files panel on the left. Refresh page. You'll notice everytime you load the page, the file list slides again. So we now have to wait 1s for it to stop sliding before starting to read the file we clicked on. Btw, I'd rather this never slides at all. This is time loss anyway. Could there be an option to disable this?
So there are two different things here apparently: removing the animation Don't remember the file sidebar state Did I get it right?
Yes absolutely A single simple solution to both "things" could be to completely remove the animation. I don't know of any IDE that does this - probably because it isn't optimal with regards to ergonomics. The fact the new panel now slides the code so we can read the code and have the panel open at the same time is still an improvement over the previous panel, even if we revert the animation part.
I think the idea behind the animation is to allow the reader to see that it's not hovering the code. As for the setting, not sure. What do you think
I agree with we should remove the animation. It bothers me as well, I just haven't found the time to file an issue / PR about it. :-) I don't think we should add a setting.
Ok, I'll remove the animation then. Will send a PR tomorrow. For the setting, it's that we keep the current save the state of the sidebar. Should I remove it as well?
My idea of new setting was rather "should there be an animation or should it be static", if we didn't want to remove the animation completely, for those of us that don't think the animation is worth the wait (so no need for a such new setting if we just remove the animation completely :) ) With regards to the other setting idea you seem to be talking about, it seems reasonable to me to always keep the current state of the sidebar, as we currently do, and not add an extra setting for that either :)
Oh ok. Well, that cleared things up. I'll just remove the animation then.

Discussion:
.source .sidebar > *:not(#sidebar-toggle) { opacity: 0; visibility: hidden; <del> transition: opacity 0.5s; </del> } .source .sidebar.expanded {

display: none; } <del> /* It doesn't render well on mobile because of the layout, so better only have the transition on desktop. */ .rustdoc.source .sidebar { transition: width .5s; } </del> .source .sidebar.expanded { width: 300px; }

click: ".srclink" wait-for: "#sidebar-toggle" click: "#sidebar-toggle" <del> wait-for: 500 </del> fail: true assert-css: ("#source-sidebar", { "left": "-300px" })
Change:
Cross post from Works fine on stable Rust.
That post is written by me. I've opened a PR , and made some comments there. I'm not an expert on Rust, actually I'm an amateur programmer, and this is what I can do for now.
61.0-nightly ( 2022-03-22) works so this is a very recent nightly regression.
I see that too when compiling
same issue on ubuntu20
Maybe related to this issue. Here is a snippet of macro with on the match side: Pass with rustc 1.61.0-nightly ( 2022-03-22), you can try this snippet via Failed with rustc 1.61.0-nightly ( 2022-03-23), you can try this snippet via , the code can be expanded on playground with: Expand macros in code using the nightly compiler. 61.0-nightly (2022-03-19 )
The piece of code looks surprising, but bisection lead to
Ok, I found it :smile:
Thanks for the report. Should be an easy fix, I will get to it on Monday.
I think is right to some extent. Even in previous Rust version, stuff in the matcher is not so useful and will be ignored like normal comments : With rustc 1.61.0-nightly ( 2022-03-22) or other versions before, the result is: With rustc 1.61.0-nightly ( 2022-03-23), the result is:
Note that the playground's nightly is a few days old and cannot be upgraded because of how this issue affects ring ;-)
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
That's an interesting observation! But I'm not a language expert and I never intended to change behaviour in , so I will fix this problem by going back to the old behaviour.

Discussion:
} TokenTree::Token(t) => { <del> // Doc comments cannot appear in a matcher. debug_assert!(!matches!(t, Token { kind: DocComment(..), .. })); // If the token matches, we can just advance the parser. Otherwise, this // match hash failed, there is nothing to do, and hopefully another item in // `cur_items` will match. if token_name_eq(&t, token) { </del> <ins> // If it's a doc comment, we just ignore it and move on to the next tt in // the matcher. If the token matches, we can just advance the parser. // Otherwise, this match has failed, there is nothing to do, and hopefully // another item in `cur_items` will match. if matches!(t, Token { kind: DocComment(..), .. }) { item.idx += 1; self.cur_items.push(item); } else if token_name_eq(&t, token) { </ins> item.idx += 1; self.next_items.push(item); }

<ins> // check-pass // This is a valid macro. Commit 4 in #95159 broke things such that it failed // with a "missing tokens in macro arguments" error, as reported in #95267. macro_rules! f { ( /// ab ) => {}; } fn main() { f!(); } </ins>
Change:
<!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
minimized: claim
I am not sure if I am able to solve this ICE -- it has to do with the way that in traits are treated as async fn in some places, but not lowered as async fn in other places. That means there's a DefId that is not associated with a HIR Id, but I can't exactly track it down. release-assignment
I'm working on a return position impl traits change that is going to make it easier to lowering return position impl traits in traits and that would make async fns in traits easy. All this is in my todo list. I should be able to accomplish some of these things soon. not sure if you were going to work on this, but we can talk about this in Zulip if you want.
Triage: The ICE doesn't occur on the latest nightly, bisecting shows fixed it but I'm not 100% sure what PR did, perhaps ? Marking .

Discussion:
<ins> // edition:2018 // Regression test for #95307. // The ICE occurred on all the editions, specifying edition:2018 to reduce diagnostics. pub trait C { async fn new() -> [u8; _]; //~^ ERROR: functions in traits cannot be declared `async` //~| ERROR: using `_` for array lengths is unstable //~| ERROR: in expressions, `_` can only be used on the left-hand side of an assignment } fn main() {} </ins>

<ins> error[E0706]: functions in traits cannot be declared `async` --> $DIR/issue-95307.rs:7:5 | LL |     async fn new() -> [u8; _]; |     -----^^^^^^^^^^^^^^^^^^^^^ |     | |     `async` because of this | = note: `async` trait functions are not currently supported = note: consider using the `async-trait` crate: https://crates.io/crates/async-trait error[E0658]: using `_` for array lengths is unstable --> $DIR/issue-95307.rs:7:28 | LL |     async fn new() -> [u8; _]; |                            ^ | = note: see issue #85077 <https://github.com/rust-lang/rust/issues/85077> for more information = help: add `#![feature(generic_arg_infer)]` to the crate attributes to enable error: in expressions, `_` can only be used on the left-hand side of an assignment --> $DIR/issue-95307.rs:7:28 | LL |     async fn new() -> [u8; _]; |                            ^ `_` not allowed here error: aborting due to 3 previous errors Some errors have detailed explanations: E0658, E0706. For more information about an error, try `rustc --explain E0658`. </ins>
Change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --I recently updated my nightly toolchain and our project (still not open-sourced) ICE'd. I managed to reduce the problem to a minimal working example: <!-- 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</detailsI ran a quick : searched nightlies: from nightly-2022-03-01 to nightly-2022-03-24 regressed nightly: nightly-2022-03-16 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </detailsThe offending line is the , so we should probably tag this with the appropriate feature tag. (Sorry if I messed anything up, I'm completely new to Rust ICE bug reports!) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
probably due to my PR claim
I get the same error on code that I got minimized to:
Same error with this example:
Same error I got with this example Defining it in a trait is fine though But adding a function body results in a crash

Discussion:
use crate::infer::type_variable::{TypeVariableOrigin, TypeVariableOriginKind}; use crate::infer::{InferCtxt, InferOk, LateBoundRegionConversionTime}; use crate::traits::error_reporting::InferCtxtExt as _; <ins> use crate::traits::query::evaluate_obligation::InferCtxtExt as _; </ins> use crate::traits::select::ProjectionMatchesProjection; use rustc_data_structures::sso::SsoHashSet; use rustc_data_structures::stack::ensure_sufficient_stack;

// type parameters, opaques, and unnormalized projections have pointer // metadata if they're known (e.g. by the param_env) to be sized ty::Param(_) | ty::Projection(..) | ty::Opaque(..) <del> if tail.is_sized(selcx.tcx().at(obligation.cause.span), obligation.param_env) => </del> <ins> if selcx.infcx().predicate_must_hold_modulo_regions( &obligation.with( ty::Binder::dummy(ty::TraitRef::new( selcx.tcx().require_lang_item(LangItem::Sized, None), selcx.tcx().mk_substs_trait(self_ty, &[]), )) .without_const() .to_predicate(selcx.tcx()), ), ) => </ins> { true }

<ins> // check-pass // Test to check that pointee trait doesn't let region variables escape into the cache #![feature(ptr_metadata)] trait Bar: Sized + 'static {} struct Foo<B: Bar> { marker: std::marker::PhantomData<B>, } impl<B: Bar> Foo<B> { fn foo<T: ?Sized>(value: &T) { std::ptr::metadata(value); } } fn main() {} </ins>
Change:
I tried this code: I expected to see this happen: Print the content of the $123 environment variable Instead, this happened: It literally prints $123 : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It is the shell that resolves environment variables. You're not using a shell here, just directly executing a command. This is behaving as expected.
Indeed, this is the expected behavior. This can be circumvented by actually using a shell, e.g. on POSIX:
I did a quick check on the doc for Note that the argument is not passed through a shell, but given literally to the program. This means that shell syntax like quotes, escaped characters, word splitting, glob patterns, substitution, etc. have no effect. I guess we can expand "substitution" into "variable substitution" to make it more clear.
so is this just a documentation change? claim

Discussion:
/// /// Note that the argument is not passed through a shell, but given /// literally to the program. This means that shell syntax like quotes, <del> /// escaped characters, word splitting, glob patterns, substitution, etc. </del> <ins> /// escaped characters, word splitting, glob patterns, variable substitution, etc. </ins> /// have no effect. /// /// # Examples

/// /// Note that the arguments are not passed through a shell, but given /// literally to the program. This means that shell syntax like quotes, <del> /// escaped characters, word splitting, glob patterns, substitution, etc. </del> <ins> /// escaped characters, word splitting, glob patterns, variable substitution, etc. </ins> /// have no effect. /// /// # Examples
Change:
As the title says, the crash disappeared once we set the on i686-pc-windows-msvc target spec. Could we disable it? cc (the codebase is really huge, cannot generate a small test case) was enabled in
cc
Disabling it for i686 sounds reasonable if it's still causing issues. It is unfortunate we don't have a test case though. I'll make a quick PR.
It would still be great if we could have a regression test case to put into our test suite, otherwise some time down the line somebody might end up re-enabling TLS on the affected platform again.
I wonder if the crash here is an example of the issue works around (or hopes to, anyway).
Would you be able to reproduce this bug?

Discussion:
.entry(LinkerFlavor::Lld(LldFlavor::Link)) .or_default() .extend(pre_link_args_msvc); <ins> // Workaround for #95429 base.has_thread_local = false; </ins> Target { llvm_target: "i686-pc-windows-msvc".to_string(),