jiebi/CodeConvo huggingface dataset:
Change:
<ins> // A regression test for #68653, which was fixed by #68938. // check-pass #![allow(incomplete_features)] #![feature(generic_associated_types)] trait Fun { type F<'a: 'a>; } impl <T> Fun for T { type F<'a> = Self; } fn main() {} </ins>

Discussion:
I wanted to test our handling of slices that are "too big" (bigger than the largest possible allocation), so I wrote: I expected an ICE or so, but I got a timeout. On nightly, here's what a stacktrace looks like: looks like the interning could do with a fast path for integer slices similar to what validation does? And maybe it could also check that the reference is dereferencable before walking it, that would avoid finding out later that we are going to produce an error anyway.
This now finishes in milliseconds with an error:

rustc crashes ungracefully when given the following input (found by ): I'm seeing this behavior on stable, beta, and nightly.
cc
Interesting: I'm not familiar with but that's where we are aborting:
cc
If I change the body of to this: then the compiler aborts how you would expect. I caught the panic in gdb (with ). It is coming from . Here's the stack trace: So it seems like this is a "legitimate" panic from the parser that the compiler would normally catch gracefully somewhere... except that assumes the closure it calls never panics and just aborts immediately if so. 's current implementation arose out of . any thoughts on how could let the panic pass through in a memory-safe manner? Or is that not possible?
I think there’s no magic trick here. Afaik the only safe way to do this is to mem::replace t with a dummy value, apply f, and swap the result back, but that requires that t has a dummy value. Does the code break if you add T: Default bound? Also, when suggesting that change I was 80% sure that it’s pure pedantry because, clearly, we don’t panic anywhere :) I am fascinated by how conspicuous and shallow such “benign” problems become in rust!
cc re:macros/ being ky.
Yes. Unfortunately, lots of the involved types lack a bound, and adding one doesn't make sense. wants the commit that introduced to be reverted anyway. Perhaps that's the best path forward, even though it'll be a perf hit. If I'd stuck with the original code that didn't handle panics it would have been a double-free without warning. One of those " is trickier than you might think" moments.
Or we just accept the current behaviour, because it's a benign abort on a very obscure case, and is being phased out anyway...
What's the plan post-? Benign to , but it will kill RLS or any other long lived tool. (Not that I disagree that we can live with this in the medium term.)
Just in case it's useful: here is a variation that causes (what I assume is) the same abort with only the macro:
I am unable to reproduce this crash on the latest releases. I was curious what fixed it, so I tried bisecting with nightlies.

The crash still happens on but no longer happens on . Unfortunately, it looks like nightlies are not available in between those two. In any case, as far as I'm concerned, this issue may be closed now.
Let's close this with a PR containing these repro cases as regression tests.
Change:
//~^ NOTE macros cannot expand to enum variants //~| ERROR unexpected token: `!` //~| NOTE unexpected token after this <del> Data { </del> <ins> Data { //~ NOTE while parsing this struct </ins> field!(x:u32), //~^ NOTE macros cannot expand to struct fields //~| ERROR unexpected token: `!`

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Regression in nightly-2023-08-05 Regression in cc
This is probably because it recovers from it and gives the field no name. We should probably give it the macro's name instead I believe this is the offending line:
An alternative approach would be to directly throw an error instead of allowing the parser to continue, imo.
label -needs-triage
Change:
fn foo() -> Result<u32, ()> { let x: Option<u32> = None; <del> x?; //~ the trait bound </del> <ins> x?; //~ ERROR `?` couldn't convert the error </ins> Ok(22) } fn bar() -> u32 { let x: Option<u32> = None; <del> x?; //~ the `?` operator </del> <ins> x?; //~ ERROR the `?` operator </ins> 22 }

Discussion:
Currently E277's message is confusing and seemingly ambiguous when it occurs on a try () expression (this may not be limited to E277, it's just the one I noticed). For example, in : The problem is that 's error type is while 's error type is . In this case the error isn't too confusing, but if the try is in a chained expression () and you're a noob it isn't clear why it wants implemented on . It doesn't necessarily even require a whole fix suggestion, all it would take is making the error only highlight the , as the issue is actually occuring when unwrapping the result. Thanks!
Change:
return; } <del> if let Some(stab) = tcx.lookup_stability(did) && stab.is_unstable() && stab.feature == sym::rustc_private { return; </del> <ins> if !tcx.features().rustc_private && !cx.render_options.force_unstable_if_unmarked { if let Some(stab) = tcx.lookup_stability(did) && stab.is_unstable() && stab.feature == sym::rustc_private { return; } </ins> } }

Discussion:
This is a regression from stable to beta, although this issue will be P-low. The problem is ignored documenting unstable traits for non-local types, fixes some regressions caused by it but the regression in nightly-rustc / compiler docs still opens. For example: Compare and . The doc in 1.46.0 has impl, while on nightly it doesn't have. A way to fix this issue is ignoring this check when the compiling-crates are being passed flag or the crate/module has feature: : Version 1.48.0-nightly ( 2020-09-14)
Hey! I would like to check this out if that is okay
Is this actually a regression?
Dropping regression label. nightly-rustc docs are, well, not really important on non-nightly channels, as they cannot be used by normal consumers.
if you're still interested in working on this we'd love to have the help! If you have trouble, feel free to ask for help in or :)
Thanks! Yes, I am still interested, I have been busy that past few weeks. I will give it a shot this weekend and will reach out if I can't figure it out!
Since zulip is lag in my region at night, I post a respond here. You could use to check for flag passed during compilation.
I think I'll hop onto this if that's OK. I've always wanted to contribute :)
Go for it!
It doesn't seem to be fixed by I'll check the cause
Change:
pub use builtin_attrs::AttributeDuplicates; pub use builtin_attrs::{ deprecated_attributes, find_gated_cfg, is_builtin_attr_name, is_builtin_only_local, <del> AttributeGate, AttributeTemplate, AttributeType, BuiltinAttribute, GatedCfg, BUILTIN_ATTRIBUTES, BUILTIN_ATTRIBUTE_MAP, </del> <ins> is_valid_for_get_attr, AttributeGate, AttributeTemplate, AttributeType, BuiltinAttribute, GatedCfg, BUILTIN_ATTRIBUTES, BUILTIN_ATTRIBUTE_MAP, </ins> }; pub use removed::{REMOVED_FEATURES, STABLE_REMOVED_FEATURES};

Discussion:
currently happily ignores any additional attributes in case there are more than one. While this is fine for attributes which don't care about duplicates or emit a warning/error in case there are more than one, this isn't currently checked in the compiler, potentially causing bugs. similar to the check in we should check that the attr declaration in has an acceptable way of dealing with duplicates. in case there are any questions on how to implement this, feel free to open a thread on zulip and pinging me there. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
| PatKind::Path(..) | PatKind::Struct(..) | PatKind::Tuple(..) => { <del> // If the PatKind is a TupleStruct, Struct or Tuple then we want to check </del> <ins> // If the PatKind is a TupleStruct, Path, Struct or Tuple then we want to check </ins> // whether the Variant is a MultiVariant or a SingleVariant. We only want // to borrow discr if it is a MultiVariant. // If it is a SingleVariant and creates a binding we will handle that when // this callback gets called again. <del> if let ty::Adt(def, _) = place.place.base_ty.kind() { </del> <ins> // Get the type of the Place after all projections have been applied let place_ty = place.place.ty(); if let ty::Adt(def, _) = place_ty.kind() { </ins> if def.variants.len() > 1 { needs_to_be_read = true; }

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. --Nightly only, since it depends on the feature gate. Without the feature gate, the code compiles without an ICE. is the first nightly with the ICE. Still occurs on the latest nightly ( at the time of writing). ICE still occurs when is substituted with , e.g. <!-- 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
cc
can you take a look please
I started looking into the issue and I think it spans from failing to resolve the upvars when the feature is enabled: fails which leads to the field of the Candidate to not be assigned as the assignment of this field is being done
The underlying issue is that currently the compiler does not realize, for the above example, that the discriminant should be read. We incorrectly assumed that would only be of type when they could be of other types like we should be looking at the when we actually want to look at Working on a fix
Change:
// Typecheck each field. for field in ast_fields { <del> let final_field_type; let field_type_hint; </del> let ident = tcx.adjust(field.name.node, variant.did, self.body_id).0; <del> if let Some(v_field) = remaining_fields.remove(&ident) { final_field_type = self.field_ty(field.span, v_field, substs); field_type_hint = self.field_ty(field.span, v_field, hint_substs); </del> <ins> let field_type = if let Some(v_field) = remaining_fields.remove(&ident) { </ins> seen_fields.insert(field.name.node, field.span); // we don't look at stability attributes on

Discussion:
fails to type check, while succeeds.
This coercion is important when using byte string literals.
The tuple struct case is actually the function call "expected type" propagation, which would have to be adapted to struct literals as well.
Yes.
Coercion already happens in non-generic struct literals:
Yes, but the field types are taken from the struct and not combined with the overall expected type for the struct literal.
I just discovered this bug/unexpected behavior today (). I would like to see some movement on it because it's surprising that these two don't work the same way. Here's a workaround I found; it's ugly as hell but I'm using it in a generated file that no human would want to look through anyway: I tried type ascription but it seems to not cue coercion, it just moves the type error: It seems that forcing a concrete type on the struct literal works as well (I didn't expect this syntax to work, honestly): Unfortunately this won't work for me because I'm using too and I can't add this extra syntax myself.
Any news on this?
Is anyone working on it?
It seems like implemented a partial fix in but suggests that there are backwards incompatibility issues to be considered that preventing him from going further. I'm not quite sure what he had in mind there, perhaps he can elaborate.
Making sure we remember to look at this.
What I did is I computed a "light hint" (which becomes "strong hint", i.e. forcing coercion, if it reaches a block, and it's enough to help integer inference for ). This is a common problem with coercion hints, in that unless there's enough type information to prevent them from triggering, they will trigger early even if that breaks later on. The thing to try here is to replace with the simpler: doesn't even need to be computed if that works, since is at least as specific - AFAICT, we already have that "specificity" with function calls, but since it hasn't been used with struct literals before, crater/cargobomb might reveal regressions.
ok, I was mostly wondering if you encountered actual regressions in practice, or just theorize that this might lead to problems.
I don't think I got the chance to do a crater run and then I lost track of it.
will open a PR and we can try a crater run at least.

There is still a similar problem with the type inference of temporaries when you have an array that should be interpreted as a slice buried in a tuple inside an outer slice.
Change:
Some(next) => next, None => break None, }; <ins> // See issue #83753. If someone writes an associated type on a non-trait, just treat it as // there being no supertrait HRTBs. match tcx.def_kind(def_id) { DefKind::Trait | DefKind::TraitAlias | DefKind::Impl => {} _ => break None, } </ins> if trait_defines_associated_type_named(def_id) { break Some(bound_vars.into_iter().collect()); }

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
From
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-medium
Change:
<ins> // https://github.com/rust-lang/rust/issues/82446 // Spurious 'help: store this in the heap' regression test trait MyTrait {} struct Foo { val: Box<dyn MyTrait> } fn make_it(val: &Box<dyn MyTrait>) { Foo { val //~ ERROR [E0308] }; } fn main() {} </ins>

Discussion:
The following code: produces the following error: is a , so writing would produce a . This is very unlikely to be what the user wants - and in this case, it won't even work, since there are no impls for . Tested on <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This problem occurs not only when 's type is , but also i32 and other types. This help message will be emitted if could coerce to . But I think this is weird. This coercion should be based on , and to coerce, we need implementation of for 's type. In other words, it seems that all types have implementation of . This behavior should be incorrect also from . I'm going to check why the compiler provides above implementation.
This suggestion uses to determine whether to emit the message. And then calls . execute trait selection. Even if a type needs implementation, trait selection does not check , . However, also . As a result, does not check whether 's type has implementation of . But, I have no idea how to fix this. I'll leave this issue.
Change:
<ins> error[E0583]: file not found for module `unknown` --> <anon>:1:1 | 1 | mod unknown; | ^^^^^^^^^^^^ | = help: to create the module `unknown`, create file "unknown.rs" or "unknown/mod.rs" error: aborting due to previous error For more information about this error, try `rustc --explain E0583`. </ins>

Discussion:
Missing external modules don't report a build error when a crate is built from stdin. Expected: When parsing an external submodule from stdin, a compiler error (or warning) is emitted noting that external submodules are not supported for stdio crates. Actual: No diagnostics are emitted and an empty submodule is implicitly inserted. Generally if a statement references a file which does not exist, an E0583 compile error will be emitted. However, when building a crate from stdin, no relative filesystem is present, yet no compile errors are emitted, even with explicit attributes. Instead they are implicitly substituted with empty inline modules. I'm not super familiar with rustc, so this might not be handy, but I'm guessing this is caused by the flag being unset when parsing from a string rather than a file ( - rather than trying to access the filesystem or emit an error during the parse.
This was fixed in nightly-2020-03-20, probably by I don't think this is worth adding a regression test for this TBH, so I think we should simply close this issue. It remains fixed in current stable (1.71).
On a second thought the right way to close this issue is probably by writing a regression test after all. Otherwise the bug can re-appear. I was being too lazy. Edit: Fix: label E-needs-test
Change:
padding: 2px 4px; box-shadow: 0 0 4px var(--main-background-color); } <ins> .item-table > li > .item-name { width: 33%; } .item-table > li > div { padding-bottom: 5px; word-break: break-all; } </ins> } @media print {

Discussion:
Crates with long type names result in a strange-looking error, see ! I've tested this on Chrome and Firefox, and by building the docs locally from I believe the text is rendering vertically due to long type names like which are auto-generated from OpenAPI. Link to original issue <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The issue is related to the rule which prevents breaking anywhere in the type name. Unfortunately using breaks . We even have a comment about the weird behaviour in the code, not sure how to fix this.
claim
Change:
} fn drop_remaining(&mut self) { <del> if mem::needs_drop::<T>() { unsafe { ptr::drop_in_place(self.as_mut_slice()); } </del> <ins> unsafe { ptr::drop_in_place(self.as_mut_slice()); </ins> } self.ptr = self.end; }

Discussion:
dilbert-feed is ICEing on beta with error: internal compiler error: could not fully normalize https://crater-
Full error log:
I'll bisect this one
Doesn't happen on the latest commit by on .
I can still reproduce with :
It may just be an instance of me not doing something right, I used:
gives me searched toolchains through regression in So this would have regressed in , cc
The PR did introduce some additional uses of inside specialized implementations. itself it is a stable function so I am not aware of any restrictions on its use. Perhaps this is some interaction with specialization?
Both sites where it is used are of this pattern: They're just there as hints to to let llvm DCE the dropinplace earlier. So if needed removing them should be safe.
Assigning as and removing .
Assigning myself to revert on beta (and potentially nightly, depending on if we can get a fix soon).
Do we know if removing fixes the problem? We also could use an MVCE, right?
MCVE would be good, yes.
I hit (what seems like) this ICE with in a pretty small experiment, would it be useful to try reducing that?
Yes, it would be -- even if it's a separate issue we can just open that :) MCVE is always useful.
ping cleanup This issue needs an MVCE
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Here's my nightly MCVE: Interestingly, it goes away when putting all of the code into one crate. <details<summaryFull error message (with <codeRUST_BACKTRACE=1</code):</summary</details
Hmm, this may be a distinct problem, but maybe not. Hard to tell.
I'm re-adding the MCVE label because the crate on beta does not require features, so we should be able to come up with a non-nightly MCVE. (Also, it would be good to have a single-crate MCVE, but perhaps the multicrate nature is critical here?)
cc , which may be the same underlying bug (but pre-existing?)

hey , did you manage to land a revert of on beta (and nightly?)?
If reverting the PR proves difficult more targeted options would be either removing the use of or only removing / stubbing while leaving the rest of the machinery unchanged. But the former may be insufficient since it also uses similar methods such as and .
Do we think given that we're likely to fix the regression here at least in and we should close this bug? Neither of those PRs fixes the underlying issue (whatever it is) since the lack of normalization is almost certainly still present, but we also don't have (AFAIK) a good test case here for the bug.
I expect so.
Change:
if self.regioncx.universal_regions().is_universal_region(r) { Some(r) } else { <del> let upper_bound = self.regioncx.universal_upper_bound(r); </del> <ins> // We just want something nameable, even if it's not // actually an upper bound. let upper_bound = self.regioncx.approx_universal_upper_bound(r); </ins> if self.regioncx.upper_bound_in_region_scc(r, upper_bound) { self.to_error_region_vid(upper_bound)

Discussion:
This code: Returns this error: Which is very unhelpful; it should at least in some way point to the line with the . This happens on rustc 1.40.0 ( 2019-12-16). For reference, this is the equivalent non-async error message (much more helpful): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Marking as focus, since improving diagnostics are important to the wg.
Change:
/// } /// ``` #[stable(feature = "metadata_ext", since = "1.1.0")] <del> #[rustc_deprecated(since = "1.8.0", reason = "deprecated in favor of the accessor  methods of this trait")] </del> <ins> #[rustc_deprecated( since = "1.8.0", reason = "other methods of this trait are now prefered" )] </ins> #[allow(deprecated)] fn as_raw_stat(&self) -> &raw::stat;

Discussion:
returned the containing all the information. Now you should access them via the methods provided by the trait, e.g. ,  etc.
Thanks for explanation. But I think the deprecated message is misleading.
PRs to change the wording would likely be accepted, but nothing better comes to mind right now. It seems pretty straightforward to me what the deprecation means.
Change:
use crate::core::DocContext; use crate::formats::item_type::ItemType; <del> use super::Clean; </del> <ins> use super::{Clean, Visibility}; </ins> type Attrs<'hir> = rustc_middle::ty::Attributes<'hir>;

Discussion:
The trait on 1.49.0 (current stable) doesn't contain modifier in function declaration of that trait. ! However, on and nightly, there is modifier. ! This is wrong because you cannot use modifier for each method/function in Trait definition. Why is this important? People copy the method/function declaration in the documentation to their code and see the compiler error: . : cc I think this might relate to some changes in visibility around macros ? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Yes, this needs the same fix as (in particular should work).
Self-assigning because this is a beta regression.
Note that this also occurs for the impl's docs.
Removed since this was fixed.
, trait methods still rendered as : ! Is there something wrong to Rust release or the bug still exists ?
Hmm, maybe it was only fixed for items in the local crate. do you have time to come up with an MCVE? I expect it's related to cross-crate re-exports.
Your guess sounds right. With core link (), things are normal.
I don't think I'll have time to fix this second part soon, so unassigning myself.
Assigning and removing as in the prioritization working group.
Removing E-mentor + E-easy labels since we don't have guides for cross-crate linking: label -E-easy -E-mentor
I think is the cross-crate case.
Fix backported to 1.50.0 and landed in 1.51.0, closing this.
Please reopen. The issue is not entirely fixed for cross-crate trait reexport case.
The cross-crate issue is now on stable. label: +regression-from-stable-to-stable -regression-from-stable-to-beta
claim