jiebi/CodeConvo huggingface dataset:
Change:
<ins> // Make sure we do not request sanitizers for naked functions. //@ only-x86_64 //@ needs-sanitizer-address //@ compile-flags: -Zsanitizer=address -Ctarget-feature=-crt-static #![crate_type = "lib"] #![no_std] #![feature(abi_x86_interrupt, naked_functions)] // CHECK: define x86_intrcc void @page_fault_handler(ptr {{.*}}%0, i64 {{.*}}%1){{.*}}#[[ATTRS:[0-9]+]] { // CHECK-NOT: memcpy #[naked] #[no_mangle] pub extern "x86-interrupt" fn page_fault_handler(_: u64, _: u64) { unsafe { core::arch::asm!("ud2", options(noreturn)); } } // CHECK: #[[ATTRS]] = // CHECK-NOT: sanitize_address </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 : And compiled it with . I expected to see this happen: The compiler should generate a function which only contains the instruction. Instead, this happened: The compiler crashes with . <!-- 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. --: As requested in
This is an LLVM assertion
It was noted in that this comes from sanitizer annotations being to naked functions. Seems like we might not want to do that? Cc
Almost certainly, but is not supposed to be used in places where user input can cause it to be reached.
Reported at
To clarify, the fix that landed is just to make this an IR verification failure rather than a backend crash. The underlying issue with the kasan + naked combination still needs to be fixed.
Should we file an issue upstream to handle this in sanitizers as well, or is there one already opened?
Change:
"serde_ignored 0.0.3 (registry+https://github.com/rust-lang/crates.io-index)", "serde_json 1.0.2 (registry+https://github.com/rust-lang/crates.io-index)", "shell-escape 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)", <del> "tar 0.4.12 (registry+https://github.com/rust-lang/crates.io-index)", </del> <ins> "tar 0.4.13 (registry+https://github.com/rust-lang/crates.io-index)", </ins> "tempdir 0.3.5 (registry+https://github.com/rust-lang/crates.io-index)", "term 0.4.5 (registry+https://github.com/rust-lang/crates.io-index)", "toml 0.4.1 (registry+https://github.com/rust-lang/crates.io-index)",

Discussion:
I got in a project of mine for recent nightlies which I think are releated to the rustification of rust-installer but I'm not 100% certain: does this sound familiar to you?
Oh looks like and are all related to this as well.
Ah, yes, backslashes in the manifest are an easily understood problem. Executable is harder. At least I left a note about that . :) Since Windows doesn't really have such flags, I suspect it must have worked on some MSYS tricks with ACLs before. Maybe we should make a special case for this when writing the tarball, like writing known-executable file names with manually-tweaked metadata?
Yeah I think we'll probably just want to special case everything going into the tarballs and manually set the metadata for the various bits and pieces. I'm... not entirely sure how this worked with MSYS, but presumably there's some weird translation layer which we're not aware of and isn't surfaced through winapi things...
OK, so should fix up the manifests at least. Researching the file modes, I first wondered whether the crate should read the advanced ACLs for , as right now it just . But it looks like all created files have "execute" privileges anyway -- e.g. even includes . You can remove that with in MSYS/Cygwin/etc., but it appears atypical for a file not_ to be executable. The good news is that also doesn't care about execute when unpacking on Windows, just . The rest will follow the defaults of , still with executable ACLs. So I think the permissions created by rustup will be fine, but I guess if one manually unpacks with MSYS/Cygwin tar they may get non-executable etc. The quickest hack for you would be to just change this: Step 7 : RUN /tmp/rust-mingw-nightly-i686-pc-windows- --prefix= ... to invoke instead, which doesn't care about execute privileges. :)
Ah yeah I don't think there's a great way to flag a file on Windows as executable/not-executable, I'm basically just thinking that we have a whitelist of files/patterns that will get listed as executable in the tarball (as the tarball stores unix modes) and we'd just follow that.
Change:
<ins> //@ build-pass //@ compile-flags: -Zmir-opt-level=0 -Zmir-enable-passes=+GVN fn main() { let variant: Option<u32> = None; let transmuted: u64 = unsafe { std::mem::transmute(variant) }; println!("{transmuted}"); } </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
cc I suspect this might be related to
I did not know where to add this is the template but this may be useful: Build works in debug mode, but not in release mode.
Regression in nightly-2023-12-31 (...)
Change:
[[package]] name = "anyhow" <del> version = "1.0.51" </del> <ins> version = "1.0.60" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "8b26702f315f53b6071259e15dd9d64528213b44d61de1ec926eca7715d62203" </del> <ins> checksum = "c794e162a5eff65c72ef524dfe393eb923c354e350bb78b9c7383df13f3bc142" </ins> [[package]] name = "array_tool"

Discussion:
This seems to have started recently; going back to before fixes the problem.
Cc any idea what might be happening here? Not everyone sees this behavior, strangely.
Looks like , and probably needs the same fix. Something is lying about the exit status of rustc.
Cc who seems to be (or has been) getting similar errors
hm, but this code seems to forward the exist status correctly
One possible issue is that anyhow does not seem to propagate (set via the TARGET env var) to . (This would likely also make it fail in Miri cross-interpretation.) The bootstrap binary to determine whether to use the bootstrap sysroot or the sysroot matching the target build.
IOW, is missing.
Not sure what's going on in this case sadly :/ I had this issue because of a bug in rustc-perf but I haven't seen it show up outside of that context.
I can confirm that the issue is fixed by applying
I am pretty sure this was caused by after that PR, the build probe of anyhow fails to build with latest libstd. It still works with the bootstrap compiler's libstd though, which is why anyhow thinks it can use the backtrace feature, but actually can't. (EDIT: and now I see has already linked to that PR. oops) eyre has exactly the same problem:
Change:
<del> Subproject commit 5e05efa87905fb5b351a2bc5644d60c57d6d9327 </del> <ins> Subproject commit 72265bea210891ae47bbe6d4f17b493ef0606619 </ins>

Discussion:
The relevant commit seem to be located at <details<summaryError</summary<p</p</details
Ah. cc
Ah, this was fixed in
Okay, it seems like this is just a misunderstanding. keywords cannot be searched ...
This won't be actually fixed in std until lands.
Change:
<ins> error[E0004]: non-exhaustive patterns: `C(QA)` not covered --> $DIR/issue-40221.rs:21:11 | 21 |     match proto { |           ^^^^^ pattern `C(QA)` not covered error: aborting due to previous error </ins>

Discussion:
The minimum code example: compiling:
Thats a regression from stable → beta/nightly.
Introduced by .
Change:
[[package]] name = "bitflags" <del> version = "0.8.2" source = "registry+https://github.com/rust-lang/crates.io-index" [[package]] name = "bitflags" </del> version = "0.9.1" source = "registry+https://github.com/rust-lang/crates.io-index"

Discussion:
generates different HTML under and not. Not only does this trigger what's effectively a spurious warning, but it doesn't render correctly either. cc , marking this as p-high
This was fixed by google/pulldown-cmark rustdoc just needs to update its version of pulldown-cmark.
The thread in that issue says it was released in 0.0.15. we're pulling in 0.0.14 for rustdoc, but also 0.1.0 for mdbook. I'll see if i can update the dependency for rustdoc and pull it in.
updates Pulldown for rustdoc and fixes this.
I am not sure this actually fixes the warnings, as they use different IDs and such. I'm testing this locally right now though; expect an update in ~20 minutes
Change:
<ins> // edition:2021 // [next] compile-flags: -Zlower-impl-trait-in-trait-to-assoc-ty // revisions: current next #![feature(async_fn_in_trait)] trait MyTrait<'a, 'b, T> { async fn foo(&'a self, key: &'b T) -> (&'a ConnImpl, &'b T); //~^ ERROR: cannot find type `ConnImpl` in this scope [E0412] } impl<'a, 'b, T, U> MyTrait<T> for U { //~^ ERROR: implicit elided lifetime not allowed here [E0726] async fn foo(_: T) -> (&'a U, &'b T) {} //~^ ERROR: method `foo` has a `&self` declaration in the trait, but not in the impl [E0186] //~| ERROR: mismatched types [E0308] } 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. --<!-- 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
This brings up the question again with whether or not we should just feed itemname for RPITITs. I can't recall the other issues where this was a problem, but perhaps we should just do that and revert all the previous mitigations we introduced due to the fact that itemname is missing for RPITITs.
Just pushed a fix, I think you were always right about not feeding item_name, whenever you try to call it for RPITITs we should have never tried because the message we are trying to fill won't make any sense.
Change:
LL | #[cfg(target(os = "linux", pointer(width = "64")))] |                            ^^^^^^^^^^^^^^^^^^^^^ <del> error: aborting due to 3 previous errors </del> <ins> error: `cfg` predicate key must be an identifier --> $DIR/cfg-target-compact-errors.rs:17:14 | LL | #[cfg(target(true))] |              ^^^^ error: aborting due to 4 previous errors </ins> Some errors have detailed explanations: E0537, E0565. For more information about an error, try `rustc --explain E0537`.

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'called on a value'', 'thread 'rustc' panicked at 'called on a value'' 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: [resolverforlowering_raw] getting the resolver for lowering --
mvce
bisects to cc ^^'
Change:
use collections::{BTreeMap, BTreeSet}; use collections::EnumSet; use collections::LinkedList; <ins> use collections::String; </ins> use collections::Vec; use collections::VecDeque; use collections::VecMap;

Discussion:
cc
The rfc says It also includes an example which depends on usize: However RangeArgument only implements the first four. Furthermore as things stand it does not appear possible to accept RangeArgument<usizeand usize simultaneously, because dispatch doesn't consider the trait bound and reports that conflicting implementations exist.
Yes, was explicit about these issues. I forsee a new RFC to finish off drain and maybe the RangeArgument trait.
I believe this has
Change:
tcx: TyCtxt<'tcx>, predicates: &List<ty::PolyExistentialPredicate<'tcx>>, ) -> &'tcx List<ty::PolyExistentialPredicate<'tcx>> { <del> let predicates: Vec<ty::PolyExistentialPredicate<'tcx>> = predicates .iter() .filter_map(|predicate| match predicate.skip_binder() { </del> <ins> tcx.mk_poly_existential_predicates_from_iter(predicates.iter().filter_map(|predicate| { match predicate.skip_binder() { </ins> ty::ExistentialPredicate::Trait(trait_ref) => { let trait_ref = ty::TraitRef::identity(tcx, trait_ref.def_id); Some(ty::Binder::dummy(ty::ExistentialPredicate::Trait(

Discussion:
<!-- [31mICE[0m: Rustc '-Zsanitizer=cfi -Ccodegen-units=1 -Clto -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0'', 'thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0'' File: --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 --
I believe this happens since cc
seems to also cause problems
The core problem here is the encoding of the receiver on a object that has no principal. There's a fix for this in the larger patch stack I was breaking down to land piecewise. I'll upload it in a moment. claim
Change:
use super::region_constraints::GenericKind; use super::lexical_region_resolve::RegionResolutionError; <del> use std::fmt; </del> <ins> use std::{cmp, fmt}; </ins> use hir; use hir::map as hir_map; use hir::def_id::DefId; use middle::region; use traits::{ObligationCause, ObligationCauseCode}; <del> use ty::{self, Region, Ty, TyCtxt, TypeFoldable, TypeVariants}; </del> <ins> use ty::{self, subst::Subst, Region, Ty, TyCtxt, TypeFoldable, TypeVariants}; </ins> use ty::error::TypeError; use syntax::ast::DUMMY_NODE_ID; use syntax_pos::{Pos, Span};

Discussion:
In , adding an parameter to the type, that defaults to induces changes to UI tests that are indicative of something that seemed to need improvement in the compiler, namely that when you have a type , errors should present instead of when they can. It turns out, the compiler does. But not consistently. The following is derived from : () This yields the following errors: See how it prints instead of the (imho) desired , but , not .
This all stems from the fact that in some cases, types are just printed out by formatting the instances, while in other cases, there is manual machinery to highlight parts of the type that handle things, and that doesn't have the default-param elimination that has.
Change:
<ins> trait Foo { fn foo(&self); } trait Bar {} fn do_stuff<T : Bar>(t : T) { t.foo() //~ ERROR no method named `foo` found for type `T` in the current scope } fn main() {} </ins>

Discussion:
Missing a trait bound for the trait that defines below: Results in the following suggestion with an extra colon after the plus.
you can look at and for inspiration on how to deal with this.
I came up with a different solution, but there may be a subtlety I'm missing:
Change:
Abi::Scalar(s @ abi::Scalar::Initialized { .. }) => { let size = s.size(bx); assert_eq!(size, layout.size, "abi::Scalar size does not match layout size"); <del> let val = read_scalar(offset, size, s, bx.backend_type(layout)); </del> <ins> let val = read_scalar(offset, size, s, bx.immediate_backend_type(layout)); </ins> OperandRef { val: OperandValue::Immediate(val), layout } } Abi::ScalarPair(

Discussion:
Reduced from : Compilation should crash with this error: Because we are trying to generate an LLVM bitcast from to . The MIR dump looks like this: I haven't been able to figure out how to produce this MIR without DataflowConstProp.
Thes standard library also works as a reproducer. Simply building a hello world with this will assert:
You asked about this crash before when I had a messy reproducer. Pinging you now because it's a lot smaller. it is now
Change:
/// total order. For example, for floating point numbers, `NaN < 0 == false` and `NaN >= 0 == /// false` (cf. IEEE 754-2008 section 5.11). /// <del> /// This trait can be used with `#[derive]`. When `derive`d, it will produce an ordering /// based on the top-to-bottom declaration order of the struct's members. </del> <ins> /// `PartialOrd` requires your type to be `PartialEq`. /// /// If your type is `Ord`, you can implement `partial_cmp` by using `cmp`: /// /// ``` /// impl PartialOrd for Person { ///     fn partial_cmp(&self, other: &Self) -> Option<Ordering> { ///         Some(self.cmp(other)) ///     } /// } /// ``` /// /// You may also find it useful to use `partial_cmp` on your type`s fields. Here /// is an example of `Person` types who have a floating-point `height` field that /// is the only field to be used for sorting: /// /// ``` /// use std::cmp::Ordering; /// /// struct Person { ///     id: u32, ///     name: String, ///     height: f64, /// } /// /// impl PartialOrd for Person { ///     fn partial_cmp(&self, other: &Self) -> Option<Ordering> { ///         self.height.partial_cmp(&other.height) ///     } /// } /// /// impl PartialEq for Person { ///     fn eq(&self, other: &Self) -> bool { ///         self.height == other.height ///     } /// } /// ``` </ins> /// /// # Examples ///

Discussion:
I'm using s as keys in a BtreeMap. I have to look up the map ~15 million times per second (10G ethernet line rate). Ipv4Addr cmp() compiles to this on my system (linux x86-64, rustc 1.10.0-nightly ( 2016-05-21)) Which seems kinda inefficient for a thing which is basically u32. I guess part of the reason is the which converts it to an array(!) first. I copied the definition and implemented Ord like this: It's about 10 times faster on my .
Nice find! Want to send a PR for this? Looks like something that'd be more than welcome :)
Change:
enum_var_cache.get().insert(local_def(id), @variants); } <del> // Check that it is possible to represent this enum: let mut outer = true; let did = local_def(id); if ty::type_structurally_contains(ccx.tcx, rty, |sty| { match *sty { ty::ty_enum(id, _) if id == did => { if outer { outer = false; false } else { true } } _ => false } }) { ccx.tcx.sess.span_err(sp, "illegal recursive enum type;  wrap the inner value in a box to make it representable"); } </del> <ins> // Check that it is possible to represent this enum. check_representable(ccx.tcx, sp, id, "enum"); </ins> // Check that it is possible to instantiate this enum: //

Discussion:
The following program causes a stack overflow: There is a check that enums do not recurse in this way, but no such check for structs. (Note, though, that there is a check that structrs are instantiable, which is slightly different)
Huh, so that's why std::list has pointer indirections in it.
This is still an issue, nominating for production ready
accepted for production-ready milestone
So uh, this... doesn't exactly reproduce. It compiles and runs fine, no overflow or anything afaict. It should be rejected by the compiler, I think.
you have to reference the type, just like , which I triaged today. Actually I think they are the same bug.
This applies to non-infinite-sized types that contain themselves unboxed like the following too:
Accepted for 1.0, P-high.

Here is a test case: I think the right approach is to replace with something like . then we have to keeep a stack of def-ids and when we enter a new nominal type check that we do not already have it on the stack. i started this then realized it was a big distraction from what I'm trying to do, so filing a bug instead. Marking as A-typesystem as this check is performed in
Just to make this concrete: both of the cases that Niko describes yield ICE's. The first (the and items) yields an ICE with no useful error information. The second ( and ) yields an error describing the illegal recursive enum type (followed by an ICE :).
I don't believe this is backwards incompatible, renominating.
accepted for production-ready milestone
appears to be properly classified
Accepting for P-high.
Tagging as mentorship bug, with as mentor
This code triggers the same infinite recursion in typestructurallycontains:
I have a fix for this written, in case anyone is wondering whether to start working on it. I'll submit a pull request soon.
Change:
} /// Compare `a` and `b` for equality (Using partial equality, `Eq`) <del> pub fn eq<A: Eq, T: Iterator<A>>(mut a: T, mut b: T) -> bool { </del> <ins> pub fn eq<A: Eq, T: Iterator<A>, S: Iterator<A>>(mut a: T, mut b: S) -> bool { </ins> loop { match (a.next(), b.next()) { (None, None) => return true,

Discussion:
They're currently very restricted as they only work with a single iterator type for both arguments, so, e.g. doesn't work. It should be easy to just add another parameter for the second argument.
Change:
|                 help: provide a definition for the static: `= <expr>;` error: free static item without body <del> --> $DIR/item-free-static-no-body-semantic-fail.rs:9:1 </del> <ins> --> $DIR/item-free-static-no-body-semantic-fail.rs:10:1 </ins> | LL | static mut D; | ^^^^^^^^^^^^- |             | |             help: provide a definition for the static: `= <expr>;` <del> error: aborting due to 4 previous errors </del> <ins> error: missing type for `static` item --> $DIR/item-free-static-no-body-semantic-fail.rs:6:8 | LL | static B; |        ^ help: provide a type for the item: `B: <type>` error: missing type for `static mut` item --> $DIR/item-free-static-no-body-semantic-fail.rs:10:12 | LL | static mut D; |            ^ help: provide a type for the item: `D: <type>` error: aborting due to 6 previous errors </ins>

Discussion:
Reproducible with stable and nightly compilers. : : Maybe this is a duplicated of but I'm not sure as the example there is more complex. : <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regressed in 1.52.0. The error in 1.51.0 wasn't so great either though, but at least it didn't ICE:
Regression in nightly-2021-03-08 (too long ago to get build artifacts per commit). That's the commit range .... Possibly related to an interaction between (which seems to have landed in that commit range) and dtorck?
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
Change:
<ins> // edition:2018 // check-pass // revisions: full min #![cfg_attr(full, feature(const_generics))] #![cfg_attr(full, allow(incomplete_features))] #![cfg_attr(min, feature(min_const_generics))] const SIZE: usize = 16; struct Bar<const H: usize> {} struct Foo<const H: usize> {} impl<const H: usize> Foo<H> { async fn biz(_: &[[u8; SIZE]]) -> Vec<()> { vec![] } pub async fn baz(&self) -> Bar<H> { Self::biz(&vec![]).await; Bar {} } } fn main() { } </ins>

Discussion:
The use of async/await and const generics can cause ICE (in the type checker?). Here is a minimal example which induces ICE: The behaviour is not triggered without the use of async/await. The . I am running recent nightly compiler: : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Guessing: It might be comparing an const to another const and expects them to compare equal. Slightly minified:
Related to . Not going to mark as a duplicate yet, since the MVCE is quite different.
Note that this ICEs with but not , where it compiles successfully. We should add a test.
Triage: It's now compiled successfully with and the latest nightly.
Great! Leaving open to track adding a regression test.
I'd like to add the test. claim