jiebi/CodeConvo huggingface dataset:
Change:
use crate::traits::{Obligation, PredicateObligations}; use rustc_data_structures::sso::SsoHashMap; use rustc_hir::def_id::DefId; <ins> use rustc_middle::infer::canonical::OriginalQueryValues; </ins> use rustc_middle::infer::unify_key::{ConstVarValue, ConstVariableValue}; use rustc_middle::infer::unify_key::{ConstVariableOrigin, ConstVariableOriginKind}; <ins> use rustc_middle::traits::query::NoSolution; </ins> use rustc_middle::traits::ObligationCause; use rustc_middle::ty::error::{ExpectedFound, TypeError}; use rustc_middle::ty::relate::{self, Relate, RelateResult, TypeRelation};

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 occurred in code different from the above but this is a minimal example that causes this failure. I believe I am disobeying some rules in the manner in which is not bound in the underlying type of the trait. This bug appeared in my own code that worked with a previous nightly build. That code does bind into the underlying type and still fails. If I bind it in this example with the following changes: the error goes away. I will need to create a minimal example that produces an ICE closer to the failure in my own code but I was struggling to do this. This is at least one ICE of interest and perhaps the unbound should itself be prevented. I'm not entirely sure. Worthy of note, the following also compiles fine: which omits all of the stuff.
I've isolated it to the following commit range: ..
I determined it was due to the above linked-from PR.
Prior to this PR, the above code would emit the following warning instead of generating the ICE:
This is caused by the fact that acts sort of like a const item with a const param ty the references other generic parameters: . When we relate the in we constrain infer vars to be the same as eachother but do not end up actually resolving the infer vars before relating so the assertion that const param ty's are sees two different infer vars instead of the resolved ones.
Change:
llvm::LLVMAddGlobal(cx.llmod, llty.to_ref(), name) }); llvm::LLVMSetInitializer(gv, cv); <del> llvm::LLVMSetGlobalConstant(gv, True); </del> <ins> llvm::LLVMSetGlobalConstant(gv, if store == ast::ExprVstoreMutSlice { False } else { True }); </ins> SetLinkage(gv, PrivateLinkage); let p = const_ptrcast(cx, gv, llunitty); (C_struct([p, C_uint(cx, es.len())], false), false)

Discussion:
This line in my project currently causes an unimplemented expression error, told me to submit an issue
Change:
| DefKind::TraitAlias | DefKind::AssocTy | DefKind::TyParam <ins> | DefKind::ConstParam </ins> | DefKind::Fn | DefKind::Const | DefKind::Static(_)

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:
if let Ok(snippet) = self.sess.source_map().span_to_snippet(data.span) { // Do not suggest going from `Trait()` to `Trait<>` if data.inputs.len() > 0 { <del> let split = snippet.find('(').unwrap(); let trait_name = &snippet[0..split]; let args = &snippet[split + 1 .. snippet.len() - 1]; err.span_suggestion( data.span, "use angle brackets instead", format!("{}<{}>", trait_name, args), Applicability::MaybeIncorrect, ); </del> <ins> if let Some(split) = snippet.find('(') { let trait_name = &snippet[0..split]; let args = &snippet[split + 1 .. snippet.len() - 1]; err.span_suggestion( data.span, "use angle brackets instead", format!("{}<{}>", trait_name, args), Applicability::MaybeIncorrect, ); } </ins> } }; err.emit();

Discussion:
The following rust code crashes . (Note, changing to fixes the crash.) Running with RUSTBACKTRACE, I get the following error message. yields Thank you.
I reduced the proc macro to the following: with tokens being:
panic due to not found inside snippet while trying to suggest to . cc
triage: P-high. Removing I-nominated.
Change:
} } <ins> fn is_array_like_block(&mut self) -> bool { self.look_ahead(1, |t| matches!(t.kind, TokenKind::Ident(..) | TokenKind::Literal(_))) && self.look_ahead(2, |t| t == &token::Comma) && self.look_ahead(3, |t| t.can_begin_expr()) } /// Emits a suggestion if it looks like the user meant an array but /// accidentally used braces, causing the code to be interpreted as a block /// expression. fn maybe_suggest_brackets_instead_of_braces( &mut self, lo: Span, attrs: AttrVec, ) -> Option<P<Expr>> { let mut snapshot = self.clone(); match snapshot.parse_array_or_repeat_expr(attrs, token::Brace) { Ok(arr) => { let hi = snapshot.prev_token.span; self.struct_span_err( arr.span, "this code is interpreted as a block expression, not an array", ) .multipart_suggestion( "try using [] instead of {}", vec![(lo, "[".to_owned()), (hi, "]".to_owned())], Applicability::MaybeIncorrect, ) .note("to define an array, one would use square brackets instead of curly braces") .emit(); *self = snapshot; Some(self.mk_expr_err(arr.span)) } Err(mut e) => { e.cancel(); None } } } </ins> /// Parses a block or unsafe block. pub(super) fn parse_block_expr( &mut self,

Discussion:
I ended up spending way too much time debugging the following error, since I was trying to port some C code to rust. Give the error: The error message is very vague and hard to determine the actual error here. Seeing as though some programming languages like Java and C use for arrays, I think it'd make sense for the compiler to suggest using if the user is trying to create an array. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I suppose adding manual diagnostic somewhere around will get the job done. claim
Change:
/// let x: Result<u32, &str> = Err("emergency failure"); /// x.unwrap(); // panics with `emergency failure` /// ``` <del> #[inline] </del> <ins> #[inline(always)] </ins> #[track_caller] #[stable(feature = "rust1", since = "1.0.0")] pub fn unwrap(self) -> T

Discussion:
If compiling with we fail to remove bounds checks and panicking branches in code like this (godbolt ): Unfortunately, while all manage to remove the panic branches, does not, leading to a lot more code and significantly worse performance. Note that we do manage to remove it in cases where the function does less stuff -- it's removed entirely in simple examples that do nothing other than load the value from a slice. However, in real code, (perhaps after a layer of inlining) you tend to have a couple of these in a function, and this issue seems to crop up again[^1]. [^1]: Although not 100% reliably -- having trouble reproducing on godbolt, but it seems like it's happening in real-world code. Given that this pattern is more or less the recommended "safe" way to read a u32 out of a &[u8], this seems unfortunate to me.
I see two problems here: looks like the isn't inlined, and the check part of an unwrap probably always should be -- looking at the discriminant of a Result/Option is trivial, and would probably optimize out enough to be worth doing even in , with just the part of triggering the panic outlined. need better methods for getting arrays out of slices. For example, writing this with and () from , instead of the manual length check, makes it work.
Is there a reason to assume would optimize better than ? It isn't clear to me why this would be. Edit: Ah, there's a godbolt link. Note that this kind of indexing is extremely common in certain code (including commonly used functions like hash implementations), and isn't always as simple as the example (which is just first/last). It would be better if we could just do better in opt-level=z. Even opt-level=1 gets this right.
If there's an in both, then no, I'm not super-confident in it. But if it can be rephrased to not need the unwrap at all -- replacing the length check that needs deduping with the -- then yes, I'd expect it to work better. Have you perchance looked at ? I don't really know what the difference is between and for us or for LLVM, but it also wouldn't surprise me if is incredibly unwilling to inline stuff.
Yes -Os is fine (I mentioned as much above).

The only two opt-levels with issues here are 0 (which is expected) and z (which is not). Note that in practice using if-let is viable for this version of the function, but it usually is not viable for this pattern.
is now , which appears to resolve this. It internally uses a call to , which is not inlined, to keep from exploding the size from inlining the discriminant check.
Change:
}); // Convert the regions 'a, 'b, 'c defined on the trait into <del> // bound regions on the fn. let rps_from_trait = trait_ty_generics.region_param_defs.iter().map(|d| { ty::ReLateBound(m.fty.sig.binder_id, ty::BrNamed(d.def_id, d.ident)) }).collect(); </del> <ins> // bound regions on the fn. Note that because these appear in the // bound for `Self` they must be early bound. let new_early_region_param_defs = trait_ty_generics.region_param_defs; let rps_from_trait = trait_ty_generics.region_param_defs.iter(). enumerate(). map(|(index,d)| ty::ReEarlyBound(d.def_id.node, index, d.ident)). collect(); </ins> // build up the substitution from <ins> //     'a,'b,'c => 'a,'b,'c </ins> //     A,B,C => A',B',C' //     Self => D' //     D,E,F => E',F',G'

Discussion:
cc I think this is related to . Here's the example code: It errors with:
I just got similar ICE with extern mod. a.rs: b.rs: Building b.rs gives (Yes, I was using .) It worked on rust revision but not on revision .
Another variant: produces:
Seems likely to be related, yes. I'll take a look today. Probably something funky in the handling of static methods. Possibly related to what was trying to address in (though maybe not -- I'm sad to say I ddn't fully understand the problem there, was too caught up in trying to finish with !)
Here's an example relevant to me:
So these examples are a mix of problems, but they are all related to . The only one of these examples I expect to not ICE is the first one. The others don't work because of . The basic problem is that you cannot have a function which has a lifetime parameter that appears in a trait bound (yet -- I want to fix this, see for details). Interestingly, the reason that we have this problem with the first example, is that static functions like get translated into functions with lifetime parameters that appear within a trait bound. That is, the type for looks to the compiler like: You can see here that appears in the bound for . Anyway, I have the fix for this. This is good because it got me thinking about and I think it's not too hard to extend the fix to cover that case as well. But I'll push the limited fix for just this bug for now.
Thanks for looking into this. I started playing around with your branch to fix this and I ran into another ICE. Is there something new, or is it also caused by ? Errors with:
On Sat, Nov 16, 2013 at 10:01:08PM -0800, Erick Tryzelaar wrote: . I will see how quickly I can prepare a fix for this. The key identifying point is: right here (I a comment)
Change:
<ins> // check-pass trait Base<'f> { type Assoc; fn do_something(&self); } trait ForAnyLifetime: for<'f> Base<'f> {} impl<T> ForAnyLifetime for T where T: for<'f> Base<'f> {} trait CanBeDynamic: ForAnyLifetime + for<'f> Base<'f, Assoc = ()> {} fn foo(a: &dyn CanBeDynamic) { a.do_something(); } struct S; impl<'a> Base<'a> for S { type Assoc = (); fn do_something(&self) {} } impl CanBeDynamic for S {} fn main() { let s = S; foo(&s); } </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. --: This is also present in beta and nightly versions, but it is not present on 1.55.0 stable. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
56.0 is released on stable, and it ICEs there as well. label regression-from-stable-to-stable
Bisection led to nightly-2021-07-26. Automatic commit bisection failed. Manual commit bisection: Regression comes from .
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Oops. Sorry for creating this ICE. I haven't really dig into this issue yet, but from the description, it seems this ICE comes from where the equality should be within a certain call, but didn't because of the HRTB region. This inequality is because the two parameters comes from two different routes. The first comes from iterator, which is called from The second comes from generator, which lived in , i think the call is the real difference here. This is my current theory, and i'll try to validate it with debugging rustc this week. I'm not totally sure what's the best way to fix this. I think maybe could give me some advice dealing with HRTBs here?
By the way, i've printed out the contents of the vtable for :
Should it just use ? Or I guess it needs the too... Hmm, probably since this is around codegen, we need to erase regions in both trait refs. But, I'd like to see what the two trait refs are.
is and is So... They're the same with , but inequal? I'm a little confused... So i switched to use , and they're a little different: is and is Complete diagnostics output:
This could "just" be fixed by anonymizing both trait refs.

The here is not the same as here . I have to remember how we deduplicate these predicates elsewhere.
Created for erasing regions before comparison. Let me know if there's a more proper approach, and i'll update the pr accordingly.
Anyone think this needs a backport?
Change:
<ins> // issue#126516 // issue#126647 fn main() { const { #![path = foo!()] //~^ ERROR: cannot find macro `foo` in this scope } } </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
bisects to cc
That's a revert, the issue probably exists much longer
ah :+1: when I start the bisection at a later point, this goes down to Regression in nightly-2023-11-29 probably ?
Jup, that looks like it
Change:
<del> use rustc_ast::token; </del> use rustc_data_structures::sync::{Lock, Lrc}; use rustc_errors::{emitter::Emitter, Applicability, Diagnostic, Handler}; <del> use rustc_parse::lexer::StringReader as Lexer; </del> <ins> use rustc_parse::parse_stream_from_source_str; </ins> use rustc_session::parse::ParseSess; use rustc_span::source_map::{FilePathMapping, SourceMap}; use rustc_span::{FileName, InnerSpan};

Discussion:
In , we would like to tweak the structure of the tokens rustc uses. One of the components which heavily depends on the current structure is ( and module use ). I think, for this issue and in general, it makes sense to switch over to , which produces lower-level guaranteed lossless tokens, which look like a better fit for the task of syntax highlighting. I plan to do this refactor myself, but I want to check with if this is a good idea. EDIT: cc
sgtm
I'm fine with it as well. :)
BTW, is there some chat room for rustdoc team on zulip on discord? I'd like to ask some questions :)
There is one on discord (simply called "rustdoc").
It's linked at (which is I agree pretty hard to find). Also the text there is wrong and mentions , we should probably fix that.
Change:
| LL | trait T { | ^^^^^ expected identifier, found keyword <del> | help: you can escape reserved keywords to use them as identifiers | LL | r#trait T { | ^^^^^^^ </del> error: expected `:`, found `T` --> $DIR/missing-close-brace-in-struct.rs:4:7

Discussion:
Right now the raw ident suggestion when using a reserved keyword somewhere where it is not allowed is context free, leading to misleading output: The parser should perform some lookahead to see if it could actually continue parsing if a raw identifier had been supplied in its place and if so, only then suggest raw idents.
Or we shouldn't suggest using raw identifiers if we cannot do that easily and reliably.
Change:
self = r.print(self)?; } <ins> ty::Alias(ty::Inherent, _) => bug!("symbol_names: unexpected inherent projection"), </ins> ty::GeneratorWitness(_) => bug!("symbol_names: unexpected `GeneratorWitness`"), ty::GeneratorWitnessMIR(..) => bug!("symbol_names: unexpected `GeneratorWitnessMIR`"), }

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 cc
claim
another one `

<!-- 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 cc
Thanks :) claim
Change:
if return_span != borrow_span { err.span_label(borrow_span, note); <ins> let tcx = self.infcx.tcx; let ty_params = ty::List::empty(); let return_ty = self.regioncx.universal_regions().unnormalized_output_ty; let return_ty = tcx.erase_regions(return_ty); // to avoid panics if !return_ty.has_infer_types() { if let Some(iter_trait) = tcx.get_diagnostic_item(sym::Iterator) { if tcx.type_implements_trait((iter_trait, return_ty, ty_params, self.param_env)) { if let Ok(snippet) = tcx.sess.source_map().span_to_snippet(return_span) { err.span_suggestion_hidden( return_span, "use `.collect()` to allocate the iterator", format!("{}{}", snippet, ".collect::<Vec<_>>()"), Applicability::MaybeIncorrect, ); } } } } </ins> } Some(err)

Discussion:
Given a situation where an iterator is : We should suggest using in these cases. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Or flatten/flat_map?
I want for us to detect cases of trying to operate on iterators of iterators because the only option then is to allocate or completely rework the logic. The former will help newcomers, experts will know enough to try the later.
claim
Couldn't we still recommend both? Recommending bad practices seems suboptimal.
Change:
<ins> fn main() { let value = [7u8]; while Some(0) = value.get(0) { //~ ERROR mismatched types //~^ NOTE expected `bool`, found `()` //~| HELP you might have meant to use pattern matching } } </ins>

Discussion:
I thought this code would provide one of the nice suggestions that implemented in , but it doesn't. (By the way, making a reference to will give an ICE because of .) () Errors:
Reopening as per
This is fixed in beta now: It is still quite verbose (too many errors), but we lead people in the right direction.

: <details<summary<strongBacktrace</strong</summary<p</p</details
Regressed in
Cc
Related: this code should probably have a suggestion for (): Currently it produces:
Minimized (): I think this might be caused by the lifetimes.
Never mind! This causes it too, with no lifetimes (): EDIT: removed the type aliases EDIT 2: changed to to make it clearer that they don't need to be the same type EDIT 3: shortened names, removed comment
Assigning and removing as .20.3D.20.2E.2E.2E.60.20expression.E2.80.A6) in the prioritization working group.
Further minimized to this (): Having be a or produces the ICE, but making it an owned does not produce the ICE.
causes the operands to be typechecked twice: I think this has side effects that are causing problems by being applied twice. Commenting out the second makes the ICE go away, but I'm not sure what the best approach for a proper fix is. The effect on the UI suite is rather low: (It still emits this error:)
I tried a couple of things but it seems to me that you hit the nail in the head and we just need to remove the branch. this is caused because one side is seen to be while the other is seen to be or (depending on the case). This is a problem because the left hand side expression should in reality be a pattern instead, but there's no utility to build a pattern from an expression: patterns are built during parsing (due to differences like, being a valid thing there). Because of that it'll be very hard to make the suggestion happen for those cases, much harder than for the ones we already handle.
I think I just found a smaller example (granted, it's not valid code any more, but how is one supposed to know that in case of ICE? ;-) ): (If that's not the same error I'm happy to open a new ICE issue, but to me it looks the same, with all the , the panic at and the conditional destructuring in a loop).