jiebi/CodeConvo huggingface dataset:
Change:
<ins> error[E0277]: the trait bound `[(); 0]: Foo` is not satisfied --> $DIR/unevaluated_fixed_size_array_len.rs:22:5 | LL |     <[(); 0] as Foo>::foo() //~ ERROR E0277 |     ^^^^^^^^^^^^^^^^^^^^^ the trait `Foo` is not implemented for `[(); 0]` | = help: the following implementations were found: <[(); 1] as Foo> note: required by `Foo::foo` --> $DIR/unevaluated_fixed_size_array_len.rs:14:5 | LL |     fn foo(); |     ^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
After , when a trait bound fails and the trait was implemented by fixed-size arrays, the compiler will display an error like: Which is pretty unhelpful. A solution would be to evaluate these and/or to show evaluated bounds preferably.
I can't reproduce triggering an error with these messages, do you have an example? I need it for a regression test, the fix was indeed as simple
It only appears if you explicitly disambiguate the trait, like . .
are you displaying these as ? I feel that'd be a reasonable output for this.
that would be a better fallback than , but I'm currently trying to get at the actual value (though that triggers cycle errors atm when building libcore's array impls ^^)
That's better in some ways, but kinda implies that
Change:
} fn main() { <del> let _ = NontrivialDrop; //~WARNING non-binding let on a type that implements `Drop` </del> <ins> let _ = NontrivialDrop; //~WARNING non-binding let on a type that has a destructor </ins> let (_, _) = (NontrivialDrop, NontrivialDrop); // This should be ignored. }

Discussion:
I tried this code: I got this warning: However, there is no impl on the type, so the error message is misleading. It is true however that there is a destructor, as defined here: That being said, it's insiginificant for all underlying types (only destructor of and type in the ), so ideally the warning still wouldn't even show. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Well, even if the parameter of is , it still has a side-effect (deallocates memory). I don't think we need this special-casing. I do think the diagnostic is a bit misleading and should just say "has a destructor" or "has side-effects when dropped". Is there a more practical code example for why you'd want to suppress this error? The example you gave is a bit artificial, so it's a hard to motivate why we'd want to suppress this code since it really could be rewritten to be clearer.
claim
Change:
match ty.kind() { ty::Adt(adt_def, _) => Some(*adt_def), // FIXME(#104767): Should we handle bound regions here? <del> ty::Alias(ty::Projection | ty::Inherent, _) if !ty.has_escaping_bound_vars() => { </del> <ins> ty::Alias(ty::Projection | ty::Inherent | ty::Weak, _) if !ty.has_escaping_bound_vars() => { </ins> self.normalize(span, ty).ty_adt_def() } _ => None,

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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
can you please avoid using in the future and directly put the attributes in the source? It makes it easier to copy it to the playground or local invocation.
I've got a fix already, gonna open a PR later. claim
Minimized:
Change:
<del> Subproject commit 3c444bf6a6cff3b9014005f21cc44995b34862ce </del> <ins> Subproject commit 974c8be95ec17cd986251d7700cd432a39576939 </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
triage: P-medium, removing nomination.
Change:
<ins> #![crate_type = "lib"] pub fn foo(callback: fn() -> dyn ToString) { let mut x: Option<Box<dyn Fn() -> dyn ToString>> = None; x = Some(Box::new(callback)); //~^ ERROR: the size for values of type `dyn ToString` cannot be known at compilation time } </ins>

Discussion:
Hello, I am trying to implement this trait: I get a compiler panic error: internal compiler error: unexpected panic I try to compile it for target=wasm32-unknown-unknown note: rustc 1.32.0 ( 2019-01-16) running on x86_64-pc-windows-msvc note: compiler flags: -C debuginfo=2 -C incremental --crate-type lib
Can you provide a self-contained example that reproduces the ICE?
Hello, This is the shortest example I could create: If you just build this you should get the error. It looks like it works? when not in lib mode, not sure
Even shorter:
<strikeBug was introduced between 1.23 and 1.24 (...)</strikeBetween 2017-11-20 and 2017-11-21 (...)
cc based on your commits that day ^^
That example should not type-check, you're assigning a where a is expected. cc
Using , we have , before then it was rejected due to syntax being unstable: 1.271.281.301.32
You can just remove the keyword, it really shouldn't matter. Btw, the minimized repro can be minimized further by removing the (rather heavy) : And we can also get rid of : is , none of this can work. So the real question is how does this ICE before emitting a type-checking error?
Okay, so there are two parts to this: the associated type of doesn't require implements the trait, so can be unsized to So this has a reason to type-check, despite being very confusing. We can make this simpler by using pointers: This way, we have , so can be unsized to . But it's impossible for the return type of a function, even with unsized rvalues, to be (i.e. we have no mechanism for supporting that), and here I think at the very least the vtable of has to have a shim that would need to return a return type (, i.e. in the original repro), so we ICE. If we don't want to enforce that return types are in pointers or trait objects methods, this case will continue ICE-ing.
The original problem is clearer if we add the keyword: You can fix your code by putting a around the return type of this , or figure out some other way to do it.

If you want to make sure you find such problems, try to write function that is has implements the right traits, e.g. . That will error because the return type of a function with a body must be .
What alternative do we have?
Thank you , I will look into an alternative
Reproduces () as of 2020-03-10.
modify labels: +regression-from-stable-to-stable Still reproduces with stable/beta/nightly `
Assigning .
The latest nightly fixes the ICE, marking as .
Change:
<del> Subproject commit fef3d7b14ede45d051dc688aae0bb8c8b02a0566 </del> <ins> Subproject commit 7738295178045041669876bf32b0543ec8319a5c </ins>

Discussion:
I tried this code: Nightly fails running on MIPS emulator assertion failed left: right: Stable succeeds Looks like the top and bottom dwords are mixed up target is mips-unknown-linux-musl emulator is qemu-mips-static
This is probably related to
WG-prioritization assigning priority (). label -I-prioritize +P-medium
This can be provoked on mips64 as well:
Is this what's causing these build failures when upgrading from 1.72.0 to 1.73.0? Just checking before I open a new bug. I get a bunch of these on slightly different floating-point values on mips64.
Floats are hell, and also this landed with 1.73: A new issue is a good idea.
Yeah I've also been getting lots of different floating point related issues on 1.73 on MIPS. I too would've thought they are related to the shifts, but the new apfloat code could also be the reason.
I applied the patch from and confirmed that it fixes the 1.73.0 bootstrap problem for me. I also tried the snippet from 's comment above and it did not assert after applying that patch.
It happened with , too. We stripped down the PoC to a few lines of LLVM IR code, and we reported to the . Turned out that it is exactly the same problem here.
Change:
Err(match_pair) } <del> PatternKind::Range { .. } | PatternKind::Slice { .. } => { </del> <ins> PatternKind::Range { .. } => { </ins> Err(match_pair) } <ins> PatternKind::Slice { ref prefix, ref slice, ref suffix } => { if prefix.is_empty() && slice.is_some() && suffix.is_empty() { // irrefutable self.prefix_slice_suffix(&mut candidate.match_pairs, &match_pair.place, prefix, slice.as_ref(), suffix); Ok(()) } else { Err(match_pair) } } </ins> PatternKind::Variant { adt_def, substs, variant_index, ref subpatterns } => { let irrefutable = adt_def.variants.iter().enumerate().all(|(i, v)| { i == variant_index || {

Discussion:
Irrefutable slice patterns with a may cause the compiler to ICE. I expected to see this happen: the code compiled (however silly this example is) Instead, this happened: : rustc 1.24.0-nightly ( 2017-12-30) binary: rustc commit-hash: commit-date: 2017-12-30 host: x86_64-unknown-linux-gnu release: 1.24.0-nightly LLVM version: 4.0 Backtrace:
It also occurs with:
Change:
} } doc_comment! { concat!("Saturating integer subtraction. Computes `self - rhs`, saturating at the numeric bounds instead of overflowing.

Discussion:
Godbolt link: So I expect these two functions has the same assembly: But the result is not:
modify labels: -C-bug -I-slow T-compiler
Hey I tried solving this but wasn't really sure how to. I believe the implementation to the LLVM generation is right here. Hope someone can solve this!
Turn out I was wrong! The is working correctly (i.e. those two functions are not equivalent): I would add some doctests to show that and close this issue.
Change:
let mut llvm_c_strs = Vec::with_capacity(n_args + 1); let mut llvm_args = Vec::with_capacity(n_args + 1); <ins> llvm::LLVMRustInstallFatalErrorHandler(); </ins> { let mut add = |arg: &str| { let s = CString::new(arg).unwrap();

Discussion:
Related to . If a fatal error occurs in LLVM, the compiler exits with status 1. This is problematic, because if a test is expecting a compilation failure, the test could still pass. It also makes it difficult to test for the presence of ICEs in general. A simple fix would be to patch our copy of LLVM to exit with 101 (like ICEs) in , but any other ideas would be appreciated.
Those error functions all call , which sounds like it could be a great hook for us, but then that only calls . :/
There is  though, and that handler gets called first.
That sounds nice, but if we exit with 101 (or simply panic) in the handler won't we be skipping any other cleanup (, plus any future cleanup that gets there)? Or could we just call it in our handler? I'm interested in putting a patch together, but I'm unfamiliar with how we link Rust to C++. The error handler needs to be able to consume a .
We shouldn't do anything that looks like exception unwinding. See : I think we can call it -- it's publicly declared in . We might want to keep a note to make sure we check for new cleanup needed when we update LLVM though. We bridge C++ code in . You could just write our handler in C++ there, and add some C-FFI function for to call and hook that up.
Change:
// We consider three kinds of enums, each demanding a different // treatment of their layout computation: <del> // 1. enums that are uninhabited // 2. enums for which all but one variant is uninhabited // 3. enums with multiple inhabited variants </del> <ins> // 1. enums that are uninhabited ZSTs // 2. enums that delegate their layout to a variant // 3. enums with multiple variants </ins> match layout.variants() { <del> _ if layout.abi.is_uninhabited() => { // Uninhabited enums are usually (always?) zero-sized. In // the (unlikely?) event that an uninhabited enum is // non-zero-sized, this assert will trigger an ICE, and this // code should be modified such that a `layout.size` amount // of uninhabited bytes is returned instead. // // Uninhabited enums are currently implemented such that // their layout is described with `Variants::Single`, even // though they don't necessarily have a 'single' variant to // defer to. That said, we don't bother specifically // matching on `Variants::Single` in this arm because the // behavioral principles here remain true even if, for // whatever reason, the compiler describes an uninhabited // enum with `Variants::Multiple`. assert_eq!(layout.size, Size::ZERO); </del> <ins> Variants::Single { .. } if layout.abi.is_uninhabited() && layout.size == Size::ZERO => { // The layout representation of uninhabited, ZST enums is // defined to be like that of the `!` type, as opposed of a // typical enum. Consequently, they cannot be descended into // as if they typical enums. We therefore special-case this // scenario and simply return an uninhabited `Tree`. </ins> Ok(Self::uninhabited()) } Variants::Single { index } => { <del> // `Variants::Single` on non-uninhabited enums denotes that </del> <ins> // `Variants::Single` on enums with variants denotes that </ins> // the enum delegates its layout to the variant at `index`. layout_of_variant(*index) } Variants::Multiple { tag_field, .. } => { // `Variants::Multiple` denotes an enum with multiple <del> // inhabited variants. The layout of such an enum is the // disjunction of the layouts of its tagged variants. </del> <ins> // variants. The layout of such an enum is the disjunction // of the layouts of its tagged variants. </ins> // For enums (but not coroutines), the tag field is // currently always the first field of the layout.

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed'', 'thread 'rustc' panicked at 'assertion failed'' 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 -- label +F-transmutability <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
Ah, it's an uninhabited non-ZST!
claim
I guess that answers my ;)
Change:
#![feature(min_specialization)] #![feature(vec_spare_capacity)] #![feature(core_intrinsics)] <del> #![feature(int_bits_const)] </del> #![feature(maybe_uninit_slice)] #![feature(new_uninit)] #![cfg_attr(test, feature(test))]

Discussion:
Tracking issue for as introduced by Gated behind .
modify labels: +T-libs
Error: Label P can only be set by Rust team members Please let know if you're having trouble with this bot.
This has been in a few releases, is used in many places in rustc itself, and there's no open questions so far. Time to stabilize? merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
We agreed in the libs meeting just now to revert stablization, since the is significant throughout the ecosystem, through . :( We can stabilize it again once that is solved upstream.
Closing this since has been merged.
Change:
<ins> error[E0588]: packed type cannot transitively contain a `#[repr(align)]` type --> $DIR/issue-73112.rs:9:5 | LL | /     struct SomeStruct { LL | | LL | |         page_table: PageTable, LL | |     } | |_____^ | note: `PageTable` has a `#[repr(align)]` attribute --> $DIR/auxiliary/issue-73112.rs:8:1 | LL | / pub struct PageTable { LL | |     entries: [PageTableEntry; 512], LL | | } | |_^ error: aborting due to previous error For more information about this error, try `rustc --explain E0588`. </ins>

Discussion:
I was writing some code that does some x86 page table configuration, but then I noticed that Rust compiler started to panic with this code: And I did realize that I cannot use in since has attribute. If I rewrite the above code without crate: (Note that this is basically same thing as 's struct) This compiler error is displayed, which is normal: And here's output from (In this case, I'm trying to compile the first code): Looking at the backtrace, there's function and : While there's no line number(since the compiler is installed using ), thankfully there are only two calls to inside . And it seems like the first one is panicking since normal output has nothing more than , but I might be wrong. I ran about five minutes ago before submitting this issue, but result was the same. BTW: I initially found this bug in Clippy, but then I noticed that Rustc was doing the same thing.
Assigning [as discussed as part of the Prioritization WG procedure][link]. [link]: https://rust-(in.20some.20cases).20when.20repr(al
Would you please try this again for us?
The second one is one that does not panic rustc(The code that panics rustc is the first one). It is very similar to the first one except that it does not use external crate, and compiling it shows the error I was expecting. Also, the second code was one of my attempts to reproduce the same panic without external crate, but for some reason, it didn't panic the compiler. Only the first code does.
Change:
<ins> //@ check-pass trait Trait { type Associated; } impl Trait for i32 { type Associated = i64; } trait Generic<T> {} type TraitObject = dyn Generic<<i32 as Trait>::Associated>; struct Wrap(TraitObject); fn cast(x: *mut TraitObject) { x as *mut Wrap; } fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'called on an value: NoSolution'', 'thread 'rustc' panicked at 'called on an value: NoSolution'' 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: [mirborrowck] borrow-checking [analysis] running analysis passes on this crate -- label +F-ptrmetadata
bisects to :thinking: cc
Minimized: This compiles on stable. ICEs on beta. <details<summaryError output on beta</summary</details label +regression-from-stable-to-beta Of note, the opposite pointer cast fails to compile on stable, beta, and nightly. This seems wrong to me. <details<summaryThe opposite cast</summaryError: </details
Just for context (unsure if relevant here) I see in that PR a question for T-lang about a breaking change at this and in the following FCP that was
So while the breaking change was approved, I believe this code should compile (and definitely not ICE). The issue seems to be that borrowck can't prove a bound (after typeck did). Seeing for you need a projection to trigger the issue () I think there is normalization missing somewhere.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Change:
let val = match normalized_op { Ok(mplace) => return mplace_to_const(ecx, mplace), Err(Immediate::Scalar(x)) => <del> ConstValue::Scalar(x.not_undef()?), </del> <ins> ConstValue::Scalar(x.not_undef().unwrap()), </ins> Err(Immediate::ScalarPair(a, b)) => <del> ConstValue::Slice(a.not_undef()?, b.to_usize(ecx)?), </del> <ins> ConstValue::Slice(a.not_undef().unwrap(), b.to_usize(ecx).unwrap()), </ins> }; <del> Ok(ty::Const { val, ty: op.layout.ty }) </del> <ins> ty::Const { val, ty: op.layout.ty } </ins> } fn eval_body_and_ecx<'a, 'mir, 'tcx>(

Discussion:
It looks like this was broken in the release of 1.32.0 (and is still broken, even on nightly) (checked on ). The following example program: Fails to compile: Interestingly, making the fixes it. My Rust version: I know , but I don't think this qualifies as a field access. And yes, I'm aware of . cc
Interesting. Looks like a validation issue? Cc
Change:
impl ops::BitOrAssign for Cfg { fn bitor_assign(&mut self, other: Cfg) { match (self, other) { <del> (&mut Cfg::True, _) | (_, Cfg::False) => {} (s, Cfg::True) => *s = Cfg::True, </del> <ins> (Cfg::True, _) | (_, Cfg::False) | (_, Cfg::True) => {} </ins> (s @ &mut Cfg::False, b) => *s = b, (&mut Cfg::Any(ref mut a), Cfg::Any(ref mut b)) => { for c in b.drain(..) {

Discussion:
Context: CC
Thanks for opening this issue! Someone from the rustdoc team will try to get back to it whenever possible.
It doesn't look too difficult. I'm going to try to make a PR for it myself, and I'll update here with or without progress.
Even better! :smile: I'll assign you to the issue in the meantime then.
Change:
<ins> trait MyIterator : Iterator {} fn main() { let _ = MyIterator::next; } //~^^ ERROR the value of the associated type `Item` in `Iterator` must be specified [E0191] //~| WARN trait objects without an explicit `dyn` are deprecated [bare_trait_objects] //~| WARN this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2021! </ins>

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

Consider the following code which is ill-formed even after specifying the assoc ty. () would only be well-formed if we defined an inherent associated type () on which doesn't work yet anyway () and is pretty niche) or once we support arbitrary shorthand projections ().