jiebi/CodeConvo huggingface dataset:
Change:
| LL | enum Foo { |      ^^^ <ins> LL | </ins> LL |     A(foo::SecretlyEmpty), |     - not covered <ins> = note: pattern `Foo::A(_)` is currently uninhabited, but this variant contains private fields which may become inhabited in the future </ins> = note: the matched value is of type `Foo` help: you might want to use `let else` to handle the variant that isn't matched |

Discussion:
The following code compiles on nightly (): But if the wrapper type is moved into a module to make the field private, then it does not: (): Making the field makes it compile again. Is this expected? I suppose I could understand if it is; the private fields could change to make actually be constructable and therefore make the pattern refutable. But if that's the case, then I think the compiler should point this out, like . If indeed this is expected, is there any way for me as a library author to somehow convince the compiler that I will never change the fields to make the type constructable? I want users of my library to be able to elide match arms when I give them an . label +T-compiler +F-never_type +D-confusing +requires-nightly +S-bug-has-mcve
label +F-exhaustive_patterns
are we sure this is actually a bug? As I said, I could understand how it's not:
I'm not sure either way - however at the very least, as you point out, it makes sense to have some better diagnostics
This is definitely intentional. But yeah, it should have a better error message. Not currently I don't think. It would probably require us to add an trait, eg. something like: This trait would then need to be a lang item so that the exhaustiveness check could make use of it. Adding this trait would require an RFC but I doubt there'll be much enthusiasm for adding another special trait for such a niche use-case. Alternatively, you could give an or method to expose the uninhabitedness of the inner value. It's not quite what you're asking for but it's still concise-ish:
Is supposed to be “injected” where an otherwise required match arm was omitted? Wouldn't that run into the same discussions project-deref-patterns had about impure code (code with side effects) inside patterns? Their existence would heavily hinder optimizations of match expressions (like translation to jump tables or reordering).
If the type implementing really is uninhabited then there won't actually be any impure code in the match. The call to would only need to be injected for types that fake uninhabitedness with an impl that panics/aborts. We could also rule that out be instead making -only like .

Making a trait isn't straightforward exactly because inhabitedness depends on visibility questions. It would probably have to mean "Uninhabited as far as the outside world is concerned", or it could use a trick like the in to make it depend on the module.
Change:
for piece in pieces { match piece { FormatArgsPiece::Literal(s) => { <del> for c in s.as_str().escape_debug() { template.push(c); </del> <ins> for c in s.as_str().chars() { template.extend(c.escape_debug()); </ins> if let '{' | '}' = c { template.push(c); }

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: When running , the format string literals for the first two s should remain valid string literals. Instead, this happened: This code is generated: Note the double and in the escapes. The escape sequences in the last are correctly preserved. This is annoying because it makes it impossible to run on the macro-expanded source, which is helpful when trying to read macro-generated code. <!-- 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I haven't looked at it, but this is probably going wrong somewhere in when printing .
Looks like you’re right: As I understand this, it duplicates curlies regardless of whether they’re part of an escape sequence.
claim
Change:
<del> # If this file is modified, then llvm will be (optionally) cleaned and then rebuilt. # The actual contents of this file do not matter, but to trigger a change on the # build bots then the contents should be changed so git updates the mtime. 2019-03-18 </del>

Discussion:
fortunately: cc
Some potentially useful extra info:
backtrace from running under in details block: <details</details
hmm for some reason this system is using a with ; i wonder if that is relevant... but that should only affect the bootstrap behavior, not the number of codegen-units used in the final build, right? I guess I should double-check this against a nightly that I download via , just to be sure...
yeah okay this doesn't occur on a nightly I downloaded via , ... grr...
And unfortunately the debug does not replicate after I do a rebuild of LLVM with in the ... (I'll have to see if the problem was actually due to some other sort of staleness of my LLVM object files...?)
can't replicate anymore. :( I have a sneaking suspicion that this might be due to my build of LLVM being stale in some way? not sure. I sort of wish I had taken a snapshot of my directory structure at the time before I cleaned it as part of trying to test out alternate configurations...
Fwiw I have the same issue locally
It is LLVM, I had these failures (all segfaults, i.e. "signal 11"): And they were fixed by (LLVM rebuilt a few of its files). We should keep track of the fact that we don't detect LLVM needing a rebuild correctly. IMO should contain the git hash of the submodule. The rebuild is really fast, especially after small deltas, and it's better than weird crashes.
Same issue here, with two separate rustc checkouts. Currently rebuilding LLVM to see if that helps. (Deleting that file triggered a complete rebuild.)
Confirmed that rebuilding LLVM fixes the problem.

I've spent the past few hours looking through documentation for how to build rustc with a patched LLVM without success. Currently, the best I'm at is: And then build with: But even that doesn't rebuild anything unless I . Which completely loses incremental compilation results. Is there any way to make this development workflow better? Rebuilding from scratch at every change is… painful.
You need to modify to rebuild LLVM. (tagging this issue as a documentation problem.)
Thanks! Leaving open for the documentation problem :)

I Changed the submodule, commited the changes; Commited the submodule commit change in the rust repo; Built. Rustbuild did not seem to pick up on the submodule being changed.
LLVM rebuild is currently triggered only when contents of and stamps disagree (including being non-existent), so it's always manual. Full checking of something in LLVM being outdated is not performed because it's expensive thing to do on every build, but the submodule state check can be performed I guess.
Change:
<ins> error: expected `;`, found `(` --> $DIR/missing-semi.rs:6:5 | LL |     () => { |     ^ no rules expected this token in macro call error: aborting due to 1 previous error </ins>

Discussion:
one of the desired output should be much help, rather than: No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
use std::num::wrapping::OverflowingOps; use std::cmp::Ordering; use std::collections::hash_map::Entry::Vacant; <del> use std::{i8, i16, i32, i64}; </del> <ins> use std::{i8, i16, i32, i64, u8, u16, u32, u64}; </ins> use std::rc::Rc; fn lookup_const<'a>(tcx: &'a ty::ctxt, e: &Expr) -> Option<&'a Expr> {

Discussion:
This affects the test suites for the and crates.
triage: I-wrong, P-high (1.0)
triage: P-high (1.0)
I ended up adding the 1.0 milestone by hand; isn't the above note with supposed to do it?
cc
the log above says that highfive did add this to the 1.0 milestone - it might just have been that your local view of the webpage needed refreshing?
yeah I guess so, I don't know what happened anymore. Maybe I should have given highfive a little more time to react.
Change:
<ins> warning: the feature `generic_const_exprs` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/mismatched-gat-subst-kind.rs:1:12 | LL | #![feature(generic_const_exprs)] |            ^^^^^^^^^^^^^^^^^^^ | = note: see issue #76560 <https://github.com/rust-lang/rust/issues/76560> for more information = note: `#[warn(incomplete_features)]` on by default error[E0747]: constant provided when a type was expected --> $DIR/mismatched-gat-subst-kind.rs:8:13 | LL | fn f<T: B<U<1i32> = ()>>() {} |             ^^^^ error: aborting due to previous error; 1 warning emitted For more information about this error, try `rustc --explain E0747`. </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
searched nightlies: from nightly-2022-12-30 to nightly-2023-03-18 regressed nightly: nightly-2023-01-01 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsRegression in
aaah shit, the commit only modified the backtrace :laughing: so "panicked at" no longer triggers before that..
`
maybe
Change:
) { err.subdiagnostic(subdiag); } <ins> if let Some(hir::Node::Expr(m)) = self.tcx.hir().find_parent(scrut_hir_id) && let Some(hir::Node::Stmt(stmt)) = self.tcx.hir().find_parent(m.hir_id) && let hir::StmtKind::Expr(_) = stmt.kind { err.span_suggestion_verbose( stmt.span.shrink_to_hi(), "consider using a semicolon here, but this will discard any values  in the match arms", ";", Applicability::MaybeIncorrect, ); } </ins> if let Some(ret_sp) = opt_suggest_box_span { // Get return type span and point to it. self.suggest_boxing_for_return_impl_trait(

Discussion:
I tried this code (): I expected to see this happen: A compiler error about missing between and Instead, this happened: This is very confusing, because I "know" that return type is which is coercible to anything else (or whatever is the technical explanation for "we can really ignore the return type of "), so it should not ever be present in error messages about mistyping stuff. <!-- 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. --: This issue is also present in 1.34.2 (from a year ago), and in two-week-old nightly (rustc 1.45.0-nightly ( 2020-05-11)) p.s.: When deminimizing the issue, i realized that it's even more confusing when match is the last statement in a for loop (as it was in my real code), i.e.: gives the same error message about incompatible match arms.
The s coerces to because the whole needs to evaluate as a statement, not an expression because its return value is ignored. Adding a trailing "fixes" the code.
As far as I can tell, didn't fix this issue (you didn't add a test for it either), and the two UI tests that the PR did touch, the suggestion didn't do anything useful -- it only fires when one of the arms is actually evaluated to be type , rather than being constrained to due to (lack of) semicolon.
Actually, we do suggest using a semicolon, but not via . I'm just gonna revert that, and add this as a test.
Change:
cx.expr_path(test_path("assert_test_result")), vec![ // $test_fn() <del> cx.expr_call(sp, cx.expr_path(cx.path(sp, vec![item.ident])), vec![]), // ) </del> <ins> cx.expr_call( ret_ty_sp, cx.expr_path(cx.path(sp, vec![item.ident])), vec![], ), // ) </ins> ], ), // } ), // )

Discussion:
Edit: outstanding work is to change the span from pointing at the function body to point at the return type. adds a test for the case where a unit test returns a value that does not implement . The message currently talks about and has an ugly multi-line span: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
As long as we have the method signature around when we emit E0277, it has a field with the span for the return type, which should be used for this instead, but this will probably require some special casing this in that (already quite hairy) diagnostic code. Extending could be possible, but I would advice against doing so to avoid turning that attribute into a bigger monster than it already is.
Chiming in that this confused me as I was preparing for a Rust training session, where I expect it would confuse the students even more. Specifically, this should not talk about at all as it's plausible to cause people to look in the wrong spot.
CC
Just started learning Rust and came across this error while writing some tests- I absolutely agree "ungreat" is perfect word choice.
It could get even more confusing when : Rust 1.64
This issue is now (mostly) fixed on nightly by and should be closed I think. The error message is now correct but the span is still “ugly”. I've overlooked this issue and only closed its duplicate, namely .
Actually, let's keep this open only for the span change :)
Just wrap the return type with a struct and implement the Termination trait for that wrapper struct example
Note that this GitHub issue is about the subpar error message given by the compiler which should be fixed and not about potential solutions for user code when facing this message. claim
Change:
pub fn codegen_fulfill_obligation<'tcx>( ty: TyCtxt<'tcx>, (param_env, trait_ref): (ty::ParamEnv<'tcx>, ty::PolyTraitRef<'tcx>), <del> ) -> Vtable<'tcx, ()> { </del> <ins> ) -> Option<Vtable<'tcx, ()>> { </ins> // Remove any references to regions; this helps improve caching. let trait_ref = ty.erase_regions(&trait_ref);

Discussion:
I'm seeing an internal compiler error on the following input (found by ): The error happens on stable, beta, and nightly.
This regressed in .
cc
triage: already has fix in pipeline. P-high. removing nomination label.
Change:
/// Returns the result of an unchecked addition, resulting in /// undefined behavior when `x + y > T::max_value()` or `x + y < T::min_value()`. <del> #[cfg(not(stage0))] </del> <ins> #[cfg(not(bootstrap))] </ins> pub fn unchecked_add<T>(x: T, y: T) -> T; /// Returns the result of an unchecked substraction, resulting in /// undefined behavior when `x - y > T::max_value()` or `x - y < T::min_value()`. <del> #[cfg(not(stage0))] </del> <ins> #[cfg(not(bootstrap))] </ins> pub fn unchecked_sub<T>(x: T, y: T) -> T; /// Returns the result of an unchecked multiplication, resulting in /// undefined behavior when `x * y > T::max_value()` or `x * y < T::min_value()`. <del> #[cfg(not(stage0))] </del> <ins> #[cfg(not(bootstrap))] </ins> pub fn unchecked_mul<T>(x: T, y: T) -> T; /// Performs rotate left.

Discussion:
We should only pass stage0 in general, should be sufficient for all use cases. cc for awareness and in case there's any concerns
Change:
<del> Subproject commit 5a5152f653959d14d68613a3a8a033fb65eec021 </del> <ins> Subproject commit e6a6470d1eb4c88fee4b1ea98cd8e0ac4a181c16 </ins>

Discussion:
Fuzzer generated code: This should output : But on it prints something different. masks the bug. This is only reproducible on , but not on or . The reproducer is very sensitive to small changes. For instance, changing the length of in to prevents the bug. For these reasons I suspect it's an Apple Silicon specific calling convention bug leading to some stack corruption. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label O-aarch64 O-macos
WG-prioritization assigning priority (). label -I-prioritize +P-high
I have another reproduction of what I believe is the same bug, but this one is only 34 lines, has only safe code and doesn't need a hasher: This should print but with The value of is different. In fact, the number commented "addend" in the original code gets to in the miscompiled result. If you change it to e.g. you get
Any chance that the fix for also fixes this one? Looks kinda similar to me.
No it fixes neither program in this issue. might be related, since it also passes a vector on the stack
Does this issue still reproduce?
Running on an MBP M1, with rustc 1.81.0-nightly ( 2024-06-12), I get the same hash output for both of the executions listed: <details</details
Thanks! Would you mind also trying the other test case in
That version does reproduce the issue:
Thanks!
I can reproduce this. claim
Upstream issue:
label +llvm-fixed-upstream
Change:
} } hir::ItemKind::Impl { ref of_trait, items, .. } => { <ins> if of_trait.is_some() { self.worklist.push(item.hir_id); } </ins> for impl_item_ref in items { let impl_item = self.krate.impl_item(impl_item_ref.id); if of_trait.is_some()

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: no warning is emitted. Instead, this happened: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I'm not sure this needs to block , but it affects it, so marking as blocking for now.
claim
This is actually not an issue related to const generics :sweat_smile: It does not look at trait impls even if they are used as long as they don't overwrite the relevant method.
Change:
<ins> // edition:2018 #![feature(generic_associated_types)] #![feature(type_alias_impl_trait)] use std::future::Future; trait MakeFut { type Fut<'a> where Self: 'a; fn make_fut<'a>(&'a self) -> Self::Fut<'a>; } impl MakeFut for &'_ mut () { type Fut<'a> = impl Future<Output = ()>; //~^ ERROR: the type `&mut ()` does not fulfill the required lifetime fn make_fut<'a>(&'a self) -> Self::Fut<'a> { async { () } } } fn main() {} </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. --: <details<summary<strongBacktrace</strong</summary<p(F# highlighting looks reasonably nice) </p</details
modify labels +requires-nightly +F-genericassociatedtypes +F-typealiasimpl_trait
GATs issue triage: not blocking. Works on latest nightly; needs test.
label: +E-needs-test
Change:
<ins> error[E0283]: type annotations needed: cannot resolve `_: A` --> $DIR/issue-63496.rs:4:21 | LL |     const C: usize; |     --------------- required by `A::C` LL | LL |     fn f() -> ([u8; A::C], [u8; A::C]); |                     ^^^^ error[E0283]: type annotations needed: cannot resolve `_: A` --> $DIR/issue-63496.rs:4:33 | LL |     const C: usize; |     --------------- required by `A::C` LL | LL |     fn f() -> ([u8; A::C], [u8; A::C]); |                                 ^^^^ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0283`. </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:
ret }); <del> // Needs to go *after* expansion to be able to check the results // of macro expansion.  This runs before #[cfg] to try to catch as // much as possible (e.g. help the programmer avoid platform // specific differences) time(time_passes, "complete gated feature checking 1", || { sess.track_errors(|| { let features = syntax::feature_gate::check_crate(sess.codemap(), &sess.parse_sess.span_diagnostic, &krate, &attributes, sess.opts.unstable_features); *sess.features.borrow_mut() = features; }) })?; </del> // JBC: make CFG processing part of expansion to avoid this problem: // strip again, in case expansion added anything with a #[cfg].

Discussion:
Macro-expanded unconfigured items are gated feature checked, but ordinary unconfigured items are not. For example, the following should compile, ... If we manually expand , it always compiles:
It looks like this was (introduced in ), but I don't think it's a good idea. cc cc
There are arguments on about why this is not a good idea: is typically used by crates that need to build against both stable and nightly and use nightly-specific features when available (the most important example that I have in mind is syntax extensions using plugins on nightly and syntex on stable). Checking for use of gated features inside this -guarded code will break those crates, and it's not a good thing, this use case is actually useful. This check pass should be removed.
cc