jiebi/CodeConvo huggingface dataset:
Change:
assert!(def.is_enum()); // Computes the variant of a given index. <del> let layout_of_variant = |index| { </del> <ins> let layout_of_variant = |index, encoding: Option<TagEncoding<VariantIdx>>| { </ins> let tag = cx.tcx.tag_for_variant((cx.tcx.erase_regions(ty), index)); let variant_def = Def::Variant(def.variant(index)); let variant_layout = ty_variant(cx, (ty, layout), index); <del> Self::from_variant(variant_def, tag, (ty, variant_layout), layout.size, cx) </del> <ins> Self::from_variant( variant_def, tag.map(|tag| (tag, index, encoding.unwrap())), (ty, variant_layout), layout.size, cx, ) </ins> }; // We consider three kinds of enums, each demanding a different

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:
<ins> trait TraitA { type TypeA; } trait TraitD { type TypeD; } pub trait TraitB { type TypeB: TraitD; fn f(_: &<Self::TypeB as TraitD>::TypeD); } pub trait TraitC<E> { type TypeC<'a>: TraitB; fn g<'a>(_: &<<Self::TypeC<'a> as TraitB>::TypeB as TraitA>::TypeA); //~^ ERROR the trait bound `<<Self as TraitC<E>>::TypeC<'a> as TraitB>::TypeB: TraitA` is not satisfied } fn main() {} </ins>

Discussion:
: Fails on nightly 1.66.0 but not on stable 1.64.0. <details<summary<strongBacktrace</strong</summary<p</p</detailsEdited: minified the code
Also ICEs on beta
stable error -beta ICE I tried moving things around so lifetime is on , but that's fine. This also requires the lifetime .
Going to preemptively assign P-medium, since this code isn't correct anyways. I think this has something to do with our error recovery here, since this valid code is fine, which only changes the trait:
I got a fix here.
Change:
#[stable(feature = "unwind_safe_atomic_refs", since = "1.14.0")] impl<T> RefUnwindSafe for atomic::AtomicPtr<T> {} <ins> // https://github.com/rust-lang/rust/issues/62301 #[stable(feature = "hashbrown", since = "1.36.0")] impl<K, V, S> UnwindSafe for collections::HashMap<K, V, S> where K: UnwindSafe, V: UnwindSafe, S: UnwindSafe {} </ins> #[stable(feature = "catch_unwind", since = "1.9.0")] impl<T> Deref for AssertUnwindSafe<T> { type Target = T;

Discussion:
Successfully compiles on stable 1.35, fails on beta/pre 1.36.
First reported to FireFox ESR and shared on irlo here:
The impl for requires , but the one for requires .
is a possible fix.
Change:
_ => bug!("closure_sig_as_fn_ptr_ty is not a fn-ptr: {:?}", ty.kind()), } } <ins> pub fn print_as_impl_trait(self) -> ty::print::PrintClosureAsImpl<'tcx> { ty::print::PrintClosureAsImpl { closure: self } } </ins> } /// Similar to `ClosureSubsts`; see the above documentation for more.

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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should suggest how to specify the return type when a function returns a closure. <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Is some thing like this not ok ?
release-assignment
It's ok but I was wondering if it's possible to make the compiler give some form of a suggestion to the user on how to do this. Cause the current diagnostics does not suggest how to fix it.
Change:
}; let encl_item_id = self.tcx.hir().get_parent_item(expr.hir_id); <del> let encl_item = self.tcx.hir().expect_item(encl_item_id); if let hir::ItemKind::Fn(..) = encl_item.kind { </del> <ins> if let Some(hir::Node::Item(hir::Item { kind: hir::ItemKind::Fn(..), span: encl_fn_span, .. })) | Some(hir::Node::TraitItem(hir::TraitItem { kind: hir::TraitItemKind::Fn(_, hir::TraitFn::Provided(_)), span: encl_fn_span, .. })) | Some(hir::Node::ImplItem(hir::ImplItem { kind: hir::ImplItemKind::Fn(..), span: encl_fn_span, .. })) = self.tcx.hir().find(encl_item_id) { </ins> // We are inside a function body, so reporting "return statement // outside of function body" needs an explanation.

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
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
This is a regression considering it doesn't happen in beta.
Change:
<ins> // force-host // no-prefer-dynamic #![crate_type = "proc-macro"] extern crate proc_macro; use proc_macro::TokenStream; #[proc_macro] pub fn dummy(input: TokenStream) -> TokenStream { // Iterate to force internal conversion of nonterminals // to `proc_macro` structs for _ in input {} TokenStream::new() } </ins>

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --We have a library that compiles fine on 1.47.0 but after uggrading to 1.48.0 the compilation hangs. This code-snippet above is reduced from the original code as much as I can. I'm having problems understanding exactly where the problem is coming from and any further modifications to reduce it haven't worked. It uses the "paste" crate, and I've tried a few different versions including the latest one but it doesn't make a difference . I've been building it with at 1.47.0 and 1.48.0 to reproduce the issue which I got just by running doesn't work on works on </p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --
Some quick notes as I find them: This reproduces on just a cargo check, so has nothing to do with codegen (unsurprising) Compilation time scales by a little more than 2x for each additional number (going from 0 to 20 took 11 seconds, 21 took 26, 22 took 1 min 5) Given that I don't think this is a hard hang per se, just a really really long running compilation Definitely something in macro expansion, compiling the post- code is instant Reproduces on current nightly. -Zself-profile shows all the time is spent in . Unfortunately I don't have a debug build of rustc handy, but I imagine slapping a profiler on one should make the issue fairly obvious. I'd recommend cutting the provided example down from 64 to 20 though.

searched nightlies: from nightly-2020-08-24 to nightly-2020-10-03 regressed nightly: nightly-2020-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: </detailsLooks like
If it helps, this crate was exploring some ideas related to the crate
Assigning and removing as in the prioritization working group.
This is caused by some of the extra logic I in to ensure that we don't throw out the captured unnecessarily. I'm looking into improving the performance. In the longer term, this will be solved by getting rid of the pretty-print/retokenize hack entirely.
Change:
pub mod time; cfg_if::cfg_if! { if #[cfg(not(target_vendor = "uwp"))] { <del> pub mod stdio; </del> pub mod stack_overflow; } else { <del> pub mod stdio_uwp; </del> pub mod stack_overflow_uwp; <del> pub use self::stdio_uwp as stdio; </del> pub use self::stack_overflow_uwp as stack_overflow; } }

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --Building std library (-Zbuild-std) with nightly for uwp-windows-msvc targets has been failing with compile errors since around after 17/10/22 I expected to see this happen: Last successeful build on 16/10: Instead, this happened: Lastest failed build: It most recently worked on: rustc 1.66.0-nightly ( 2022-10-14) : <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --
Hey, is anyone looking into this because ALXR ci (uwp) builds are failing for over a week. Should this issue be posted in another repo?
This is the right repo, but it fell through the cracks for whatever reason. I can get to it this weekend.
Thank you :)
Oh, sorry I missed this! Since 10.0. console functions are available on UWP (see ). So I think the thing to do here is to simply stop making the function conditionally imported.
Change:
} } <ins> #[stable(feature = "string_box_error", since = "1.7.0")] impl<'a> From<&'a str> for Box<Error> { fn from(err: &'a str) -> Box<Error> { From::from(String::from(err)) } } </ins> #[stable(feature = "rust1", since = "1.0.0")] impl Error for str::ParseBoolError { fn description(&self) -> &str { "failed to parse bool" }

Discussion:
There's an implementation of that allows the conversion of a to a , but it doesn't quite work when just using . The (perhaps subtle) error message is due to the compiler attempting to use the general implementation for . I was trying to return string errors from a function returning and ended up writing the following: This works well, but is really just boilerplate and not obviously suited to inclusion in any crate or library. Other solutions I thought of include: Adding to the standard library for cases like this. Altering the semantics for trait-resolution on types that parametrise over multiple traits. From what I've read, we don't yet have semantics for general additions of traits, only built-in ones. See .
This is somewhat intentional on the side of being conservative, but it seems pretty harmless to add.
Change:
<ins> fn main() { [(); &(&'static: loop { |x| {}; }) as *const _ as usize] //~^ ERROR: invalid label name `'static` //~| ERROR: type annotations needed } </ins>

Discussion:
Probably somewhat related to This ICE's on stable, beta and nightly: Playground: Backtrace:
The ICE doesn't appear on the latest nightly (), marked as E-needstest

Running the following code triggers an internal compiler error and the error message says that it's a bug and I should report it, so I'm doing that now:
mcve:
Note, that this does not ICE anymore on nightly, instead it gives me: Can this be closed

I'm experimenting with a parser combinator and ran into an issue with closure lifetime inference. This might be a duplicate of , since it uses a similar (but simpler) mechanism to produce the same error message. However, in the code below the error is potentially a lot further away, and since I need to return values from the closure I'm having trouble finding any way to make it work by explicitly specifying a signature. Since it involves more moving parts, I'm also not sure how to confirm if the underlying issue is the same. I removed all parts that aren't involved in triggering the error message (the original use case has trait methods with related return types). It comes down to the following error message: And here is the triggering code:
After some experimentation, I tried a possible fix, which lead to an ICE. I changed to which gives me: My is: And here is the :
The ICE reduced:
Triage: still ICEs
Still ICEs:
The reduced example doesn't show the ICE, from 1.35.0 (tested on godbolt). Marked as E-needstest
And the original code is now accepted, so adding tests is enough to close this ticket.
Change:
LL |     test_macro!(String,); |     -------------------- in this macro invocation | <ins> = help: enum variants can be `Variant`, `Variant = <integer>`, `Variant(Type, ..., TypeN)` or `Variant { fields: Types }` </ins> = note: this error originates in the macro `test_macro` (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to previous error

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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Although I know Enums take to form of: I sometimes find myself accidentally defining them as I would a Struct (): The current output is: This always takes more than a few seconds to parse and then realize my mistake. Is it possible to change this to something like: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Do you have any suggestion for how the compiler should distinguish between "trying to write an enum with struct syntax" and "trying to write a struct but used the enum keyword"?
Linking to the topic on internals where some other folks have left suggestions (). Although none of those directly address your question. My gut reaction is to assume that if the "enum" keyword is used that truly was the intention of the developer, but if it wasn't, hopefully some help message like the : Would provide enough information to trigger an "Oh wait did I really want to use an enum here?"
claim
Change:
} } } <ins> enum_did </ins> } _ => return Err(TypeIsStructural), <ins> }; if ty::has_dtor(tcx, did) { return Err(TypeHasDestructor) </ins> } Ok(())

Discussion:
Basically, it's now possible to write: and have everything work. This unfortunately means that doing something like with a will zero b, but not move it. /cc
I noticed this possibility too and was debating if this is a problem. It's not clear to me. Probably best to disallow it for now.
at the very least, it's causing incorrect behaviour at runtime, since it's zeroing out types like a move, but not forbidding the use of them like a copy.
Looks unsafe to me: Program received signal SIGSEGV, Segmentation fault. 0x0000555555598e5c in ()
I agree that combining it with zeroing is unsafe. If zeroing did not occur, or we did not zero for types that were copy, there wouldn't necessarily be a problem.
Anyhow, it's easiest to forbid it for now. We can always make it legal later if someone comes up with a persuasive use case. Idempotent destructors seem like a bit of an odd thing.
Change:
<ins> #![feature(type_alias_impl_trait)] #![deny(improper_ctypes)] pub trait TraitA { type Assoc; } impl TraitA for u32 { type Assoc = u32; } pub trait TraitB { type Assoc; } impl<T> TraitB for T where T: TraitA { type Assoc = <T as TraitA>::Assoc; } type AliasA = impl TraitA<Assoc = u32>; type AliasB = impl TraitB<Assoc = AliasA>; fn use_of_a() -> AliasA { 3 } fn use_of_b() -> AliasB { 3 } extern "C" { pub fn lint_me() -> <AliasB as TraitB>::Assoc; //~ ERROR: uses type `impl TraitA` } fn main() {} </ins>

Discussion:
cc Gives the following incorrect warning:
I'm not sure if this is incorrect - I think this is what I'd expect. In the declaration of , we don't know what concrete type is - if it were , then we could normalize to - but we don't know? Maybe I'm missing something.
Hmm, that might be true. I definitely think that the following should not lint here (with bound to u32)
I agree that seems like it should be fine. So, this happens because of this call: It makes sense that we want to lint on opaque types on extern declarations, it's unclear whether we would want to allow projections which contain opaque types - this would solve the case you've shown here, but could be used to "sneak" opaque types by the lint (in , the projection normalizes to an opaque type; it's hard to detect because the normalization goes further and resolves it to so we can't tell that it was an opaque type) - I have a build with this locally. Any thoughts on whether we should change the behavior here? cc
Hm, I think it might be worth it to normalize using here, which should not normalize the first case and your example while fixing the second one if I am not mistaken.
Long ago I filed where we also concluded Reveal::UserFacing is the right behavior for normalization in this lint. The current behavior comes from cc
I'll put up a PR with my experiments from last night later in that case.
Change:
<ins> // ICE Where clause `Binder(..)` was applicable to `Obligation(..)` but now is not // issue: rust-lang/rust#84727 struct Cell<Fg, Bg = Fg> { foreground: Color<Fg>, //~^ ERROR cannot find type `Color` in this scope background: Color<Bg>, //~^ ERROR cannot find type `Color` in this scope } trait Over<Bottom, Output> { fn over(self) -> Output; } impl<TopFg, TopBg, BottomFg, BottomBg, NewFg, NewBg> Over<Cell<BottomFg, BottomBg>, Cell<NewFg, NewBg>> for Cell<TopFg, TopBg> where Self: Over<Color<BottomBg>, Cell<NewFg>>, //~^ ERROR cannot find type `Color` in this scope { fn over(self) -> Cell<NewFg> { //~^ ERROR mismatched types self.over(); } } impl<'b, TopFg, TopBg, BottomFg, BottomBg> Over<&Cell<BottomFg, BottomBg>, ()> for Cell<TopFg, TopBg> where Cell<TopFg, TopBg>: Over<Cell<BottomFg>, Cell<BottomFg>>, { fn over(self) -> Cell<NewBg> { //~^ ERROR cannot find type `NewBg` in this scope self.over(); } } pub fn main() {} </ins>

Discussion:
: Same in 1.52.0-nightly, same in 1.51.0. : <details<summary<strongBacktrace</strong</summary<p</p</detailsGood luck! <3
This happens on top of too much code for me to take the time to minimalize this issue, sorry. Though I'll try to file the fixing patch.
Wait! I made it! This issue revolves around L.31. Comment to see the ice go away. Interestingly, comment L.40 (or the whole impl L.37-45) to see ice go away as well. Commenting L.47-56 does not make ice go away. Commenting L.13-22 should raise another error (as L.31 is supposed to go there), but doesn't. Actually, the real fix is to replace L.31 with: Have fun!
Minimized with , then a bit by hand: <details<summaryDetails</summary<pIcemelter version: v0.2.0 label +S-bug-has-mcve </p</details
fixed by . we previously used to eagerly error but did not consider them as part of the cache key. So using a cache key from an evaluation with different can result in buggy behavior
Change:
assert!(rows.iter().all(|r| r.len() == v.len())); let pcx = PatternContext { <ins> // TyErr is used to represent the type of wildcard patterns matching // against inaccessible (private) fields of structs, so that we won't // be able to observe whether the types of the struct's fields are // inhabited. // // If the field is truely inaccessible, then all the patterns // matching against it must be wildcard patterns, so its type // does not matter. // // However, if we are matching against non-wildcard patterns, we // need to know the real type of the field so we can specialize // against it. This primarily occurs through constants - they // can include contents for fields that are inaccessible at the // location of the match. In that case, the field's type is // inhabited - by the constant - so we can just use it. // // FIXME: this might lead to "unstable" behavior with macro hygiene // introducing uninhabited patterns for inaccessible fields. We // need to figure out how to model that. </ins> ty: rows.iter().map(|r| r[0].ty).find(|ty| !ty.references_error()) .unwrap_or(v[0].ty), max_slice_length: max_slice_length(cx, rows.iter().map(|r| r[0]).chain(Some(v[0])))

Discussion:
the compiler unexpectedly panicked. this is a bug. I tried this code (hyper = "0.11.9"): I expected to see this happen: code compiles (two top branches are incompatible) Instead, this happened: compiler crashed; re-ordering two top branches fixes the issue : Backtrace:
Slightly simplified version (it's not valid Rust code -- not all patterns are covered -- but it crashes the compiler): Backtrace with debug logging from rustc (RUSTBACKTRACE=full RUSTLOG=rustcconsteval):
Minified:
Change:
<ins> // Copyright 2014 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. struct Foo; fn main() { let mut a = Foo; let ref b = Foo; a += *b; //~ Error: binary assignment operation += cannot be applied to type `Foo` } </ins>

Discussion:
OS: Ubuntu 12.04 x86 rustc -v rustc 0.9-pre ( 2013-12-24 01:56:30 -0800) host: i686-unknown-linux-gnu Full error message: 30:14 error: binary operation + cannot be applied to type v += move; ^~~~~ error: internal compiler error: no type for node 81: expr move (id=81) in fcx 0xb3970ef8 This message reflects a bug in the Rust compiler. We would appreciate a bug report: task 'rustc' failed at 'explicit failure', task '<main' failed at 'explicit failure', Source: