jiebi/CodeConvo huggingface dataset:
Change:
<ins> error[E0046]: not all trait items implemented, missing: `call` --> $DIR/location-insensitive-scopes-issue-116657.rs:18:1 | LL |     fn call(x: Self) -> Self::Output; |     --------------------------------- `call` from trait ... LL | impl<T: PlusOne> Callable for T { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ missing `call` in implementation error: unconstrained opaque type --> $DIR/location-insensitive-scopes-issue-116657.rs:22:19 | LL |     type Output = impl PlusOne; |                   ^^^^^^^^^^^^ | = note: `Output` must be used in combination with a concrete type within the same impl error[E0700]: hidden type for `impl PlusOne` captures lifetime that does not appear in bounds --> $DIR/location-insensitive-scopes-issue-116657.rs:28:5 | LL | fn test<'a>(y: &'a mut i32) -> impl PlusOne { |         --                     ------------ opaque type defined here |         | |         hidden type `<&'a mut i32 as Callable>::Output` captures the lifetime `'a` as defined here LL |     <&mut i32 as Callable>::call(y) |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | help: to declare that `impl PlusOne` captures `'a`, you can add an explicit `'a` lifetime bound | LL | fn test<'a>(y: &'a mut i32) -> impl PlusOne + 'a { |                                             ++++ error: aborting due to 3 previous errors Some errors have detailed explanations: E0046, E0700. For more information about an error, try `rustc --explain E0046`. </ins>

Discussion:
File: reduced: original: Version information Command: Program output:
cc
Some notes dump: the original test fuzzed into this MCVE is . NLLs and do compute the same scopes on that original difference in scopes here is on a somewhat ambiguous case in the current implementation: the loan ultimately flows into via member constraints, not a regular outlives constraint. NLL still computes a scope for it, doesn't since it considers the loan to escape the we ignored the member constraint here and computed the scope anyways, it would result in the same results as NLLs and not trigger the assert. A handful of other tests would then fail of SCC member constraints difference between this test and these other 4 seems to me to be about applied member constraints. That is, in this test the member constraint is likely not applied, so maybe the loan should only be considered to escape via these. We had discussed this very subject before, but thought the distinction didn't matter for the purpose of computing scopes -- maybe we were wrong in these edge cases. That should be a correct fix and should work on these 5 tests. So I'll look into that next.
Change:
<ins> // Copyright 2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #[derive(Debug, PartialEq)] enum Bar { A(i64), B(i32), C, } #[derive(Debug, PartialEq)] struct Foo(Bar, u8); static FOO: [Foo; 2] = [Foo(Bar::C, 0), Foo(Bar::C, 0xFF)]; fn main() { assert_eq!(&FOO[1],  &Foo(Bar::C, 0xFF)); } </ins>

Discussion:
Running this code in either release or debug mode will yield a segfault: It looks like this also runs successfully on stable, just failing on beta/nightly cc
This looks very similar to .
This was introduced between and (). I'm no llvm ir expert, however I believe the following excerpts show the problem: The definition in the case is missing the padding between the slice elements. Edit: Note that this ir was obtained from a slightly modified code, the definition was changed to And the struct changed to Also, some manually edited impl's revealed that (in the modified case) the first is correctly handled as a , however the second is (which then leads to the segfault when trying read the string literal from an invalid address.
The following code reproduces the problem without the segfault: The expected hexdump would be (from the working nightly): The actual hexdump is:
Waiting on backport.
Reopened because this still affects beta.
Backported in , so closing.
Change:
<ins> #![feature(rustc_attrs)] #![feature(transparent_unions)] use std::marker::PhantomData; // Regression test for #115664. We want to ensure that `repr(transparent)` wrappers do not affect // the result of `homogeneous_aggregate`. type Tuple = (f32, f32, f32); struct Zst; #[repr(transparent)] struct Wrapper1<T>(T); #[repr(transparent)] struct Wrapper2<T>((), Zst, T); #[repr(transparent)] struct Wrapper3<T>(T, [u8; 0], PhantomData<u64>); #[repr(transparent)] union WrapperUnion<T: Copy> { nothing: (), something: T, } #[rustc_layout(homogeneous_aggregate)] pub type Test0 = Tuple; //~^ ERROR homogeneous_aggregate: Ok(Homogeneous(Reg { kind: Float, size: Size(4 bytes) })) #[rustc_layout(homogeneous_aggregate)] pub type Test1 = Wrapper1<Tuple>; //~^ ERROR homogeneous_aggregate: Ok(Homogeneous(Reg { kind: Float, size: Size(4 bytes) })) #[rustc_layout(homogeneous_aggregate)] pub type Test2 = Wrapper2<Tuple>; //~^ ERROR homogeneous_aggregate: Ok(Homogeneous(Reg { kind: Float, size: Size(4 bytes) })) #[rustc_layout(homogeneous_aggregate)] pub type Test3 = Wrapper3<Tuple>; //~^ ERROR homogeneous_aggregate: Ok(Homogeneous(Reg { kind: Float, size: Size(4 bytes) })) #[rustc_layout(homogeneous_aggregate)] pub type Test4 = WrapperUnion<Tuple>; //~^ ERROR homogeneous_aggregate: Ok(Homogeneous(Reg { kind: Float, size: Size(4 bytes) })) fn main() {} </ins>

Discussion:
On aarch64-unknown-linux-gnu (a tier 1 target), consider this testcase: passes its argument as uses IOW, uses float registers and uses int registers. This violates our promise that types are ABI-compatible. I think this might indicate a bug in the function? At least I don't see anything in the aarch64 adjustment that would be obviously wrong.
This also affects arm32 targets like arm-unknown-linux-gnueabihf.
Yes, that is definitely the issue -- that is heterogeneous.
Should be fixed by
Change:
<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn works<T>(x: T) -> Vec<T> { vec![x] } fn also_works<T: Clone>(x: T) -> Vec<T> { vec![x] } fn main() { let _: Vec<usize> = works(0); let _: Vec<usize> = also_works(0); let _ = works(0); let _ = also_works(0); } </ins>

Discussion:
cc me.
Triage: Not relevant right now, but this issue should be tested if/when we restore int/float fallback.
Change:
<ins> // run-pass #![feature(inline_const_pat)] #![allow(dead_code)] #![allow(incomplete_features)] fn foo<const V: usize>() { match 0 { const { 1 << 5 } | _ => {} } } fn main() {} </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --interestingly the code compiles as soon as I remove and just make it a boring <!-- 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 nightly-2023-06-01 Regression in cc
just needs to check for inline const along with anon consts in
claim do you mean literally just adding ? Seems to fix the ICE on my end
Change:
/// /// let uc = UnsafeCell::new(5); /// <del> /// let five = unsafe { uc.into_inner() }; </del> <ins> /// let five = uc.into_inner(); </ins> /// ``` #[inline] #[stable(feature = "rust1", since = "1.0.0")] <del> pub unsafe fn into_inner(self) -> T { </del> <ins> pub fn into_inner(self) -> T { </ins> self.value } }

Discussion:
It's been unsafe since 2014 when it was called . Nobody thought about it, I guess, but it shouldn't be unsafe.
For reference the PR which it is
Someone thought about it enough to : Has something changed to make this consideration unnecessary or do you have an explanation of why the reasoning is faulty?
Because the function takes so by definition it must be the owner of the value so there can be no other viewers, either from this thread or another thread.
Although this isn't backwards-compatible there is some prior art of going unsafe -safe: (although, that was pre-1.0)
That's weird, it seems like you ought to be able to assign a safe fn to an unsafe fn pointer. , Nicole Mazzuca wrote:
We removed the subtyping relation at some point; it does seem like a coercion would be (probably) ok, but that would still not be (strictly) backwards compatible.
(I tend to agree that could be safe, though, and I highly doubt any existing crates would actually break due to this change.)
We could always do a crater run just to be absolutely sure nobody is turning into a function pointer.
HI ! Any news on this one ?
No change that I know of.
FWIW the relevant coercion was in
This change is breaking my crate. If I add the then it will work for older compilers. If I remove the then it will work for newer compilers. Is there a conditional compilation attribute for compiler version? I can't find one.
Use
Yeah, that's what I'm doing for now. It seems kind of lame, though. But it does work.
Change:
.get(&item.item_id) .into_iter() .flatten() <del> .map(|clean::ItemLink { link, did, .. }| { (link.clone(), from_item_id((*did).into(), self.tcx)) </del> <ins> .map(|clean::ItemLink { link, page_id, fragment, .. }| { let id = match fragment { Some(UrlFragment::Item(frag_id)) => *frag_id, // FIXME: Pass the `UserWritten` segment to JSON consumer. Some(UrlFragment::UserWritten(_)) | None => *page_id, }; (link.clone(), from_item_id(id.into(), self.tcx)) </ins> }) .collect(); let docs = item.attrs.collapsed_doc_value();

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. --field contains wrong IDs for some kind of items. Items for which no independent HTML is generated (link target URL is ) appear to have incorrect IDs. I tried this code: I expected to see this happen: contains the IDs of link targets Instead, this happened: contains the ID of the items containing the link targets <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
modify labels: +A-rustdoc-json +T-rustdoc +A-intra-doc-links
claim
Change:
hideSearchResults(search); var hash = ev.newURL.slice(ev.newURL.indexOf("#") + 1); if (browserSupportsHistoryApi()) { <del> history.replaceState(hash, "", "?search=#" + hash); </del> <ins> // `window.location.search`` contains all the query parameters, not just `search`. history.replaceState(hash, "", getNakedUrl() + window.location.search + "#" + hash); </ins> } elem = document.getElementById(hash); if (elem) {

Discussion:
mdbook v4.6+ has a feature that pressing ESC removes query components from URLs (for example ). The feature was implemented in rust-lang/mdBook. It would be nice if rustdoc offers the same kind of that feature. This is, for example, an URL that contains query components in rustdoc: When users share URLs to an API, they don't have to remove the query manually.
could you share some thoughts about this feature request? If possible, could you mentor contributors how to implement this ?
I think it's a good idea. Gonna take a look at how to do it.
Can we reopen this issue ? I think only removes the query component when we remove keywords in search bar. This issue is about adding a keyboard shortcut.
Oh I see, my bad. Reopening!
Change:
<ins> fn main() { if 1 == = 1 { //~ ERROR expected expression println!("yup!"); } } </ins>

Discussion:
Been working in JavaScript a lot lately and find myself accidentally typing this a lot. It would be nice to automatically detect this and offer a proper fix. Lots of languages use this syntax in addition to JavaScript so it seems like a reasonable error to make. Playground example below. () Errors:
I think the current error message is clear enough. Also I don't think providing auto-fix suggestion is easy, because the error happened when parsing AST.
Nice. But I still think the current error message is fine as is.
don't disagree, but handling it was relatively easy because there's no case where would be valid.
Change:
assert!(output.status.success()); assert!(output.stderr.len() == 0); } <del> #[cfg(not(unix))] fn main() { // Not worried about signal masks on other platforms } </del>

Discussion:
Perhaps I'm holding it wrong? About a fifth of the rustc UI test suite to fail on wasm32-unknown-emscripten when trying to run . In all cases we get an error like this:
Does this target use some different main symbol name?
... do we need to pass --no-entry to lib builds? can you check if (some of) the failing tests are lib crates? Actually what am I doing, I can check
I can't get past the building test helpers for this target cross-compiling from msvc host, not sure what's up with that.
Huh. cc Can you make it any further?
Because there's an open PR for this.
In the open platform support docs PR this says It's recommended to test the  target instead for WebAssembly compatibility. ... so I don't know, is this expected failure?
See I was able to get past the build helpers stage by properly acquring the toolchain and making relevant env vars available to bootstrap. Didn't bother trying to diagnose past stage 1 std and tests because there's like a chain of failures. Notably I see
The failing link command includes: if we replace that with , then it links as expected. But then it fails to run it at: We should invoke with node.
So I guess for starters we should do:
Combined with setting the runner to this fixes most of the failing tests:
The failures seem to be: and seems like it hangs? sounds like an xfail.
Change:
<ins> error[E0658]: attributes on expressions are experimental --> $DIR/ICE-119271-never-arm-attr-in-guard.rs:6:16 | LL |             if #[deny(unused_mut)] |                ^^^^^^^^^^^^^^^^^^^ | = note: see issue #15701 <https://github.com/rust-lang/rust/issues/15701> for more information = help: add `#![feature(stmt_expr_attributes)]` to the crate attributes to enable error[E0658]: `!` patterns are experimental --> $DIR/ICE-119271-never-arm-attr-in-guard.rs:5:14 | LL |         Some(!) |              ^ | = note: see issue #118155 <https://github.com/rust-lang/rust/issues/118155> for more information = help: add `#![feature(never_patterns)]` to the crate attributes to enable error: a guard on a never pattern will never be run --> $DIR/ICE-119271-never-arm-attr-in-guard.rs:7:13 | LL |             false |             ^^^^^ help: remove this guard error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0658`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: No parent for node HirId(DefId(0:3 ~ code[c982]::noarmsorguards).13) (unknown node)', 'error: internal compiler error: No parent for node HirId(DefId(0:3 ~ code[c982]::noarmsorguards).13) (unknown node)' File: --snippet: Version 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: [shallowlintlevelson] looking up lint levels for [typeck] type-checking [analysis] running analysis passes on this crate --
Regression in cc
Change:
impl Emitter for BufferEmitter { fn emit_diagnostic(&mut self, diag: &Diagnostic) { let mut buffer = self.buffer.borrow_mut(); <del> // FIXME(davidtwco): need to support translation here eventually buffer.messages.push(format!("error from rustc: {}", diag.message[0].0.expect_str())); </del> <ins> let fluent_args = self.to_fluent_args(diag.args()); let translated_main_message = self.translate_message(&diag.message[0].0, &fluent_args); buffer.messages.push(format!("error from rustc: {}", translated_main_message)); </ins> if diag.is_error() { buffer.has_errors = true; }

Discussion:
I have created which reliably reproduces the internal compiler error on my system. The readme in that crate includes version as well as from inside and outside the repo which has a . This is recreated with: with the dependencies from my original crate into : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Note, changing to enables to succeed with version: -and:
claim
I'm also getting a similar error but mine doesn't resolve by changing in . More info:
This issue here is caused by nom as well. The fix is pretty simple, I should be able to open up the PR today.
Change:
use rustc_infer::infer::{ InferCtxt, InferOk, LateBoundRegion, LateBoundRegionConversionTime, NllRegionVariableOrigin, }; <ins> use rustc_infer::traits::ObligationCause; </ins> use rustc_middle::mir::tcx::PlaceTy; use rustc_middle::mir::visit::{NonMutatingUseContext, PlaceContext, Visitor}; use rustc_middle::mir::AssertKind;

Discussion:
Messing around with a Haskell-like implementation of , I encountered two presumably similar ICEs (would think they're the same, but the error messages are obviously different). The other one is . I'm pretty sure this should be an error, based on the reasoning that returns an opaque type, so, while the output of might be , it also might not (and in this case, isn't), and since only accepts s, should be an error. Note that this implementation throws the ICE even without the main method, but I'm leaving it there for contrast to the other ICE. : Same ICE on nightly: <details<summary<strongBacktrace</strong</summary<p</p</details
This regressed in
I was able to "weaponize" this into a transmute, lol: So the issue here is that, at least in the case of RPITs, we are not checking for opaque type mismatches in closures correctly. The closure, in this example, is able to incorrectly constrain even though in the enclosing function, we define . During mir borrowck, we never check these two together, so we never report a type mismatch. I think I have a fix, though.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Change:
Ok(ty) => ty, Err(guar) => Ty::new_error(tcx, guar), }; <del> collected_tys.insert(def_id, ty::EarlyBinder::bind(ty)); </del> <ins> remapped_types.insert(def_id, ty::EarlyBinder::bind(ty)); </ins> } Err(err) => { let reported = tcx.sess.delay_span_bug( return_span, format!("could not fully resolve: {ty} => {err:?}"), ); <del> collected_tys.insert(def_id, ty::EarlyBinder::bind(Ty::new_error(tcx, reported))); </del> <ins> remapped_types.insert(def_id, ty::EarlyBinder::bind(Ty::new_error(tcx, reported))); </ins> } } } <del> Ok(&*tcx.arena.alloc(collected_tys)) </del> <ins> // We may not collect all RPITITs that we see in the HIR for a trait signature // because an RPITIT was located within a missing item. Like if we have a sig // returning `-> Missing<impl Sized>`, that gets converted to `-> [type error]`, // and when walking through the signature we end up never collecting the def id // of the `impl Sized`. Insert that here, so we don't ICE later. for assoc_item in tcx.associated_types_for_impl_traits_in_associated_fn(trait_m.def_id) { if !remapped_types.contains_key(assoc_item) { remapped_types.insert( *assoc_item, ty::EarlyBinder::bind(Ty::new_error_with_message( tcx, return_span, "missing synthetic item for RPITIT", )), ); } } Ok(&*tcx.arena.alloc(remapped_types)) </ins> } struct ImplTraitInTraitCollector<'a, 'tcx> {

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-07-11 Regression in cc ^^
This is possibly fixed by , or alternatively . I'll have to look into it, but I'll look into it regardless by tomorrow.
Change:
const D: _ = 42; //~^ ERROR the type placeholder `_` is not allowed within types on item signatures } <ins> fn map<T>(_: fn() -> Option<&'static T>) -> Option<T> { None } fn value() -> Option<&'static _> { //~^ ERROR the type placeholder `_` is not allowed within types on item signatures Option::<&'static u8>::None } const _: Option<_> = map(value); //~^ ERROR the type placeholder `_` is not allowed within types on item signatures </ins>

Discussion:
Hello, While trying to figure out how to keep a JoinHandle in a thread-local variable, I tried compiling this incorrect code, and rust crashed. It will not panic if I use a regular static var instead of in a block. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
The ICE happens since 1.44 label: +regression-from-stable-to-stable
ping icebreakers-cleanup-crew can we add a bit more detail and trace where this starts?
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
Assigning as discussed as part of the and removing . label -I-prioritize +P-medium
Regression between ... If I had to guess, I would say
Reduced testcase:
Not sure if of any help, but the thread_local macro is not needed:
const : Option<= map(value); ;)
Change:
LL |     cfg!(target_feature = "zebra"); |          ^^^^^^^^^^^^^^^^^^^^^^^^ | <del> = note: expected values for `target_feature` are: `10e60`, `2e3`, `3e3r1`, `3e3r2`, `3e3r3`, `3e7`, `7e10`, `a`, `aclass`, `adx`, `aes`, `altivec`, `alu32`, `atomics`, `avx`, `avx2`, `avx512bf16`, `avx512bitalg`, `avx512bw`, `avx512cd`, `avx512dq`, `avx512er`, `avx512f`, `avx512fp16`, `avx512ifma`, `avx512pf`, `avx512vbmi`, `avx512vbmi2`, `avx512vl`, `avx512vnni`, `avx512vp2intersect`, `avx512vpopcntdq`, `bf16`, `bmi1`, and `bmi2` and 188 more </del> <ins> = note: expected values for `target_feature` are: `10e60`, `2e3`, `3e3r1`, `3e3r2`, `3e3r3`, `3e7`, `7e10`, `a`, `aclass`, `adx`, `aes`, `altivec`, `alu32`, `atomics`, `avx`, `avx2`, `avx512bf16`, `avx512bitalg`, `avx512bw`, `avx512cd`, `avx512dq`, `avx512f`, `avx512fp16`, `avx512ifma`, `avx512vbmi`, `avx512vbmi2`, `avx512vl`, `avx512vnni`, `avx512vp2intersect`, `avx512vpopcntdq`, `bf16`, `bmi1`, `bmi2`, `bti`, and `bulk-memory` and 186 more </ins> = note: see <https://doc.rust-lang.org/nightly/rustc/check-cfg.html> for more information about checking conditional configuration warning: 27 warnings emitted

Discussion:
For example, from (And many more.) I think this is due to Should we just drop these from ?
cc