jiebi/CodeConvo huggingface dataset:
Change:
let z: &dyn SomeTraitWithGenerics<u64, i8> = x; (y.method1(), z.method1(), x as &dyn Send) } <ins> // Constructing the debuginfo name for the FnOnce vtable below initially caused an ICE on MSVC // because the trait type contains a late bound region that needed to be erased before the type // layout for the niche enum `Option<&dyn Fn()>` could be computed. pub fn bar() -> Box<dyn FnOnce(Option<&dyn Fn()>)> { Box::new(|_x: Option<&dyn Fn()>| {}) } </ins>

Discussion:
Building on Windows ( toolchain) causes an ICE: <details<summarybacktrace</summary</detailsBisecting reveals this was injected by (cc <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-pc-windows-msvc Reproduce with: </details
I'll look into it.
Since landed in 1.57, labeling as stable-to-beta regression.
Re-opening to track the beta backport.
fix backported to beta in PR rollup
Change:
}; use crate::utils::{is_type_diagnostic_item, qpath_res, same_tys, sext, sugg}; use if_chain::if_chain; <del> use itertools::Itertools; </del> use rustc_ast::ast; use rustc_data_structures::fx::{FxHashMap, FxHashSet}; use rustc_errors::Applicability;

Discussion:
I ran into an issue in where was getting expanded into instead of , which resulted in a compile error. We should add some tests that make sure we can still compile code after macros have been expanded.
To clarify: if I understand you correctly, you're saying that the expansion of error!("...") was being rendered by pprust as log(1,"..."), not that the expansion was actually incorrect. Is that correct? First off, that would obviously be a bug in the pretty-printer, which should be fixed. The larger issue of making sure that pretty-printed code compiles I would nominate for well-covered.
Yep, that was the problem, it's fixed now though. The larger issue still stands.
just a bug, removing milestone/nomination.
Fixed by !
Yay!

When using and together, the compiler complains that is an unused import even when a call to something like exists. Removing gets rid of the warning and the crate compiles. However, the crate will fail to link (for example with ) unless the is there. It seems like the warning is a bug unless the intent is to have also bring in foo itself. Here's a small crate that shows the example. This was originally found in rust-core-foundation.
Looking at the code, that's a genuinely unused import when not compiling with . I ran into this when removing unused imports in the compiler, and you can prefix the import with so that the import is only resolved when testing. Other options I've seen are to have a which is 'd off, or just put the in the function itself.
You're right. In this case I moved the inside the test function.

The macro is required, as is that exact order of the bounds, and the use of the repeated bound in the . (It's not specific to though.) output:
Works now, I'll check in a test case
Test case checked in in . Closing

The following code... ...results in the following error: Both and are loans of , so it should be safe to update to new loan of as updating doesn't cause to be freed.
This works now; I'll check in the test case.
Test case checked in in . Closing

So, after much wrangling with MinGW to get Rust to compile on my Windows partition, I'm trying to get Rust-SDL to work. When compiling it, and then running the demo application, I get the following, somewhat esoteric message: The procedure entry point ZN4bool14extensions9meth80572eq154e94be02e19a92306E could not be located in the dynamic link library core-- Is this a configuration issue? A bug? Me being silly?
I'm suspecting this is a dup of
Well, that puts my mind to rest! Thanks

<prefn main() { #error("%?", x);*/ } </preyields
Change:
<ins> warning: ignoring --out-dir flag due to -o flag error: io error modifying /dev/ error: aborting due to previous error </ins>

Discussion:
Ok, so rustc outputting to /dev/null is a bit pathelogical but it used to not ICE the compiler. If you checkout and from dir tests/suite/futurescore run: rustc --crate-type lib -o /dev/null Then rustc is vexed: (ICEs on stable and nightly) The irony is that this is in the test suite of a rust code minimisation project.... Let me minimise the reproduction of the problem...
Thanks to rust-reduce I managed to get the repro down to: Interestingly it doesn't ICE on playground - I'm guessing playground is on linux?
Indeed
triage: P-medium, removing nomination tag, assigning self.
hmm. I nonetheless see an ICE on my own Linux machine. (There is probably some other reason the ICE does not replicate on the playpen.)
Change:
} }; <ins> if ty_to_mut == Mutability::Mut && ty_mut == Mutability::Not { span_mirbug!( self, rvalue, "ArrayToPointer cast from const {:?} to mut {:?}", ty, ty_to ); return; } </ins> if let Err(terr) = self.sub_types( ty_elem, ty_to,

Discussion:
cc is this a coercion that's expected to work?
triage: I-nominated
The first cast is from to , the second is from to . I'm not actually sure if this is meant to work, I guess it should. The intention here is to give a way to treat arrays like C-arrays and get a pointer to the start of the array. It seems that if the array is mutable, then the pointer should be too. I recommend this is P-low - it is backwards compatible, rare, and just a bug by omission, really. The fix should be pretty easy though.
Ah I wasn't sure if this was intended, if it's actually intended then I don't mind removing the nomination as well!
I'm not sure how intended this is, but it doesn't seem too harmful. ;)
P-low, (perhaps "just a bug", perhaps a minor feature.)
Triage: no change
This still happens today (with ), but the error message is slightly different: is another -related issue.
Change:
<ins> error: suffixes on string literals are invalid --> $DIR/lit-err-in-macro.rs:7:4 | LL | f!("Foo"__); |    ^^^^^^^ invalid suffix `__` error: aborting due to previous error </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Regression in nightly-2022-11-18
label regression-from-stable-to-stable
WG-prioritization assigning priority (). label -I-prioritize +P-low
Change:
} } GeneratorInteriorOrUpvar::Upvar(upvar_span) => { <ins> // `Some(ref_ty)` if `target_ty` is `&T` and `T` fails to impl `Sync` let refers_to_non_sync = match target_ty.kind() { ty::Ref(_, ref_ty, _) => match self.evaluate_obligation(&obligation) { Ok(eval) if !eval.may_apply() => Some(ref_ty), _ => None, }, _ => None, }; let (span_label, span_note) = match refers_to_non_sync { // if `target_ty` is `&T` and `T` fails to impl `Sync`, // include suggestions to make `T: Sync` so that `&T: Send` Some(ref_ty) => ( format!( "has type `{}` which {}, because `{}` is not `Sync`", target_ty, trait_explanation, ref_ty ), format!( "captured value {} because `&` references cannot be sent unless their referent is `Sync`", trait_explanation ), ), None => ( format!("has type `{}` which {}", target_ty, trait_explanation), format!("captured value {}", trait_explanation), ), }; </ins> let mut span = MultiSpan::from_span(upvar_span); <del> span.push_span_label( upvar_span, format!("has type `{}` which {}", target_ty, trait_explanation), ); err.span_note(span, &format!("captured value {}", trait_explanation)); </del> <ins> span.push_span_label(upvar_span, span_label); err.span_note(span, &span_note); </ins> } }

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 compiler helpfully points out that is required, but nonetheless and I both got confused by this error for some time before we noticed it. The suggestion was kind of buried by all the other details.
I'm not sure the ideal output, but it might be something like this:
This error can be replicated without any external crates (i.e., without ) like so:
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. // Regression test for #3512 - conflicting trait impls in different crates should give a // 'conflicting implementations' error message. // aux-build:trait_impl_conflict.rs extern mod trait_impl_conflict; use trait_impl_conflict::Foo; impl<A> Foo for A { //~^ ERROR conflicting implementations for trait `trait_impl_conflict::Foo` //~^^ ERROR cannot provide an extension implementation where both trait and type are not defined in this crate } fn main() { } </ins>

Discussion:
Some days ago, I wrote some code involving char as HashMap key. At that time, char didn't implement the IterBytes trait, so I implemented it locally myself. After updating rust, my code failed to compile with a somewhat less than obvious error. Example: Produces the following errors: Note that there is no way to know that the problem is the duplicate implementation of IterBytes.
Reproduced as of
Bumping to 0.7, though.
Not critical for 0.7. Nominating for milestone 5, production-ready.
accepted for production-ready milestone
Still reproduces: It has a bunch of other non-bug errors too, but it still exhibits this bug.
Accepted for P-high.
Change:
| LL |         Foo::Bar => {} |         ^^^^^--- <del> |              | |              help: a unit variant with a similar name exists: `Baz` </del> <ins> |         |    | |         |    help: a unit variant with a similar name exists: `Baz` |         did you mean `Foo::Bar ( /* fields */ )`? </ins> error[E0532]: expected tuple struct/variant, found unit struct `S` --> $DIR/issue-32004.rs:16:9

Discussion:
Code Example (): <img width="805" alt="image" src="https://user-"Currently we provide a "do you mean..." for the but not for the . We probably should provide one for both.
Consider fixing Btw (which is a similar enhancement)
I'd like to work on this if it is still available.
go ahead! Ideally, you could turn the output into but just changing the tuple case would be enough.
I created a PR, could you please help review. I took a look at your suggestion of updating all the errors to , that seemed too many changes, not sure if it was necessary, so I just the tuple case.
Change:
= note: consult the function's documentation for information on how to avoid undefined behavior error: unnecessary `unsafe` block <del> --> $DIR/unsafe-env.rs:26:5 </del> <ins> --> $DIR/unsafe-env.rs:36:5 </ins> | LL |     unsafe { |     ^^^^^^ unnecessary `unsafe` block | note: the lint level is defined here <del> --> $DIR/unsafe-env.rs:11:8 </del> <ins> --> $DIR/unsafe-env.rs:21:8 </ins> | LL | #[deny(unused_unsafe)] |        ^^^^^^^^^^^^^ <del> error: aborting due to 4 previous errors </del> <ins> error: aborting due to 7 previous errors </ins> For more information about this error, try `rustc --explain E0133`.

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. --I tried this code: I expected to see this happen: will become in Rust 2024, the above code is using Rust 2021, so this should compile with no issue. Instead, this happened: <!-- 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<summaryBacktrace</summary<pNot needed </p</detailsI think the root cause is the lint , commenting it out would make the code compile: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Thanks for the report! That should not happen. We did a so I don't know how this is even possible... any ideas? This seems to be some bad interaction with .
claim Hmmm, weird that crater run didn't catch this.
I posted a PR fixing this: . Does crater maybe restrict lints?
I don't think it does. Is this code part of the "nix" crate?
If you are asking if this problem originates from the nix crate, then yes, see
I am wondering whether the nix crate as published on fails to build with latest nightly due to this issue.
I think yes, the has been in Nix for a long time. One should be able to reproduce the build failure on a UNIX platform other than: I am currently on Linux, will try reproducing it on my mac tomorrow.
Looks like crater tested nix 0.26.4 and that failed already before the removevar/setvar change (). That's due to the which makes the build fail even when there are just warnings. I guess we can add this to the list of why having deny(warnings) in the code is considered bad practice.
I created an issue and a PR against nix-rust.
Yeah, we can reproduce this on macOS
The reason this was missed is a combination of and
WG-prioritization assigning priority (). label -I-prioritize +P-high
Fix already exists, just needs a review: .
Change:
<ins> // check-pass // // Regression test for issue #78632 #![crate_type = "lib"] pub trait Corge<T> { type Fred; } impl Corge<u8> for () { type Fred = u32; } pub trait Waldo { type Quax; } impl Waldo for u32 { type Quax = u8; } pub trait Grault where (): Corge<Self::Thud>, { type Thud; fn bar(_: <() as Corge<Self::Thud>>::Fred) {} } impl<T> Grault for T where T: Waldo, (): Corge<T::Quax>, <() as Corge<T::Quax>>::Fred: Waldo, { type Thud = u8; } pub trait Plugh<I> { fn baz(); } #[derive(Copy, Clone, Debug)] pub struct Qiz<T> { foo: T, } impl<T> Plugh<<() as Corge<T::Thud>>::Fred> for Qiz<T> where T: Grault, (): Corge<T::Thud>, { fn baz() {} } pub fn test() { <Qiz<u32> as Plugh<u32>>::baz(); } </ins>

Discussion:
To ICE, both tests must be present. Also, if the code compiles successfully, the cache is poisoned. Until is run, all future runs will compile successfully, even once the offending code is reintroduced. Also, this only ICEs as a lib, not as a binary. Steps to reproduce: # ICE remove test1 or test2 # compiles add the test back, such that there are now two tests as before. # still compiles - # ICE I have been unable to reduce the code further. My apologies for its length. much worse. : :
This code compiles on 1.43 (on stable with and removed) and ICEs on every later version, but the ICE on 1.46 and before is different. modify labels: regression-from-stable-to-stable
This still produces an ICE (removed the use of the crate):
This also ICEs with replaced with a , containing the body of , e.g. Looks like putting it in a in a lib crate repros it but putting it in in an executable crate doesn't unless rustc is passed both and crate types, which is what I effectively did on godbolt.
Too long ago to get CI builds for individual commits, but the range where the bug was introduced is ....
It's a weird ICE all around. The compiler panics on a failed , then while unwinding panics again because of a , so the panic handler calls due to panicking while panicking. It looks like the SIGILL is how is implemented. On 1.46 and before only the second error happened (apparently directly thrown instead of delayed).
Might have been caused by ?
Ah wait no this is in , before it gets to codegen.
Could be , though.
Hard to know because of ;)
It's not before codegen (or at least, rustccodegenssa is in the backtrace so I don't think can be ruled out); the full backtrace of where the delayspan_bug happens is: <details<summaryBacktrace</summary</details
that's just because of the query system; rust doesn't have stages of compilation: https://rustc-dev- But the panic is coming from .
cc
Assigning and removing as .2C.20requires.20two.20tests.20.E2.80.A6) in the prioritization working group.
glacier ""
glacier ""
Appears to be fixed by
Change:
<ins> // aux-build: foreign-generic-mismatch-with-const-arg.rs extern crate foreign_generic_mismatch_with_const_arg; fn main() { foreign_generic_mismatch_with_const_arg::test::<1>(); //~^ ERROR function takes 2 generic arguments but 1 generic argument was supplied } </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --Not sure how this passes the test suite :upsidedownface: Original code from reduced &lt;!-- 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. --: &lt;!-- Include a backtrace in the code block by setting in your environment. E.g. . --&lt;details&lt;summary&lt;strongBacktrace&lt;/strong&lt;/summary&lt;p&lt;/p&lt;/details
This is caused by The fix is to either enable in - this improves diagnostics but pessimizes compile times for successful compilations. do not use spans of const generic parameters from other crates in diagnostics - this makes diagnostics worse but optimizes compile times for successful compilations.
I can't reproduce this either locally or in playground.
Weird, I can still repro locally with and master :shrug:
mcve from a different file:
This is also weird for me to reproduce: I must be doing something wrong, both my and toolchains are the same rustc/cargo commits ( and ): a (or rustc) ICEs on that stdsimd repro a (or rustc) does not a ICEs (but not rustc)
Yeah, something is very weird. I didn't manage to properly this when I tried. I also failed to reproduce on playground or godbolt, but I have encountered maybe around 20 more or less similar files that hit this ICE when checking reports.
Same for me, found a nightly but failed with the CI artifacts. If somehow invoking differently manually or with/without rustup makes things work or fail, maybe the tool also invokes things in the way that doesn't repro...
I forgot to mention: this does also reproduce on master and reverting seems to fix the ICE indeed, as vadim suggested above.
I'm going to remove has-mcve since we're not sure why it sometimes doesn't ICE.
I think this is the better solution. Otherwise, we'll have more and more special cases in diagnostic code which is already very complex.
Couple more reproducers:
Change:
let Some(arg_ty) = self.node_ty_opt(args[idx].hir_id) else { return false; }; <del> let possible_rcvr_ty = expr_finder.uses.iter().find_map(|binding| { </del> <ins> let possible_rcvr_ty = expr_finder.uses.iter().rev().find_map(|binding| { </ins> let possible_rcvr_ty = self.node_ty_opt(binding.hir_id)?; <ins> if possible_rcvr_ty.is_ty_var() { return None; } </ins> // Fudge the receiver, so we can do new inference on it. let possible_rcvr_ty = possible_rcvr_ty.fold_with(&mut fudger); let method = self

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. --Hello, I am sorry, but I wasn't able to reproduce the bug outside my company's project (proprietary and which I don't have the permission to share), so I can't really help here. Code like this resides in proc-macro transformed function ( from leptos) and inside recursivelly calling macro. Here is how approximately it looks: <!-- 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. --Fails on both nightly and stable, backtrace if from nightly. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailsHope this helps and thank for your work.
Relabeling issues which don't have a runnable reproduction (as opposed to not having a minimized one) to the new label S-needs-repro. label +S-needs-repro -E-needs-mcve
I think I encountered the same bug. A minimal example is below. I think the problem is a lookup, which includes the unimplemented trait without checking the length of the argument list before accessing. : Also fails on nightly. <details<summary<strongnightly ructc-</strong</summary<p</p</details
Maybe inside rollup ? cc
I ran into this ICE and minimized my case to the following reproducer. Its slightly different way to get to the same case as 's code above. Still happens from stable 1.77.2 to nightly 2024-04-19. When doing a bisection I get nightly-2023-05-16.
Change:
Node::Lifetime(lt) => Some(lt.ident), Node::GenericParam(p) => Some(p.name.ident()), Node::TypeBinding(b) => Some(b.ident), <ins> Node::PatField(f) => Some(f.ident), Node::ExprField(f) => Some(f.ident), </ins> Node::Param(..) | Node::AnonConst(..) | Node::ConstBlock(..)

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 --
Regression in nightly-2022-08-16 commit[0] 2022-08-14: Auto merge of - GuillaumeGomez:merge-html-elements-together, r=notriddle commit[1] 2022-08-14: Auto merge of - matthiaskrgr:rollup-734hkpt, r=matthiaskrgr commit[2] 2022-08-15: Auto merge of - compiler-errors:as-a-treat, r=jackh726 commit[3] 2022-08-15: Auto merge of - austinabell:skip_optimization, r=Mark-Simulacrum commit[4] 2022-08-15: Auto merge of - ehuss:even-more-attribute-validation, r=cjgillot commit[5] 2022-08-15: Auto merge of - michaelwoerister:new-cpp-like-enum-debuginfo, r=wesleywiser commit[6] 2022-08-15: Auto merge of - matthiaskrgr:rollup-9450lzs, r=matthiaskrgr commit[7] 2022-08-15: Auto merge of - matthiaskrgr:rollup-f1zur58, r=matthiaskrgr
WG-prioritization assigning priority (). label -I-prioritize +P-medium
claim
Originates in PR . We are returning for although it does have an ident: The fix would be to start returning the ident. suffers from the same problem and may need the same treatment.
Change:
main_thread_worker_state = MainThreadWorkerState::Idle; } // If the thread failed that means it panicked, so we abort immediately. <del> Message::Done { result: Err(()), worker_id: _ } => { </del> <ins> Message::Done { result: Err(None), worker_id: _ } => { </ins> bug!("worker thread panicked"); } <ins> Message::Done { result: Err(Some(WorkerFatalError)), worker_id: _ } => { return Err(()); } </ins> Message::CodegenItem => bug!("the coordinator should not receive codegen requests"), } }

Discussion:
Ok, so rustc outputting to /dev/null is a bit pathelogical but it used to not ICE the compiler. If you checkout and from dir tests/suite/futurescore run: rustc --crate-type lib -o /dev/null Then rustc is vexed: (ICEs on stable and nightly) The irony is that this is in the test suite of a rust code minimisation project.... Let me minimise the reproduction of the problem...
Thanks to rust-reduce I managed to get the repro down to: Interestingly it doesn't ICE on playground - I'm guessing playground is on linux?
Indeed
triage: P-medium, removing nomination tag, assigning self.
hmm. I nonetheless see an ICE on my own Linux machine. (There is probably some other reason the ICE does not replicate on the playpen.)