jiebi/CodeConvo huggingface dataset:
Change:
} } ty::Closure(closure_def_id, args) => { <del> let trait_closure_kind = tcx.fn_trait_kind_from_def_id(trait_id).unwrap(); Some(Instance::resolve_closure( tcx, closure_def_id, args, trait_closure_kind, )) </del> <ins> Some(Instance::resolve_closure(tcx, closure_def_id, args, target_kind)) </ins> } ty::FnDef(..) | ty::FnPtr(..) => Some(Instance { def: ty::InstanceDef::FnPtrShim(trait_item_id, rcvr_args.type_at(0)),

Discussion:
Importantly note that the closure passed to foo is ; does not ICE. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Regression in ()
Change:
<ins> error: macros that expand to items must be delimited with braces or followed by a semicolon --> $DIR/issue-118786.rs:7:22 | LL |         macro_rules! $macro_name { |                      ^^^^^^^^^^^ | help: change the delimiters to curly braces | LL |         macro_rules! {} { |                      ~          + help: add a semicolon | LL |         macro_rules! $macro_name; { |                                 + error: macro expansion ignores token `{` and any following --> $DIR/issue-118786.rs:7:34 | LL |         macro_rules! $macro_name { |                                  ^ ... LL | make_macro!((meow)); | ------------------- caused by the macro expansion here | = note: the usage of `make_macro!` is likely invalid in item context error: cannot find macro `macro_rules` in this scope --> $DIR/issue-118786.rs:7:9 | LL |         macro_rules! $macro_name { |         ^^^^^^^^^^^ ... LL | make_macro!((meow)); | ------------------- in this macro invocation | note: maybe you have forgotten to define a name for this `macro_rules!` --> $DIR/issue-118786.rs:7:9 | LL |         macro_rules! $macro_name { |         ^^^^^^^^^^^ ... LL | make_macro!((meow)); | ------------------- in this macro invocation = note: this error originates in the macro `make_macro` (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to 3 previous errors </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. --: The problem seems to be this: But it looks like rustc already gets the span wrong: !
<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p<!-- Include a backtrace in the code block by setting in your environment. E.g. RU &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;/detailsSTBACKTRACE=1 cargo build. --<details<summary<strongBacktrace</strong</summary<p</p</details</p</details
This appears to stem from the span for the delimited block being changed . I will work on a fix now and submit it.
Change:
if (go_to_first || (results.others.length === 1 && getSettingValue("go-to-only-result") === "true") ) { <ins> // Needed to force re-execution of JS when coming back to a page. Let's take this // scenario as example: // // 1. You have the "Directly go to item in search if there is only one result" option //    enabled. // 2. You make a search which results only one result, leading you automatically to //    this result. // 3. You go back to previous page. // // Now, without the call below, the JS will not be re-executed and the previous state // will be used, starting search again since the search input is not empty, leading you // back to the previous page again. window.onunload = () => {}; searchState.removeQueryParameters(); </ins> const elem = document.createElement("a"); elem.href = results.others[0].href; removeClass(elem, "active");

Discussion:
Reproduction: Go to Click the gear next to the search field, enable "Directly go to item in search if there is only one result" Refresh page to ensure it's enabled (was required the first time I tried to reproduce, but seemed to work straight away the second time) Search for You should be taken straight to Press "Back" in your browser I expected this to happen: Go back to Instead, this happened: Goes back to then instantly redirects forward again
Taking a look.
Fixed in
Change:
location: Location) { // Handle activations match self.activation_map.get(&location) { <del> Some(&activated) => { debug!("activating borrow {:?}", activated); sets.gen(&ReserveOrActivateIndex::active(activated)) </del> <ins> Some(activations) => { for activated in activations { debug!("activating borrow {:?}", activated); sets.gen(&ReserveOrActivateIndex::active(*activated)) } </ins> } None => {} }

Discussion:
This program : See also , which I believe to be relevant. I'm refactoring some of this code, trying to explore the new NLL approach, so I will probably wind up fixing this. But obviously we should have this as a test! cc
Is this similar to this ICE?
Change:
#[stable(feature = "manually_drop", since = "1.20.0")] #[lang = "manually_drop"] #[derive(Copy, Clone, Debug, Default, PartialEq, Eq, PartialOrd, Ord, Hash)] <del> pub struct ManuallyDrop<T> { </del> <ins> #[repr(transparent)] pub struct ManuallyDrop<T: ?Sized> { </ins> value: T, }

Discussion:
currently requires . It would be nice if we could remove this restriction. I'm not sure how to do it with the current implementation using though.
Doesn't seem possible until we get by-value DSTs
care to explain why?
Ah, nevermind. It would just need to make unsized, too.
The and methods can keep could keep their bounds, we just need to relax the bound on the struct itself, and make sure . Then the following code would be possible:
I guess this would be possible by allowing types to be when there is only one variant. I was worried that would be unsound, but then I realized, the only way to create a DST type would be from an unsize coercion, and then way you know what the erased type is and can get the vtable/slice length then, just like any other unsize coercion.
See
Change:
use rustc_infer::traits::ObligationCause; use rustc_middle::infer::unify_key::{ConstVariableOrigin, ConstVariableOriginKind}; use rustc_middle::middle::stability::AllowUnstable; <ins> use rustc_middle::ty::fold::FnMutDelegate; </ins> use rustc_middle::ty::subst::{self, GenericArgKind, InternalSubsts, SubstsRef}; use rustc_middle::ty::DynKind; use rustc_middle::ty::GenericParamDefKind;

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 --
searched nightlies: from nightly-2023-02-17 to nightly-2023-03-18 regressed nightly: nightly-2023-02-21 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: </details
cc is this fixed by your branch?
No, it's not. The stacktrace does indeed contain but that's not the root cause of the problem. It just calls which ices (changing it to doesn't help either). The actual (?) bug is probably inside of the code I assume.
Ah, wait. If it's a bug to pass s to the type relating functions then it is the fault of and it should probably return early if a type . Edit: But it that case?
Hm, actually I think we should just fix the relate code instead.
Sure. I also feel like I've seen this ICE message pop up several times already on this issue tracker. I might be mistaken tho.
More minimal:
Reassigning to myself since the approach involving region erasure during selection we talked about fixes this issue (obviously) and since I'd like to integrate this into my PR to be able to write UI tests that exercise the bound region code used during IAT confirmation (otherwise we would never go past selection in those cases). claim label F-inherentassociatedtypes
Change:
<ins> // check-pass #![allow(unused)] trait Foo { type Bar; type Baz: Bar<Self::Bar>; } trait Bar<T> {} fn x<T: Foo<Bar = U>, U>(t: &T) {} fn main() {} </ins>

Discussion:
The trait system seems to be missing a normalization in bounds for associated items: produces the error:
cc
Note that this version works: (Removing the )
, which compiles.
This now compiles.

Gives me: There is a workaround: But it's ugly and should not be necessary. We hit this problem a lot with , and I'd like to see cleaner use of it without explicit bounds that we use as a .
This may be related to .
Edited original post to remove bounds, they're no longer needed. Issue still reproduces:
A lot of related issues for this have been opened over time. Duplicates: , , , , , Probably same underlying cause: , , , , , There's also a related discussion on the Rust forums:
Mildly simplified: So, probably the fix is "just" that we need to do some normalization somewhere or other. My preference is to fix this by moving over to lazy normalization and chalk, which will do away with these sorts of shortcomings for good. But it's probably worth looking to see if this can be fixed a touch more rapidly by adding a normalization in the right place. I'll try to do that in a bit and mentor/open a fix if it seems reasonable.
Any progress here
Looks like the issue is known and mentioned at this line: This indicates this may be the area to check in when working on this? Still working on understanding a lot of this code, so I'm not sure.
Ran into this as well. Here's my minimal test case:
I've just run into this issue in one of my own projects, and reduced it to a test case that's even simpler than the last one: Although it compiles successfully if you add the bizarrely-tautological-looking . For now, I'm stuck with adding the where clause, but that's putting a LOT of boilerplate in my code (the actual where clause is 71 characters long and appears in dozens of places, including being de-facto required in code that uses my library, not just inside the library itself). Is there any progress on this?
: makes the code compile. Edit: updated output: : : Update: this case now compiles. In call cases applying the suggestions fulfill the requirements.
any update on this? Is there anything I can do help with this? I'd be happy and try to help where I can, as this is blocking a lot of nice usages of for me at the moment.
It looks like this compiles under , or at least the bounds compile.

The body function complains about inference, but I'm inclined to think that's just a chalk bug / missing feature and unrelated to this issue. Given that, the solution might just be fully stable chalk integration. If it is, then this issue would fall into the same bucket as features like , where there isn't a lot we can do outside of just pushing chalk integration.
I think my is still correct. I think the normalizing is missing here: After we invoke , we should also be normalizing, probably kind of like this If Chalk solves this, it is probably because of lazy normalization.
All of now compile. I believe this can be closed by adding tests.
Change:
debug!(?concrete_type, ?substs); let mut subst_regions = vec![self.universal_regions.fr_static]; <del> let universal_substs = infcx.tcx.fold_regions(substs, &mut false, |region, _| match *region { ty::ReVar(vid) => { subst_regions.push(vid); self.definitions[vid].external_name.unwrap_or_else(|| { infcx.tcx.sess.delay_span_bug( span, "opaque type with non-universal region substs", ); infcx.tcx.lifetimes.re_static }) } // We don't fold regions in the predicates of opaque // types to `ReVar`s. This means that in a case like // // fn f<'a: 'a>() -> impl Iterator<Item = impl Sized> // // The inner opaque type has `'static` in its substs. ty::ReStatic => region, _ => { infcx.tcx.sess.delay_span_bug( span, &format!("unexpected concrete region in borrowck: {:?}", region), ); region } }); </del> <ins> let universal_substs = infcx.tcx.fold_regions(substs, &mut false, |region, _| { let vid = self.universal_regions.to_region_vid(region); subst_regions.push(vid); self.definitions[vid].external_name.unwrap_or_else(|| { infcx .tcx .sess .delay_span_bug(span, "opaque type with non-universal region substs"); infcx.tcx.lifetimes.re_static }) }); </ins> subst_regions.sort(); subst_regions.dedup();

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. --Minimized: also occurs for but not <!-- 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. --: also on Rust Playground <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Somehow I missed that this does not require async. Also crashes with and returning .
minimized:
-- the minimization no longer ICEs for me
-- this sure looks like a dup of
After a discussion with Niko about this and assigning to myself we saw that there's already a PR. Unassigning myself then :).
Change:
self.span.hi ); if attr.node.style != ast::AttrStyle::Outer { <del> return Err(self.fatal("expected outer comment")); </del> <ins> let mut err = self.fatal("expected outer doc comment"); err.note("inner doc comments like this (starting with  `//!` or `/*!`) can only appear before items"); return Err(err); </ins> } attrs.push(attr); self.bump();

Discussion:
This piece of code fails compilation (): This is because the compiler expects inner comments only before the first item (something like ). It doesn't point this out however, instead, it gives the rather cryptic error message: It should say something like "Please place the inner comment to the top". From reading the code, an error message like would be sufficient. Can that be achieved by changing the if near line 38: to something like ? I haven't tested because I haven't set up a development setup of rustc (and don't know whether there is a better way to do it).
It was suggested on irc to cc about this because its a bad error.
Change:
/// Panics if the buffer is not large enough. /// A buffer of length four is large enough to encode any `char`. #[unstable(feature = "char_internals", reason = "exposed only for libstd", issue = "none")] <del> #[rustc_const_unstable(feature = "const_char_encode_utf8", issue = "130512")] </del> <ins> #[rustc_const_stable(feature = "const_char_encode_utf8", since = "CURRENT_RUSTC_VERSION")] </ins> #[doc(hidden)] #[inline] <ins> #[rustc_allow_const_fn_unstable(const_eval_select)] #[cfg_attr(bootstrap, rustc_allow_const_fn_unstable(const_mut_refs))] </ins> pub const fn encode_utf8_raw(code: u32, dst: &mut [u8]) -> &mut [u8] { const fn panic_at_const(_code: u32, _len: usize, _dst_len: usize) { // Note that we cannot format in constant expressions.

Discussion:
Feature gate: This is a tracking issue for supporting in const scenarios. [x] Implementation: [x] Address diagnostics: [x] Final comment period (FCP) [x] Stabilization PRNone yet.
fcp merge for
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [ ] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
I'll note that in the , making this const seems to require making the panic error message worse (even in the case where isn't used in a context) and also introducing more uses of . I'm not especially happy about that.
The use of unsafe code cannot be avoided as long as slice indexes aren't const-friendly (AFAIK). But I would argue that this use is properly documented and (relatively) invulnerable to UB, although I am open to other views on this. has also noted that could be used to regain full diagnostics in non-const calls – a feature which I would be more than happy trying to implement.
We could have a safe "const fn subslice" that does the bounds check and then uses unsafe fromrawparts. That would avoid introducing new unsafe reasoning in encode_utf8 itself.
resolves the diagnostics question. Can this be without conflicting with the FCP?
Yeah that should be fine. Thank you! I appreciate that. :-)
Plesse add a FIXME(const-hack) next to the const-eval-select to document that it should be removed again in the future, when possible.
Done. :)
:bell: This is now entering its final comment period, as per the . :bell:
Am I supposed to draft a stabilisation PR or is that outside my domain?
If you want to then yes you can draft a stabilization PR. :) Please link it to this issue and mention that it must only land once FCP has completed.
stabilises this.
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon.
Change:
//~^ ERROR where clauses on associated types are unstable } <ins> impl Bar for Foo { type Assoc where Self: Sized = Foo; //~^ ERROR where clauses on associated types are unstable } </ins> fn main() {}

Discussion:
Compiling this code results in no output by . But exits with 101 and does not produce any artifacts. () The error happens with: , , and -
If I set breakpoints on - It hits the first two but not the third, seemingly pointing to returning an .
The silent exit is a regression. From godbolt, #### 1.23.0 exit code = 101 #### 1.24.0–1.25.0 exit code = 101 #### 1.26.0–1.28.0(beta) No message, exit code = 101 #### 1.29.0(nightly) No message, exit code = 1
cc -- it'd be good to find out why we stopped providing any output at all here
I'm worried it might be one of my parser changes to provide better diagnostics... I would probably check for any odd looking .
It's not the parsing itself, it's that in 1.24 the feature was introduced:
do you think you see what the problem is?
Calling P-high but we don't yet have an obvious assignee. Still, seems bad that there is no diagnostic output at all! Not a good look.
The core issue is reported in However, the example here also demonstrates that clauses aren't being feature gated properly.
I've made to address the surface problem, which is that you can trigger this on stable, without declaring the feature. I thought it was better to fix that part of the problem straight away.
Narrowing it down a little more: is at this point when the clauses are defined, so something's going wrong before that point.
Change:
| = note: expected reference `&S` found reference `&R` <ins> help: consider using a semicolon here, but this will discard any values in the match arms | LL |     }; |      + </ins> error[E0038]: the trait `Trait` cannot be made into an object --> $DIR/wf-unsafe-trait-obj-match.rs:26:21

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:
match mode { Mode::Std => { self.clear_if_dirty(&my_out, &self.rustc(compiler)); <ins> for backend in self.codegen_backends(compiler) { self.clear_if_dirty(&my_out, &backend); } </ins> }, Mode::Test => { self.clear_if_dirty(&my_out, &libstd_stamp);

Discussion:
At the very least, the tests don't appear to be re-checked. It's possible is also not rebuilt.
Change:
<ins> #![crate_name = "foo"] // @has 'foo/type.Resolutions.html' // @has - '//*[@class="rust typedef"]' "pub type Resolutions<'tcx> = &'tcx u8;" pub type Resolutions<'tcx> = &'tcx u8; </ins>

Discussion:
It'd be good to minimize this and reproduce this outside of rustc. ! !
This bisects to . Stop looking at me like that! is still a thing! And no, before someone asks, I do not volunteer to do this sort of thing on a regular basis. It took all day. I did other stuff at the same time, but still...
Thank you so much! FYI, using  (with and ) would've probably been a lot faster :)
cc
I guess the issue here is that is erasing the lifetimes (=regions) in the type, hence its name. cc as well
I'm working on it.
I feel very embarrassed. I figured that it wouldn't work, because generally cargo explodes whenever I try to use it on the compiler. I take it would actually work though?
Actually, I think you're right to use . cargo-bisect-rustc doesn't usually work on the compiler Sorry about that!
The underlying principle should work though, by specifying rustc = ... in pointing to a rustup-toolchain-install-master'd binary (and potentially cargo = and/or rustdoc =).
Change:
<ins> error[E0067]: invalid left-hand side of assignment --> $DIR/assign-non-lval-needs-deref.rs:15:16 | LL |     (&mut Foo) += (); |     ---------- ^^ |     | |     cannot assign to this expression | help: consider dereferencing the left-hand side of this operation | LL |     *(&mut Foo) += (); |     + error: aborting due to previous error For more information about this error, try `rustc --explain E0067`. </ins>

Discussion:
: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
(update, I've reproduced it on smaller example)
Error -ICE regression in 1.63 label regression-from-stable-to-stable
searched nightlies: from nightly-2022-05-01 to nightly-2022-07-01 regressed nightly: nightly-2022-05-19 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsRegresses in rollup , most likely , cc
claim