jiebi/CodeConvo huggingface dataset:
Change:
let placeholder_self_ty = placeholder_trait_predicate.self_ty(); let placeholder_trait_predicate = ty::Binder::dummy(placeholder_trait_predicate); let (def_id, substs) = match *placeholder_self_ty.kind() { <del> ty::Alias(_, ty::AliasTy { def_id, substs, .. }) => (def_id, substs), </del> <ins> // Excluding IATs here as they don't have meaningful item bounds. ty::Alias(ty::Projection | ty::Opaque, ty::AliasTy { def_id, substs, .. }) => { (def_id, substs) } </ins> _ => bug!("projection candidate for unexpected type: {:?}", placeholder_self_ty), };

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 --
This might also be related to cc
label F-inherentassociatedtypes claim
Change:
Add { #[primary_span] span: Span, <del> found: Ty<'tcx>, </del> <ins> found: String, </ins> }, #[suggestion( typeck::add_return_type_missing_here,

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should suggest how to specify the return type when a function returns a closure. <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Is some thing like this not ok ?
release-assignment
It's ok but I was wondering if it's possible to make the compiler give some form of a suggestion to the user on how to do this. Cause the current diagnostics does not suggest how to fix it.
Change:
<ins> error[E0658]: the `#[expect]` attribute is an experimental feature --> $DIR/expect-future_breakage-crash-issue-126521.rs:8:5 | LL |     #[expect(semicolon_in_expressions_from_macros)] |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: see issue #54503 <https://github.com/rust-lang/rust/issues/54503> for more information = help: add `#![feature(lint_reasons)]` to the crate attributes to enable = note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0658`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '-Zunstable-options --edition=2024 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'assertion failed: matches!(, Error Allow)'' 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: [earlylintchecks] perform lints prior to macro expansion [hircrate] getting the crate HIR -- label +F-stmtexpr_attributes
bisects to :thinking: cc edit: ah the assertion was there...
Change:
<ins> error[E0599]: no method named `clone` found for type parameter `T` in the current scope --> $DIR/issue-95898.rs:5:7 | LL |     t.clone(); |       ^^^^^ method not found in `T` | = help: items from traits can only be used if the type parameter is bounded by the trait help: the following trait defines an item `clone`, perhaps you need to restrict type parameter `T` with it: | LL | fn foo<T: Clone>(t: T) { |        ~~~~~~~~ error: aborting due to previous error For more information about this error, try `rustc --explain E0599`. </ins>

Discussion:
Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: Note: The bound is treated incorrectly. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
You mean that does not handle correctly, right?
Correct, the suggestion reads which is not syntactical. The fix would be to detect this case and correctly suggest
It's my first time contributing and i was taking a look at and didn't find a way to detect . So i ended up adding a flag to , setting it in and checking the flag in to handle the case. Does that seem reasonable?
Adding a new flag to seems a bit heavy. I was thinking you could one of the methods on  to detect if there is a colon following the generic param. Also hmm... I think was also looking at ... I opened up this issue before he said that he was trying to , though I'm not sure if in general or just a specific case in something he was working on (i.e. another suggestion). Perhaps he could comment to see if he's already solved this, in order to deduplicate work?
So. I was fixing the same problem in and I just got a working fix! My solution is to use in order to find the span of . It may be hacky, but I think it's good enough for diagnostics. It seems like my fix doesn't fix this issue, because this suggestion is created using different API (), but it should be easy to extend it to this case too. For example could use internally ( produces better suggestions anyway :D). I'll try to clean my fix & create a PR today.
I took a look at your PR, that's way better than my solution. I will use the method you to to fix this issue if you aren't working on it as well.
Change:
use rustc_arena::TypedArena; use rustc_ast::Mutability; <ins> use rustc_data_structures::fx::FxHashSet; </ins> use rustc_data_structures::stack::ensure_sufficient_stack; use rustc_errors::{ struct_span_err, Applicability, Diagnostic, DiagnosticBuilder, ErrorGuaranteed, MultiSpan,

Discussion:
Sorry about the long title :sweat_smile: Given the following code (): The current output is: Note how the first diagnostic, emitted when matching on a , contains additional information about why this exhaustive match does not pass the exhaustiveness check. Ideally, this information should be to the second diagnostic as well: modify labels: +A-exhaustiveness-checking +A-patterns +D-terse
Hm, even though has a different size on different architectures, should always be exhaustive, right? Then that code would be accepted, but the following would still error: We could have the error for this say "missing pattern: ", which would also work if there's a around it. That said, pretty sure what you describe also happens for enums too, and there we'll want to do what you suggest.
see also
I forgot this issue existed, but yeah this is a lint we want. I explained a bit about how this might be done in , if anyone wants to tackle this feel free to ping me
Change:
| = note: #[deny(overflowing_literals)] on by default <del> error: aborting due to previous error </del> <ins> error: range endpoint is out of range for `u8` --> $DIR/deny-overflowing-literals.rs:5:14 | LL |     for _ in 0..256u8 {} |              ^^^^^^^^ help: use an inclusive range instead: `0..=255u8` error: aborting due to 2 previous errors </ins>

Discussion:
since
It is hitting the here: So I'm not quite sure why the error isn't being emitted yet.
It appears to be hitting this line of code which is cancelling the diagnostic:
this appears to be a stable-to-beta regression ()
triage: P-high. Assigning to self.
We need to change to not consider desugarings coming from loops as external. If that has regressions in our test suite, then we can add a new desugaring kind to differentiate between different parts of the for loop desugaring and target it further, but I do not expect that to be needed.
I've opened with a fix, based on comment.
Change:
use rustc::hir::intravisit::{self, Visitor, NestedVisitorMap}; use rustc::hir; <del> pub struct CheckTypeWellFormedVisitor<'a, 'tcx:'a> { tcx: TyCtxt<'a, 'tcx, 'tcx>, code: ObligationCauseCode<'tcx>, } </del> /// Helper type of a temporary returned by .for_item(...). /// Necessary because we can't write the following bound: /// F: for<'b, 'tcx> where 'gcx: 'tcx FnOnce(FnCtxt<'b, 'gcx, 'tcx>). struct CheckWfFcxBuilder<'a, 'gcx: 'a+'tcx, 'tcx: 'a> { inherited: super::InheritedBuilder<'a, 'gcx, 'tcx>, <del> code: ObligationCauseCode<'gcx>, </del> id: ast::NodeId, span: Span, param_env: ty::ParamEnv<'tcx>,

Discussion:
At the moment WF checking is not done via a query. As a consequence, we cannot cache it during incremental compilation. Seems like an easy optimization. cc
I'm working on this.
Change:
span, E0435, "attempt to use a non-constant value in a constant"); <del> err.span_label(span, "non-constant used with constant"); </del> <ins> err.span_label(span, "non-constant value"); </ins> err } ResolutionError::BindingShadowsSomethingUnacceptable(what_binding, name, binding) => {

Discussion:
rustc 1.0.0 - 1.11.0: rustc 1.12.0 - 1.15.0: rustc 1.16.0 - present: Can we have the first one back please?
To clarify, the problem is in the note:
Note introduced in , using the exact wording from . Rust 1.12 fully transitioned to MIR, which made the repeat count no longer special, thus losing the special error message. I think the note should be reworded to "non-constant used as constant".
The error message today speaks the truth and does so quite well. Closing.
The span label is still pretty nonsensical.
Okay, I'll reopen. Can you provide the exact wording you'd expect? (I personally don't really see any point for a span label, but ... ).
Either remove the label or just "non-constant value" seems to make more sense to me. It's the "with constant" that is weird IMO.
I'll PR.
I just came here after googling and want to say that the first error message is a lot easier to understand!
Change:
GenericArg::Const(c) => c.value.hir_id, } } <ins> pub fn is_const(&self) -> bool { match self { GenericArg::Const(_) => true, _ => false, } } </ins> } #[derive(Clone, RustcEncodable, RustcDecodable, Debug, HashStable)]

Discussion:
This very simple example (): results in: . Changing it to use curly braces around does not help.
This does work:
I was actually just experimenting locally to see if I could fix this and I think I have, I could put a PR up in a few minutes.
Change:
inference_context: new_infer_ctxt(crate_context.tcx), inherent_impls: RefCell::new(FnvHashMap::new()), }.check(crate_context.tcx.map.krate()); <ins> impls::check(crate_context.tcx); </ins> unsafety::check(crate_context.tcx); orphan::check(crate_context.tcx); overlap::check(crate_context.tcx);

Discussion:
Compiling with works fine, definitely does not, though: And, if the bound in is removed, the code compiles fine with or without . So... somehow the test runner is causing a tuple of arity 3 specifically to be inferred to something completely ridiculous.
cc I guess?
points out that specifically having causes the problem.
cc me
FYI: discovered this problem while working on
Slightly more minimized:
contains: This causes the problem.
I'll take a look at it.
Oh, I see you tracked it down -- I thought it might be something like that. This is in fact something I was talking to about as a possible danger of the way we're treating builtin bounds right now, though in a different context.
In fact, I think that the for a tuple ought to be a coherence violation to begin with, actually.
(I think there was language about specifically this in the OIBIT RFC)
I agree with comments here and after a quick chat on IRC with him, we agreed that implementations of built-in traits (and likely default trait impls in the future) should be allowed just on and .
Change:
return; } <del> if item.link_names(&cx.cache).is_empty() { // If there's no link names in this item, // then we skip resolution querying to // avoid from panicking. return; </del> <ins> if let Some(item_id) = item.def_id() { check_redundant_explicit_link_for_did(cx, item, item_id, hir_id, &doc); </ins> } <ins> if let Some(item_id) = item.inline_stmt_id { check_redundant_explicit_link_for_did(cx, item, item_id, hir_id, &doc); } } </ins> <del> let Some(item_id) = item.def_id() else { return; }; let Some(local_item_id) = item_id.as_local() else { </del> <ins> fn check_redundant_explicit_link_for_did<'md>( cx: &DocContext<'_>, item: &Item, did: DefId, hir_id: HirId, doc: &'md str, ) { let Some(local_item_id) = did.as_local() else { </ins> return; };

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. --Basically this is the module where it fails, right now I can't create a minimized example, I'll try to later: on: branch: Bug also exists on nightly, and also on Linux: : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I can confirm this bug on
minimized repro: label T-rustdoc A-intra-doc-links A-resolve S-has-mcve -needs-triage
Change:
// Also skip the witness type, because that has no free regions. substs.as_generator().tupled_upvars_ty().visit_with(self); <del> for upvar_ty in substs.as_generator().upvar_tys() { upvar_ty.visit_with(self); } </del> substs.as_generator().return_ty().visit_with(self); substs.as_generator().yield_ty().visit_with(self); substs.as_generator().resume_ty().visit_with(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. --<!-- 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</detailsNOTE: The bug is found by our work-in-progress compiler testing tool Kira, and the test program is reduced/minimized by <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
does this still panic after ? That only merged a couple days ago so you'll need to update your version of nightly.
Hmm I checked and it does, and it also panics before. So probably unrelated? cc just in case
Note that this works fine on .
Sorry, I accidentally closed the issue. Yes, you are right. It still crashes on the latest nightly version. I have a cron job to update my rust version everyday.
I think we ended up (incorrectly) removing a check in We shouldn't be calling upvarsty if is . This is a separate issue than that was fixed in
claim
Change:
intravisit::NestedVisitorMap::All(&self.tcx.hir()) } fn visit_item(&mut self, it: &'tcx Item) { <ins> debug!("find_existential_constraints: visiting {:?}", it); </ins> let def_id = self.tcx.hir().local_def_id(it.hir_id); // The existential type itself or its children are not within its reveal scope. if def_id != self.def_id {

Discussion:
Mentioning the existential types tracking issue Mentioning and
O_o I don't think I considered closures at all. Should closures be defining uses? Or just uses (and thus only be able to return that type by calling a function that defines the existential)?
As a motivating use case, existential types defined by a closure are required if we want to extend to support referring to local variables.
Yeah, any in-scope use (including in a binding) can be a defining use.
A binding like this? It looks like this is not currently picked up. It is why I had to write rather than simply in my previous comment.
Yeah, the RFC specifies that that should work.
I chose a simpler logic: any in scope use must be a defining use.
We've moved from segmentation faults to an ICE:
Change:
use rustc_middle::middle::codegen_fn_attrs::{CodegenFnAttrFlags, CodegenFnAttrs}; use rustc_middle::mir::visit::*; use rustc_middle::mir::*; <ins> use rustc_middle::ty::TypeVisitableExt; </ins> use rustc_middle::ty::{self, Instance, InstanceDef, ParamEnv, Ty, TyCtxt}; use rustc_session::config::OptLevel; use rustc_span::{hygiene::ExpnKind, ExpnData, LocalExpnId, Span};

Discussion:
I found this ICE while compiling in release mode. : <details<summary<strongBacktrace</strong</summary<p</p</detailsbisect command: bisect result: Regression in
uuh cc
For repro:
You're right that this ICEs after my PR but not before, but this looks like an issue related to type system code or , not MIR inlining itself, so I don't think I can't help here.
Ah so it would have iced before if we had forced inlining before?
Yes, with enough application of this code should ICE before that PR. I couldn't tell you where to apply the attribute though, just squinting at the ICE message it looks like this is significant, though I don't know enough to track down where that closure is.
Is there some rustc flag I can use to force inlining of like ~ everything ~ for testing purposes? :eyes: edit: -Zinline-mir-threshold=0 or something like that? :D
You need to set both thresholds, and I don't think we have a magic value for "always", just use a big number. The defaults are 50 and 100 I think. Also just FYI there's also an inlining depth limit that's not configurable, but it shouldn't be relevant for this PR. But if you see unexpected missed inlinings even with passing those flags, that threshold might be why.
Oh, those flags won't help you before the PR in question, because functions without are simply not considered for inlining at all, no matter their size. Fixing this odd ignoring of size was the whole point of that PR. You can pass to lift that "must have " requirement, but of course that turns on other passes, but the check you're trying to dodge is an explicit check for the MIR opt level inside the Inline pass so... yeah just you might also hit other bugs. You could try turning off the passes that are enabled at mir-opt-level=3 but that would be messy.

The mir opt level is cranked up already anyway Maybe I can find some snippet that somehow reassembles what we are seeing here :) I'll be able to report back in an hour or so I guess ^^
Meh besides a couple more "hangs" (process timeouts) nothing new in the standard rustc test set :/
This is a dupe of I believe
Another reproducer (possibly large): Run in , with rustc 1.71.0-nightly ( 2023-04-29) running on x86_64-unknown-linux-gnu. Failing CI log:
I've been getting this too since about a month ago: I can do a bisect.
Change:
#[unstable(feature = "step_trait", reason = "recently redesigned", issue = "42168")] impl Step for $i_narrower { step_identical_methods!(); <ins> step_signed_methods!($u_narrower); </ins> #[inline] fn steps_between(start: &Self, end: &Self) -> Option<usize> {

Discussion:
I tried this code: I expected to see this happen: No UB. Instead, this happened: UB, confirmed by Miri. is called, which does , or . The implementation of is correct here, and should be safe to call. The implementation that does a wrapping cast from to before doing the unchecked math is the incorrect code here. Signed integers should switch to just using wrapping or unsigned math, whichever gets better codegen out of LLVM. We do have and methods now, but no . <!-- 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. --:
Note that this is reachable on stable since the default impl of uses and not all adapters forward both.
did you find this with Miri or just use Miri to confirm the bug? (I'm asking because I may want to add this to our "bugs found by Miri" list :)
Only confirmed/diagnosed with Miri, spotted manually when looking at the code.
Change:
<ins> fn foo(s: &i32) -> &i32 { let xs; xs } fn main() { let y; // we shouldn't ice with the bound var here. assert_eq!(foo, y); //~^ ERROR binary operation `==` cannot be applied to type //~| ERROR `for<'r> fn(&'r i32) -> &'r i32 {foo}` doesn't implement `Debug` } </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</detailsNOTE: The bug is found by our work-in-progress compiler testing tool Kira, and the test program is reduced/minimized by <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It also fails for every comparison of and
I found another potentially related weirdness: This fails with: But this (without the argument) fails with a different error, even though there should be no difference as is not used: EDIT: Apparently this is intended behavior, see .
searched nightlies: from nightly-2019-01-01 to nightly-2020-10-13 regressed nightly: nightly-2020-05-03 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
Darn, is it really the bitcode commit again? Or did it happen sometime around then? Cc
This bisection is incorrect due to:
Marking this as P-
claim
You have to write if you want to assign this issue.
Thanks bro. claim
Change:
&& (self.look_ahead(2, |t| *t == token::OpenDelim(token::Paren)) || self.look_ahead(2, |t| *t == token::OpenDelim(token::Brace))) { // method macro. <ins> let last_span = self.last_span; self.complain_if_pub_macro(visa, last_span); </ins> let pth = self.parse_path(NoTypesAllowed); self.expect(&token::Not);

Discussion:
Hey, I have an issue on my macros use. The source code of my macro is . I can't put the pub keyword and if I call my macro like this : The methods aren't public. Am I doing something wrong or is it a compiler's bug ? Thanks in advance.
Any news on it ?
Related?
I think.
I just encountered this. I can reproduce it with:
Now let's just hope it'll be fixed sooner or later !
Hm, what should actually mean? A macro in item position can expand to zero or more items. Should the qualifier apply to all of them, or should it be an error to use it with a multi-item macro? We might want to forbid in this position for 1.0, and come back to the issue later. I had a design for that I think would be rather nice. The current workaround is to write The precise syntax is up to the macro author and can accommodate multiple items. This workaround would be less annoying if we had a "0 or 1" repeat operator in macros.
Could you be a little more explicit about the workaround - I can't seem to get it to work.
from the compiler itself. looks better, with less duplicated code.
Thanks for the examples. If I understand them correctly (neither of which generate forms, iiuc), I should be matching on and inserting a literal in the expansion, but does not seem to work :
It works for me on rustc 1.0.0-dev ( 2015-02-16). The playpen is just to have my fix for .
Thanks for the confirmation. I'll be looking forward to a new nightly for once :)