jiebi/CodeConvo huggingface dataset:
Change:
is_static: bool, is_return_type: bool, ) { <del> // We have to check for opaque types before `normalize_erasing_regions`, // which will replace opaque types with their underlying concrete type. </del> if self.check_for_opaque_ty(sp, ty) { // We've already emitted an error due to an opaque type. return; } <del> // it is only OK to use this function because extern fns cannot have // any generic types right now: let ty = self.cx.tcx.normalize_erasing_regions(self.cx.param_env, ty); </del> <ins> let ty = self.cx.tcx.try_normalize_erasing_regions(self.cx.param_env, ty).unwrap_or(ty); </ins> // C doesn't really support passing arrays by value - the only way to pass an array by value // is through a struct. So, first test that the top level isn't an array, and then

Discussion:
Create an empty crate, add to dependencies, and . [ ] Previous Stable [ ] Current Stable [X] Current Beta [X] Current Nightly Discovered on since 1.72.0-nightly ( 2023-07-03). The previous version 2023-07-02 is good. The breaking day is the same as . I suspect this is also related to . But fix to that does NOT fix this ICE though. cc The error message is similar to , but that occurs on an earlier version 2023-06-28. I guess it's unrelated.
label regression-from-stable-to-beta
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
pub(super) fn new_simple(kind: ErrorKind) -> Self { let utagged = ((kind as usize) << 32) | TAG_SIMPLE; // Safety: `TAG_SIMPLE` is not zero, so the result of the `|` is not 0. <del> let res = Self(unsafe { NonNull::new_unchecked(utagged as *mut ()) }); </del> <ins> let res = Self(unsafe { NonNull::new_unchecked(utagged as *mut ()) }, PhantomData); </ins> // quickly smoke-check we encoded the right thing (This generally will // only run in libstd's tests, unless the user uses -Zbuild-std) debug_assert!(

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: either it to compile or not compile. Instead, this happened: it compiled but only on 64-bit platforms. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust 1.59 (where it did not compile no matter what platform) <!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged -- modify labels: +regression-from-stable-to-beta -regression-untriaged
Not sure what the best approach is here. We could just to restore consistency from which made auto-implement . cc
which non-64bit platform does reproduce the issue (not sure if this question matters a lot)?
All platforms that have and . For example, . This is caused by this code:
Ah, should have or something along those lines. I'll get a fix for this up later this evening or tomorrow.
Hmm, this should probably not be closed, unless prioritization will still see it if it is closed.
Yeah, for backports I think the issue stays open until the backport is landed or decided against. Reopened for tracking.
Change:
<ins> // pretty-compare-only // pretty-mode:expanded // pp-exact:format-args-str-escape.pp fn main() { println!("x1B[1mHello, world!x1B[0m"); println!("u{1B}[1mHello, world!u{1B}[0m"); println!("Not an escape sequence: u{{1B}}[1mboldx1B[0m"); println!("{}", "x1B[1mHello, world!x1B[0m"); } </ins>

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. --I tried this code (): I expected to see this happen: When running , the format string literals for the first two s should remain valid string literals. Instead, this happened: This code is generated: Note the double and in the escapes. The escape sequences in the last are correctly preserved. This is annoying because it makes it impossible to run on the macro-expanded source, which is helpful when trying to read macro-generated code. <!-- 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 --
I haven't looked at it, but this is probably going wrong somewhere in when printing .
Looks like you’re right: As I understand this, it duplicates curlies regardless of whether they’re part of an escape sequence.
claim
Change:
| LL |     macro_two!(); |     ^^^^^^^^^ <ins> | = note: consider importing this macro: two_macros::macro_two </ins> error: aborting due to previous error

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. --I tried this code: I expected to see this happen: compiler should suggest importing from (it is in ). Instead, this happened: compiler say cannot find macro 'Component' but did not suggest importing it like other functions <!-- 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 not available in stable.
Change:
assert_eq!(u as *const u8, p as *const u8); assert_eq!(u as *const u16, p as *const u16); <del> // ptr-ptr-cast (both vk=Length) </del> <ins> // ptr-ptr-cast (Length vtables) </ins> let mut l : [u8; 2] = [0,1]; let w: *mut [u16; 2] = &mut l as *mut [u8; 2] as *mut _; let w: *mut [u16] = unsafe {&mut *w};

Discussion:
Much of the implementation work for rust-lang/rfcs has been done, but there remain some corner cases to fix: [ ] Casts between raw pointers to different traits are accepted but should not be (e.g. ) [ ] Double-check other cases, ensure adequate tests exist
triage: P-high -- I'm giving this high priority since accepting casts that we ought not to is a backwards compatibility risk, though it is mitigated by the fact that afaik the illegal casts yield an ICE (but I haven't done exhaustive testing)
The newly-illegal casts shouldn't be ICE-s (I mean, on nightly). Casts on stable are just randomly ICE-ey.
Change:
<ins> // Check that we do not ICE when structurally comparing types with lifetimes present. // check-pass pub struct Record<'a> { pub args: &'a [(usize, &'a str)], } mod a { extern "Rust" { fn foo<'a, 'b>(record: &'a super::Record<'b>); fn bar<'a, 'b>(record: &'a super::Record<'b>); } } mod b { extern "Rust" { fn foo<'a, 'b>(record: &'a super::Record<'b>); fn bar<'a, 'b>(record: &'a super::Record<'b>); } } fn main() {} </ins>

Discussion:
<!-- 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</detailsPlayground uses 7-13 nightly still, and the code compiles there:
Hmmm... I can't seem to reproduce this. Windows only, perhaps? Or incremental comp issue? I have the input in a and am running .
followed by reproduces this for me. Might be Windows only, haven't tested elsewhere. edit: my code originally failed in Github Actions using an ubuntu builder so I guess not Windows only.
Yup, fails in WSL, too: <details<summaryBacktrace</summary<p</p</details
It fails on latest nightly for me. Failing version: Working version:
Ahh! I was testing 2022-07-14, which passes. I got confused by the date being 1 day off. Yeah, I can reproduce it now :) Running a bisect.
searched nightlies: from nightly-2022-07-13 to nightly-2022-07-15 regressed nightly: nightly-2022-07-15 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
is yet another rollup; we really need a try build for each rolled up PR... Out of: (Always create elided lifetime parameters for functions) (Stabilize and rexport in ) (Implement lifetime binder for closures) (remove allow(rustc::potentialqueryinstability) in rustcspan) (Give a better error when fails for an optional tool) This looks like cc
This is a variant of the following bug which already happens on stable:
Change:
<ins> struct A; struct B; struct C; struct D; fn f( a1: A, a2: A, b1: B, b2: B, c1: C, c2: C, ) {} fn main() { f(C, A, A, A, B, B, C); //~ ERROR this function takes 6 arguments but 7 arguments were supplied [E0061] f(C, C, A, A, B, B);  //~ ERROR arguments to this function are incorrect [E0308] f(A, A, D, D, B, B);  //~ arguments to this function are incorrect [E0308] f(C, C, B, B, A, A);  //~ arguments to this function are incorrect [E0308] f(C, C, A, B, A, A);  //~ arguments to this function are incorrect [E0308] } </ins>

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. --I tried this code: I expected to see this happen: the compiler giving an error and showing a hint that order of the argument are not correct. Instead, this happened: it stucks, waits forever. It happens on both stable and nightly. Might be related to this:
Yeah, this is probably a dupe of that other one. cc
Yes, it's another bug in the same function, but the root cause is different. I will working on the same PR for this issue.
Change:
DefPathData::ValueNs(i.ident.name) } ItemKind::MacroDef(..) => DefPathData::MacroNs(i.ident.name), <del> ItemKind::MacCall(..) => return self.visit_macro_invoc(i.id), </del> <ins> ItemKind::MacCall(..) => { visit::walk_item(self, i); return self.visit_macro_invoc(i.id); } </ins> ItemKind::GlobalAsm(..) => DefPathData::Misc, ItemKind::Use(..) => { return visit::walk_item(self, i);

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. --Found an ICE with when trying to use it in the standard library (). cc . <!-- 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
I can hit an additional ICE by using an unknown attribute instead of a valid one: <details<summary<strongBacktrace</strong</summary<p</p</detailsI don't really think it's useful for this issue though, since it's a delayed error.
Fixed in
Change:
<ins> // check-pass struct Generic<T>(T); impl<T> Generic<T> { const ARRAY: [T; 0] = []; const NEWTYPE_ARRAY: Generic<[T; 0]> = Generic([]); const ARRAY_FIELD: Generic<(i32, [T; 0])> = Generic((0, [])); } pub const fn array<T>() ->  &'static T { &Generic::<T>::ARRAY[0] } pub const fn newtype_array<T>() ->  &'static T { &Generic::<T>::NEWTYPE_ARRAY.0[0] } pub const fn array_field<T>() ->  &'static T { &(Generic::<T>::ARRAY_FIELD.0).1[0] } fn main() {} </ins>

Discussion:
The following ICE's on nightly only: <details<summaryBacktrace:</summary</detailsThis ICE is the same as reported in , however the example given there currently runs fine without any errors.
cc
As the OP notes, this is closely related to . To fix that problem, zero-length arrays were special-cased so that they are never marked as indirectly mutable. However, this did not extend to projections of zero-length arrays. When compiling this code, the analysis sees a reference being taken to a place of type , which it cannot assume is . I should be able to make the validation passes agree in this particular case by checking the type of the target of each projection along the borrowed place, suppressing the indirectly mutable annotation for the base local if any of those types are a zero-sized array. It's unfortunate that we have to treat and differently here, but obviously backwards compatibility must be preserved. I wonder if there's a different way to handle this. It seems like should return for an empty array?
Change:
<ins> error: expected `;`, found `#` --> $DIR/properly-recover-from-trailing-outer-attribute-in-body-1.rs:4:47 | LL |     #[cfg(feature = )] |     ------------------ only `;` terminated statements or tail expressions are allowed after this attribute LL |     [1, 2, 3].iter().map().collect::<String>() |                                               ^ expected `;` here LL |     #[attr] |     - unexpected token | help: add `;` here | LL |     [1, 2, 3].iter().map().collect::<String>(); |                                               + help: alternatively, consider surrounding the expression with a block | LL |     { [1, 2, 3].iter().map().collect::<String>() } |     +                                            + error: expected statement after outer attribute --> $DIR/properly-recover-from-trailing-outer-attribute-in-body-1.rs:5:5 | LL |     #[attr] |     ^^^^^^^ error: aborting due to 2 previous errors </ins>

Discussion:
<!-- [31mICE[0m: Rustc '--crate-type=lib -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: not a tail expression', 'error: internal compiler error: not a tail expression' File: --auto-reduced (treereduce-rust): original: 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: --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It seems the pops up since cc The code starts ICEing in general since cc
claim
Change:
<del> fn main() {} </del> <ins> fn main() { let x: Vec<i32> = vec![1, 2, 3].into_iter().collect::<Vec<i32>>().sort_by_key(|i| i); //~ ERROR mismatched types vec![1, 2, 3].into_iter().collect::<Vec<i32>>().sort_by_key(|i| i).sort(); //~ ERROR no method named `sort` found for unit type `()` in the current scope } </ins> fn foo(mut s: String) -> String { s.push_str("asdf") //~ ERROR mismatched types }

Discussion:
In long method chains we might inadvertently call a method that is not meant to be chained. When this happens, the most likely error to occur is a type error involving . We should instead look if the rhs expression is a method chain and look at all the chained call's type to find where is introduced. Given Ideally the output would be closer to <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Hi, I'd like to try working on this :) claim
Change:
<ins> struct A {} impl A { fn new() {} } fn hof<F>(_: F) where F: FnMut(()) {} fn ice() { hof(|c| match c { A::new() => (), //~ ERROR expected tuple struct/variant, found method _ => () }) } fn main() {} </ins>

Discussion:
This one is very interesting IMHO. The "original" ICE was introduced between ..., but if I prepend the before (the outcommented line), there's a second ICE that is there forever (at least since Rust 1.11). modify labels: I-ICE C-bug
modify labels: I-ICE C-bug T-compiler (seems that I cannot ping rustbot from the thread start itself)
Reduced:
This issue exists all the way back to at least 1.7.0.
Change:
<ins> // build-pass // only-x86_64 // compile-flags: --crate-type=lib -C target-cpu=skylake #![feature(avx512_target_feature)] #![feature(stdarch_x86_avx512)] use std::arch::x86_64::*; #[target_feature(enable = "avx512f")] #[no_mangle] pub unsafe fn test(res: *mut f64, p: *const f64) { let arg = _mm512_load_pd(p); _mm512_store_pd(res, _mm512_fmaddsub_pd(arg, arg, arg)); } </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. --Compiling With nightly (2024-02-13) fails with nightly 2024-02-08 (with the stdsimd removal and stdarch addition) compiles fine Looks like the update to LLVM 18 could be the culprit <!-- 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. --: Here is the .ll file coming from the emit llvm ir (as recommended in another issue of the sort) changed extension so that github is not annoying about it (what a way to validate data blobs!) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Reduces to something like this:
Just wanted to take a moment and thank you warmly it's a pleasure to interact and work with you on those issues (even if it's only as a bug reporter ) Cheers
This fails: While this works: This also works: I think it's related to this change: It will automatically add only if generic target-cpu is used. I can't say that I understand the logic behind that change, but I guess this means we have to explicitly add in rustc when avx512 features are used.
Change:
<ins> trait Foo { const ASSOC: bool = true; } impl<T> Foo for fn(T) {} fn foo(_x: i32) {} fn impls_foo<T: Foo>(_x: T) {} fn main() { impls_foo(foo as fn(i32)); <fn(&u8) as Foo>::ASSOC; //~^ ERROR implementation of `Foo` is not general enough //~| ERROR implementation of `Foo` is not general enough } </ins>

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code (): The current ( , regressed in the past week) output is: <!-- The following is not always necessary. --Ideally the output should look like: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --The desired result can be achieved by swapping the order of the two statements and . <!-- If dramatically different output is caused by small changes, consider also adding them here. If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
searched nightlies: from nightly-2022-06-07 to nightly-2022-06-08 regressed nightly: nightly-2022-06-08 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details are you working on this? I'll probably be investigating this due to it being related to the recent removal of the borrowck migration mode.
I've been working on it a bit, but please feel free to take over this issue!
This actually looks like a particularly difficult issue. I think it's either a bug in , or something weird with the that is convincing us that the correct source for this region error is through the on line 12 of the example. It may also be notable that we end up going thru a when emitting this error. This issue seems to be out of my area of expertise, so I won't claim it. if you can't find a solution then it may be best to hand off to someone with mir-borrowck expertise.
Actually, what I said was totally wrong.

This is definitely because we're passing in the wrong when . I think I have a fix for this, though I probably want to eliminate other dummy locations we're passing around mir borrowck... cc sorry for all the pings, but don't keep wasting time on this unless you've made significant progress :stuckout_tongue: claim
Change:
_ => panic!("can't make docs for trait item with name {:?}", item.name) } <del> match link { AssocItemLink::Anchor if !is_static || render_static => { document(w, cx, item) }, _ => Ok(()), </del> <ins> if !is_default_item && (!is_static || render_static) { document(w, cx, item) } else { Ok(()) </ins> } } write!(w, "<div class='impl-items'>")?; for trait_item in &i.impl_.items { <del> doctraititem(w, cx, trait_item, link, render_header, outer_version)?; </del> <ins> doctraititem(w, cx, trait_item, link, render_header, false, outer_version)?; </ins> } fn render_default_items(w: &mut fmt::Formatter,

Discussion:
I use documentation on my trait impls to tell users about how my types behave: This documentation is not rendered anymore. I expect to see it under the entry for the implementation of the type. I think this was lost after (the otherwise very awesome!) documentation changes by
Note: Documentation on top of the item itself is properly rendered. If you too agree this is adequate, please close the issue again.
Just for reference: this also leaves the (perhaps not entirely obvious) operator impls on HashSets undocumented. Also see on this issue.
Yes, is dup of this. It is hiding stable parts of std from me:
Change:
Err(..) => Ok(EvaluatedToErr), } })?; <ins> // If we erased any lifetimes, then we want to use // `EvaluatedToOkModuloRegions` instead of `EvaluatedToOk` // as your final result. The result will be cached using // the freshened trait predicate as a key, so we need // our result to be correct by *any* choice of original lifetimes, // not just the lifetime choice for this particular (non-erased) // predicate. // See issue #80691 if stack.fresh_trait_ref.has_erased_regions() { result = result.max(EvaluatedToOkModuloRegions); } </ins> debug!(?result); Ok(result) }

Discussion:
Split out from the discussion in See for the original comments. The issue is caused by the way that we handle regions in the evaluation cache. When we insert a result into the evaluation cache (either or , we use a 'freshened' version of the original as the key. The 'freshened' has all non-late-bound regions erased. Unfortunately, this can lead to issues if we try to evaluate the following two predicates: When we evaluate , we'll get , since the region parameter in our trait ref is known to match the impl. We will then cache the result as . If we later try to evaluate , we will end up matching the evaluation cache entry, giving us a result of . However, we should have gotten a result of , since we don't know that holds. This is really difficult to observe in practice, for a number of reasons: The relevant trait predicates need to get evaluated, not just registered in a . Trait evaluation usually goes through the query, which canonicalizes the regions in the input trait ref. To end up trying to evaluate , we need to end up calling on it, with a different original trait ref used in the original query. Using instead of only seems to cause an error when it results in the incremental hash changing (I don't know if it's possible to weaponize this into extending a lifetime). As a result, I haven't been able to minimize this.
With landing, this is going to start causing ICEs (since the query result is actually changing across compilatioon sessions). I'm still not sure if this can actually cause unsoundness, but it should be fixed anyway, since it's a bug in a pretty subtle part of the trait system. cc - I'm not familiar enough with the relevant code to be sure of how to fix this.
This can be reproduced by following the instructions in after lands - it turns out that that reproducer also hits this issue. Unfortunately, that reproducer is quite large, and I'm not sure how to minimize it.
I wouldn't know where to look (or rather, I only know the vague shape of all of this, but not enough details) and would defer to or myself. The only thing I can think of is we should blanket use any time freshening erased a lifetime.
The same issue happens on
managed to create a minimized reproducer in