jiebi/CodeConvo huggingface dataset:
Change:
Q, R(u32), S { <del> d1: u32, d2: u32, </del> <ins> d1: Option<u32>, d2: Option<i32>, </ins> }, } #[automatically_derived]

Discussion:
I tried this code: I expected to see this happen: code fails to compile. Instead, this happened: code compiles, and assertion fails. Changing order of enum variants to make go first fixes the issue: : It's reproducible in in Stable, Beta and Nightly. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I have played around a bit with the example and got to compile an even bigger class of bad programs: You can reproduce this in the . As you can see, the compiler is tricked into thinking that implements . This works with sum and product types, as long as: is the first field (or variant) and are "wrapped" with the same type, i.e , or . I have little experience with internals. Maybe someone more experienced could direct us to where this magic happens?
Expanding the macro yields a looks like it only asserts ness for the first field - whoops! claim
Gonna hand it over to you as discussed on zulip release
claim
On 1.63.0 this failed to compile, as expected (): label regression-from-stable-to-stable
this was recently introduced when was doing derive optimizations.
I'll take a look today, thanks for the report.
Don't worry, we've found the issue already, just wanted to let you know.
See for the fix.
WG-prioritization assigning priority a posteriori () mostly to help tracking the fix progress. label -I-prioritize +P-high
Change:
// option. This file may not be copied, modified, or distributed // except according to those terms. <ins> // Make sure casts between thin pointer <-> fat pointer are illegal. pub trait Trait {} </ins> fn main() { let a: &[i32] = &[1, 2, 3]; let b: Box<[i32]> = Box::new([1, 2, 3]); let p = a as *const [i32]; <ins> let q = a.as_ptr(); a as usize; //~ ERROR illegal cast b as usize; //~ ERROR illegal cast p as usize; //~ ERROR illegal cast // #22955 q as *const [i32]; //~ ERROR illegal cast </ins> <del> a as usize; //~ ERROR cast from fat pointer b as usize; //~ ERROR cast from fat pointer p as usize; //~ ERROR cast from fat pointer </del> <ins> // #21397 let t: *mut (Trait + 'static) = 0 as *mut _; //~ ERROR illegal cast let mut fail: *const str = 0 as *const str; //~ ERROR illegal cast </ins> }

Discussion:
This is done when compiling repository. Use on either the entire handmadehero crate, or handmadelibsdl. Warning: Ugly, code ahead! Cleaned up repo: It does need to be across crate lines, and needs to be returned in a result, afaict.
The issue is that I should not be able to write because is a [T]. Same with .
Actually, to that end, why is bigger than a anything? Why is a a fat pointer at all?
Very similar to , , .
Yes it is, pretty much the same. A should not be differently sized from a , at least IMHO, so why is it?
is a with fewer guarantees; one can convert between them freely (if you ensure the guarantees are maintained for -). In particular, this means is a fat pointer to match .
That is weird...
NVM, I now understand why it is a fat pointer. However, this should be an easy fix, right? Why is a mut [T] seen as the same size as a mut T in rustc? Well, now it isn't, so is fixed, but it still panics at .
Change:
cargo.env("XARGO_RUST_SRC", builder.src.join("src")); // Debug things. cargo.env("RUST_BACKTRACE", "1"); <del> // Configure `cargo install` path, and let cargo-miri know that that's where // xargo ends up. cargo.env("CARGO_INSTALL_ROOT", &builder.out); // cargo adds a `bin/` </del> <ins> // Let cargo-miri know where xargo ended up. </ins> cargo.env("XARGO", builder.out.join("bin").join("xargo")); let mut cargo = Command::from(cargo);

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. 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 I-nominated.
Change:
<ins> error[E0307]: invalid `self` parameter type: T --> $DIR/issue-66312.rs:4:22 | LL |     fn is_some(self: T); |                      ^ | = note: type of `self` must be `Self` or a type that dereferences to it = help: consider changing to `self`, `&self`, `&mut self`, `self: Box<Self>`, `self: Rc<Self>`, `self: Arc<Self>`, or `self: Pin<P>` (where P is one of the previous types except `Self`) error: aborting due to previous error For more information about this error, try `rustc --explain E0307`. </ins>

Discussion:
produces an expected error: , the original error is replaced with this: : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Nominating because: The trait impl does not exist, the compiler hallucinated it into existence Inherent methods are supposed to take precedence over trait methods This might indicate a quite serious bug in the compiler.
I would suggest stable- and beta-nominating the fix for this PR; it seems like this could warrant a point release. cc
modify labels: beta-nominated stable-nominated
Phew; looks like precedence works correctly in non-error code at least: Crisis averted? :)
assign
unnominating for back ports; we don't backport nominate issues, just Pull Requests.
claim I'll take a look, since is finding this to be mighty tricky to track down
I managed to get similar symptoms without async but with . But this time the trait compiles.
I am 99% sure that also applies here.
The async case is fixed by , I think we should break out the arbitrary self types case into a distinct bug.
Change:
) -> hir::ExprKind<'hir> { macro_rules! make_if { ($opt:expr) => {{ <ins> let cond = self.lower_expr(cond); </ins> let then_expr = self.lower_block_expr(then); <del> hir::ExprKind::If(self.lower_expr(cond), self.arena.alloc(then_expr), $opt) </del> <ins> hir::ExprKind::If(cond, self.arena.alloc(then_expr), $opt) </ins> }}; } if let Some(rslt) = else_opt {

Discussion:
I tried this code: : Note: A simpler program does not crash, but does not compile.
Is it possible for you to share the code?
It might be better for you to share the code which reproduces the issue on your nightly, 2021-02-11, so that I can try to reproduce it on the latest nightly build and possibly find the commit that might have introduced this issue.
Okay, I'll trim down my base and share it later today.
I deleted my whole project and got this
Thanks label: -E-needs-mcve
Not sure if this helps: I ran on my host target , and it is shown that it ICEd back in 2018 (even before the initial implementation of the feature.
Duplicate of
Change:
pub fn set(stack_bounds: (uint, uint), stack_guard: uint, thread: Thread) { THREAD_INFO.with(|c| assert!(c.borrow().is_none())); <del> match thread.name() { Some(name) => unsafe { ::sys::thread::set_name(name); }, None => {} } </del> THREAD_INFO.with(move |c| *c.borrow_mut() = Some(ThreadInfo{ stack_bounds: stack_bounds, stack_guard: stack_guard,

Discussion:
I think this is fallout of , and it's somewhat unfortunate :( ! cc
Yup. Didn't think of that. So don't set the name of the main thread I suppose?
Yeah that may be the best option after all (sorry for recommending the opposite!)
Okay, no problem, I'll send PR...
Thanks!
Change:
<ins> // edition:2018 #![feature(async_await)] async fn print_dur() {} fn main() { async { let (); }.await; //~^ ERROR `await` is only allowed inside `async` functions and blocks async { //~^ ERROR `await` is only allowed inside `async` functions and blocks let task1 = print_dur().await; }.await; (async || 2333)().await; //~^ ERROR `await` is only allowed inside `async` functions and blocks (|_| 2333).await; //~^ ERROR `await` is only allowed inside `async` functions and blocks //~^^ ERROR } </ins>

Discussion:
Hi I'm pretty new to rust and programming in general. I was trying (failing) to write some toy async code and I got this internal compiler error, the theme seems to be always report ICEs so here we go This was from cargo: ~ The code I was trying was this code: ~ <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Minimized:
ICEs with any statement between while inside a function that isn't async ICE Error without and without the ICE statement inside async function
claim
This is actually the same as . I think I've got a fix for both.
do you have a PR for this open?
Closing as a duplicate of , both of which are fixed by

<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Not had a lot of time to look at this unfortunately and it appears has come up with a fix in in the meantime. release-assignment
claim
assign (Sorry for the noise, testing a new GH feature)
Change:
strategy: fail-fast: false matrix: <del> build: [linux64, macos, win32] </del> include: <del> - build: linux64 os: ubuntu-latest </del> <ins> - os: ubuntu-latest </ins> host_target: x86_64-unknown-linux-gnu <del> - build: macos os: macos-latest </del> <ins> - os: macos-latest </ins> host_target: x86_64-apple-darwin <del> - build: win32 os: windows-latest </del> <ins> - os: windows-latest </ins> host_target: i686-pc-windows-msvc steps: - uses: actions/checkout@v3

Discussion:
Specifically, this manifested with indexing into a dvec. Not all of the code that was manipulating s was handling the case. Already fixed it, about to check in a fix. Thanks to for the test case.

It's currently ignored on Windows.
The code in question looks like: When I commented-out the ignore and a then this test passed on my Windows machine (Mingw32 + 64 bit Windows 7). So perhaps this particular issue is no more?
Fixed in

A comment suggests the type should be something richer, perhaps, than just .
Blocked on or something similar
Definitely not backwards incompatible for 1.0 if this depends on Rust 2.0 features. Renominating.
Nominating for "far-future" (does that require nomination?)
FIXME is gone, bug is too vague, closing

as per a FIXME.
Ok, so, the strings "globalenv" and "getglobalenvchan" don't appear in the source anymore, so I'm going to close this bug...
Change:
if self.target.contains("windows") { build_cred( "cargo-credential-wincred", <del> "src/tools/cargo/crates/credential/cargo-credential-wincred", </del> <ins> "src/tools/cargo/credential/cargo-credential-wincred", </ins> ); } if self.target.contains("apple-darwin") { build_cred( "cargo-credential-macos-keychain", <del> "src/tools/cargo/crates/credential/cargo-credential-macos-keychain", </del> <ins> "src/tools/cargo/credential/cargo-credential-macos-keychain", </ins> ); } build_cred( "cargo-credential-1password", <del> "src/tools/cargo/crates/credential/cargo-credential-1password", </del> <ins> "src/tools/cargo/credential/cargo-credential-1password", </ins> ); cargo_bin_path }

Discussion:
Happened during probably since cc
You'll need to delete the directory. There was probably a file left behind, and git won't delete the directory automatically.
Hm, there is no such directory ?! :sweatsmile: There is a though
My fault. I forgot to update Will send a PR.
What is most concerning to me is that this actually did not fail the entire , so this would/did not even break CI..? is there something we can do about that?
Run in CI probably? I supposed to run it locally before submitting a PR. However, that was an unlucky day. Something on nightly cannot build, so I blindly pushed .
Oh, sorry, I misunderstood what was going on. There have been some issues with those directories being moved around, but this was different. The issue here is that the credential helpers are being included on an "as available" basis. Because they are nightly and experimental, they were intentionally marked as being optional so that if they failed it wouldn't cause problems here on rust-lang/rust. Eventually, if it gets stabilized, this will need to change to make them required tools.
Change:
<ins> // Test the parse error for an invalid digit in recursion_limit #![recursion_limit = "-100"] //~ ERROR `recursion_limit` must be a non-negative integer //~| not a valid integer fn main() {} </ins>

Discussion:
The following code since it exceeds the default recursion limit. Using as the recursion limit works as expected. This is because we don't check for integer overflow errors when parsing limits: There's a few options here. My preference would be to silently default to when overflow occurs. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Hi! I'd like to try and handle this. If I understand this correctly, we should check if there is an , and if that error is an overflow. If it's an overflow, we default to ? claim
correct
Change:
version = "0.1.0" dependencies = [ "byteorder 1.2.7 (registry+https://github.com/rust-lang/crates.io-index)", <del> "cargo_metadata 0.7.1 (registry+https://github.com/rust-lang/crates.io-index)", </del> <ins> "cargo_metadata 0.8.0 (registry+https://github.com/rust-lang/crates.io-index)", </ins> "colored 1.6.0 (registry+https://github.com/rust-lang/crates.io-index)", "compiletest_rs 0.3.22 (registry+https://github.com/rust-lang/crates.io-index)", <del> "directories 1.0.2 (registry+https://github.com/rust-lang/crates.io-index)", </del> <ins> "directories 2.0.1 (registry+https://github.com/rust-lang/crates.io-index)", </ins> "env_logger 0.6.0 (registry+https://github.com/rust-lang/crates.io-index)", "hex 0.3.2 (registry+https://github.com/rust-lang/crates.io-index)", "log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)",

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. 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 prioritization.
Miri is fixed upstream, but will be broken again by so I'd like to land that before updating.
Change:
} } impl2_predicates.extend( <del> traits::elaborate_predicates(tcx, always_applicable_traits) </del> <ins> traits::elaborate_predicates_with_span(tcx, always_applicable_traits) </ins> .map(|obligation| obligation.predicate), ); <del> for predicate in impl1_predicates { </del> <ins> for (predicate, span) in impl1_predicates { </ins> if !impl2_predicates.contains(&predicate) { check_specialization_on(tcx, predicate, span) }

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: <!-- Please provide a link to -- The current output is: <!-- The following is not always necessary. --Ideally the output should not reference the debug format of an internal type <!-- 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. -- modify labels +F-specialization +A-specialization +requires-nightly
Change:
} } <ins> pub struct TypeOfDepthLock<'a, 'tcx: 'a>(&'a LocalCrateContext<'tcx>); impl<'a, 'tcx> Drop for TypeOfDepthLock<'a, 'tcx> { fn drop(&mut self) { self.0.type_of_depth.set(self.0.type_of_depth.get() - 1); } } </ins> /// Declare any llvm intrinsics that you might need fn declare_intrinsic(ccx: &CrateContext, key: &str) -> Option<ValueRef> { macro_rules! ifn {

Discussion:
Repeating segment:
Note: the type is regular, just not representable (actual non-regular data types make selection overflow, possibly at trans time).
This particular case could be handled in type-checking, but the general case requires some sort of recursion check after the type has been monomorphized.

causes a stack overflow.
This is a stack overflow inside middle::traits::project::normalizeprojectiontype

I've encountered a variant of this bug (or is it another bug? please advise if so and I will post it separately): If I remove the lifetime, the stack overflow no longer occurs.
Seems to be a dupe of
example was fixed in 1.4.

The following program generates a trans-time stack overflow.
Can confirm this is still an issue
This is somewhat distinct from , as it creates an irregular type without selection errors.
actually, not really.

On 3/4/2015 on playpen, the following code: the following error: This may be considered a duplicate of issue , which notes a similar problem with recursive trait bounds. I figured this may be unique given that this involves a recursive associated type on a trait, rather than a recursive trait itself.
cc
This was just rediscovered in the #rust IRC.
The code that that IRC example was simplified from was code that looked reasonably sane (and was quite far removed from simple recursion like this), so trying to come up with an error message instead of a crash would be quite handy.
Change:
} } <ins> /// This is a marker for a fatal compiler error used with `resume_unwind`. pub struct FatalErrorMarker; </ins> /// Turns a closure that takes an `&mut Formatter` into something that can be display-formatted. pub fn make_display(f: impl Fn(&mut fmt::Formatter<'_>) -> fmt::Result) -> impl fmt::Display { struct Printer<F> {

Discussion:
found while checking with When you run the snipped above with , rustc panics, but the exit status is as if there was just a normal compiler error, instead of a . This tripped up automatic ice-reduction that relies on a somewhat familiar exit code when the program crashes :sweat_smile:
is the problematic line here that turns ICEs into "normal" fatal errors that call exit(1) though actually at least with the non parallel compiler i'm very surprised that we're ending up in a query in the first place after panicking.
It seems that current stable does correctly exit with here... I bisected the exit code 101 -exit code 1 change with a crashing file ( ) and got to Regression in nightly-2023-08-31 Regression in cc /
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
pub fn f3(arg: <Priv as PrivTr>::Assoc) {} //~^ WARNING type `aliases_priv::Priv` is more private than the item `aliases_priv::f3` //~| WARNING associated type `aliases_priv::PrivTr::Assoc` is more private than the item `aliases_priv::f3` <ins> //~^^^ WARNING trait `aliases_priv::PrivTr` is more private than the item `aliases_priv::f3` </ins> } mod aliases_params {

Discussion:
This is a pretty common use case, so this bug has probably already been registered, but I couldn't find anything while searching around, so I'm reporting this here just in case. I ran this code: When running this code, I expect to simply get a not yet implemented error on the function. Instead, I get this: : returns an , and is not a trait method–it's just a regular method. Therefore, AFAIK, this should compile. Notably, making either or as makes it compile fine.
Regression in . cc
oli's on leave so cc-ing PR 's reviewer
WG-prioritization assigning priority (). label -I-prioritize +P-high
Change:
<ins> // check-pass #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash struct Foo<const D: usize> { state: Option<[u8; D]>, } impl<const D: usize> Iterator for Foo<{D}> { type Item = [u8; D]; fn next(&mut self) -> Option<Self::Item> { if true { return Some(self.state.unwrap().clone()); } else { return Some(self.state.unwrap().clone()); } } } fn main() {} </ins>

Discussion:
<short summary of the bugI tried this code: I expected to see this happen: It should build. Instead, this happened: rustc crashed with: Possible workaround: replace with . playground: rustc version: 1.39.0-nightly 2019-09-15
cc
Also ICEs without explicit feature gate enabled :/
Change:
}); } <ins> fn check_trait_method(&self, method: &Method) { // If there is a TraitRef in scope for an impl, then the method must be in the trait. for &(did, ref trait_ref) in self.current_trait_ref.iter() { let method_name = method.ident.name; if self.method_map.borrow().find(&(method_name, did)).is_none() { let path_str = self.path_idents_to_str(&trait_ref.path); self.resolve_error(method.span, format!("method `{}` is not a member of trait `{}`", token::get_name(method_name), path_str).as_slice()); } } } </ins> fn resolve_module(&mut self, module: &Mod, _span: Span, _name: Ident, id: NodeId) { // Write the implementations in scope into the module metadata.

Discussion:
This code is wrong because ToStr does not define . But what's odd is that the compiler error does not happen in the block but in the : Error message: The expected error message would point to the block that needs to be split into two (one with ToStr and one without a trait).
Reproduced as of
Repro'd with -- but not critical for 0.6, de-milestoning
Appears to be fixed, as per this updated test case: fails with . Closing.
We've regressed: there's a test case (), but it's been xfailed since it was . With I see:
Aaaand, we've un-regressed! Removing all tags except for neesdtest.
Whoops, had the wrong code example, regression still here.
Change:
// of the underlying generator. async fn f() -> u8 { 1 } <ins> async fn foo() -> [bool; 10] { [false; 10] } </ins> pub async fn g(x: u8) { match x {

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</detailsThis is the most minimal example I could find, it needs tokio with the features "macro" and "sync". While this error occured on Nightly I could also reproduce this on stable (as far back as on 1.39, didn't test beyond that because my build started failing because of other reasons) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is very reminiscent of (await in if guard in match statement)
MCVE: Yeah, very .
Thank you for reducing this further. Totally forgot that I could just declare my own async function this way! But I do understand correctly that the linked example is just related, not the same? (Since it's still occuring in latest nightly and the linked issue seemes to be already fixed)
Yeah, just related - my immediate guess is this is some case that was missed in the fix for that issue. The difference appears to be that is used in a index expression after the await instead of some other way.
Another example: Any usage of in the if guard after the that does not cause to be autorefed (like just from the MCVE would) appears to trigger the ICE.
claim
Assigning as and removing .
Change:
e.note(&note); } if let Some((label, span)) = err.secondary_label { <del> let sp = fmt_span.from_inner(span); e.span_label(sp, label); </del> <ins> if efmt_kind_is_lit { e.span_label(fmt_span.from_inner(span), label); } </ins> } e.emit(); return DummyResult::raw_expr(sp, true);

Discussion:
Reproducer: Playground link: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'd love to take a look at this. Seems to be ICEing in code that displays the diagnostic to fixup the actual compiler error here. claim