jiebi/CodeConvo huggingface dataset:
Change:
<ins> #![feature(generic_const_exprs)] //~^ WARN: the feature `generic_const_exprs` is incomplete // Regression test for #125770 which would ICE under the old effects desugaring that // created a const generic parameter for constness on `Add`. use std::ops::Add; pub struct Dimension; pub struct Quantity<S, const D: Dimension>(S); //~^ ERROR: `Dimension` is forbidden as the type of a const generic parameter impl<const D: Dimension, LHS, RHS> Add<LHS, D> for Quantity<LHS, { Dimension }> {} //~^ ERROR: trait takes at most 1 generic argument //~| ERROR: `Dimension` is forbidden as the type of a const generic parameter pub fn add<const U: Dimension>(x: Quantity<f32, U>) -> Quantity<f32, U> { //~^ ERROR: `Dimension` is forbidden as the type of a const generic parameter x + y //~^ ERROR: cannot find value `y` in this scope } fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: tried to combine ConstKind::Infer/ConstKind::Infer(InferConst::Var): ?0e: bool and ?0c: Dimension', 'error: internal compiler error: tried to combine ConstKind::Infer/ConstKind::Infer(InferConst::Var): ?0e: bool and ?0c: Dimension' 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: [evaluateobligation] evaluating trait selection obligation [typeck] type-checking -- label +F-genericconstexprs
(this is bc is a and is an effect var)
Can't reproduce it.
cc I assume this was fixed by the new effects desugaring that does not create an implicit const parameters
the new effects desugaring landed 3 days ago wheres this stopped crashing already around 3 weeks ago.
Can't reproduce it. Originally posted by in That is because I tried 2024-05-30 and it actually regressed in 2024-05-31. Specifically in . It then un-regressed in 2024-06-05. Specifically in (in the rollup).
Change:
use rustc_middle::ty::{self, subst::Subst, TyCtxt}; use rustc_span::source_map::Span; use rustc_target::abi::{Abi, LayoutOf}; <del> use std::convert::TryInto; </del> <ins> use std::convert::{TryFrom, TryInto}; </ins> pub fn note_on_undefined_behavior_error() -> &'static str { "The rules on what exactly is undefined behavior aren't clear, 

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</detailsNOTE: The bug is found by our work-in-progress compiler testing tool Kira, and the test program is reduced/minimized by
Assigning and removing as as part of the prioritization working group procedure.
searched nightlies: from nightly-2020-09-16 to nightly-2020-09-29 regressed nightly: nightly-2020-09-27 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
Cc
Change:
use crate::{Build, DocTests, GitRepo, Mode}; pub use crate::Compiler; <ins> // FIXME: replace with std::lazy after it gets stabilized and reaches beta use once_cell::sync::Lazy; </ins> pub struct Builder<'a> { pub build: &'a Build,

Discussion:
introduced some checks which execute 4 times. They run unconditionally when executing , even if it is just to run tidy. On my system the wall time exceeds that of running tidy itself. I'll look into whether the checks themselves can be made be less wasteful. But if there are suggestions how to completely eliminate them or defer them while preserving their original purpose that would be great too. ! CC can you explain the purpose of running this in rather than erroring in ?
To know beforehand if the test should unconditionally be run or not. If the test is run and the npm package isn't installed, we panic. To be noted that we could make it go down to 2 by switching the order of : currently we check both "local" and "global". Switching the two of them will divide the number of calls by two. cc
I don't have installed, so it'll fail and no short-circuiting will happen regardless of order.
In case you don't have it it'll check 4 times indeed.
Hm, this does seem annoying. It's possible we could add some lazily-evaluated default condition so that this never runs if we're not considering default-on steps (if defaults are on, then these npm lists are likely quite fast in comparison to the rest of the logic).
Change:
fn emit_orphan_check_error<'tcx>( tcx: TyCtxt<'tcx>, sp: Span, <ins> full_impl_span: Span, </ins> trait_span: Span, self_ty: Ty<'tcx>, self_ty_span: Span,

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 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. --<!-- 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 --<!-- TRIAGEBOTEND --
This could use some work, too, I think. Maybe "impl mentions type from outside the current crate" might be a sufficient replacement, though we should probably make sure that wording is compatible with current coherence rules. Though, in this case, for a non- self type like , we could then replace that^ message with something even more specific. I'm a bit skeptical of mentioning "try implementing on " when we have , since implementing something for and can have very different meanings depending on the signatures inside the trait.
Let's improve this case! claim
This was actually closer to my original error I got, it uses a type alias to create some extra confusion:
Amazing example :) thanks, I'm on it
This is a reproducible example without serde!
Change:
// Exclude #[repr(simd)] types so that they are not de-optimized into an array return true; } <ins> if Some(def.did()) == tcx.lang_items().dyn_metadata() { // codegen wants to see the `DynMetadata<T>`, // not the inner reference-to-opaque-type. return true; } </ins> // We already excluded unions and enums, so this ADT must have one variant let variant = def.variant(FIRST_VARIANT); if variant.fields.len() > 1 {

Discussion:
<!-- [31mICE[0m: Rustc '-Zmir-opt-level=5 -Zvalidate-mir -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'broken MIR in Item(DefId(0:8 ~ [c6e7]::main)) (after pass ScalarReplacementOfAggregates) at bb3[12]:'', 'thread 'rustc' panicked at 'broken MIR in Item(DefId(0:8 ~ [c6e7]::main)) (after pass ScalarReplacementOfAggregates) at bb3[12]:'' 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: [optimizedmir] optimizing MIR for [collectandpartitionmonoitems] collectandpartitionmonoitems -- label +F-ptrmetadata
cc
Thanks! I have a fix for this in -- I didn't know it was possible without that change. I'll pull it out to a separate PR.
Change:
use rustc_middle::ty::{self, Ty}; use rustc_span::symbol::Symbol; use rustc_span::symbol::{kw, sym}; <del> use rustc_span::{BytePos, Span, DUMMY_SP}; </del> <ins> use rustc_span::{BytePos, Span}; </ins> declare_lint! { /// The `unused_must_use` lint detects unused result of a type flagged as

Discussion:
Reported by here: (Note that but does not fix this bug.)
searched nightlies: from nightly-2021-01-07 to nightly-2021-12-24 regressed nightly: nightly-2021-09-12 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
This regression was introduced in . cc
Not a fix, but if I make this change then there is no longer an ICE and I get
Thanks for opening the issue If someone finds a fix but doesn't know how to add the test, this pull request which solves a similar ICE has an example of how to add a test when there is a missing newline:
Change:
<ins> //@ build-fail //@ needs-asm-support #![feature(asm_const)] use std::arch::global_asm; fn main() {} global_asm!("/* {} */", const 1 << 500); //~ ERROR evaluation of constant value failed [E0080] global_asm!("/* {} */", const 1 / 0); //~ ERROR evaluation of constant value failed [E0080] </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: asm const cannot be resolved', 'error: internal compiler error: asm const cannot be resolved' 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 --
Regression in nightly-2021-12-16 lol commit[0] 2021-12-14: Auto merge of - matthiaskrgr:rollup-hjjyhow, r=matthiaskrgr commit[1] 2021-12-14: Auto merge of - Amanieu:stableasm, r=joshtriplett commit[2] 2021-12-15: Auto merge of - matthiaskrgr:rollup-cw9qolb, r=matthiaskrgr commit[3] 2021-12-15: Auto merge of - matthiaskrgr:rollup-jszf9zp, r=matthiaskrgr commit[4] 2021-12-15: Auto merge of - yaahc:track-caller-result, r=cuviper commit[5] 2021-12-15: Auto merge of - matthiaskrgr:rollup-rhajuvw, r=matthiaskrgr commit[6] 2021-12-15: Auto merge of - matthiaskrgr:rollup-2g082jw, r=matthiaskrgr ERROR: no CI builds available between and within last 167 days ~/vcs/github/rustbisect via v1.78.0-nightly too I would guess ? cc
Doubt it, that's just when the stabilization happened, there's no meaningful changes there
Actually bisects to which support for in .
label +F-asm +A-inline-assembly +F-inline_const -needs-triage
cc
claim
Change:
static _F5: unsafe extern "C" fn(*mut c_void, usize) -> *mut c_void = jemalloc_sys::realloc; #[used] static _F6: unsafe extern "C" fn(*mut c_void) = jemalloc_sys::free; <ins> // On OSX, jemalloc doesn't directly override malloc/free, but instead // registers itself with the allocator's zone APIs in a ctor. However, // the linker doesn't seem to consider ctors as "used" when statically // linking, so we need to explicitly depend on the function. #[cfg(target_os = "macos")] { extern "C" { fn _rjem_je_zone_register(); } #[used] static _F7: unsafe extern "C" fn() = _rjem_je_zone_register; } </ins> } rustc_driver::set_sigpipe_handler();

Discussion:
jemalloc is supposed to be enabled on macos for rustc, but with all the testing I've done, it does not appear to work. Noted by Thom Chiovoloni on Zulip , the jemalloc-sys crate prevents using unprefixed symbols , which IIUC, means that it is building with symbols like , which AFAIK are never actually used. If it indeed does not work, then I think it would be good to consider either looking into fixing it (which I suspect may not be easy), or stop building it on CI. Tested with most recent nightly () and master ().
You can't override the macos malloc by shadowing its symbols (I think very early allocations in the loader still use the original malloc or something?). Instead, jemalloc actually hooks directly into some macos allocator APIs to replace the guts behind the original symbols IIRC.
This is where the magic happens I believe:
Thanks for taking a look! Do you happen to know if there's some way to validate that it is working? When I run with the environment variable I get that rustc has allocated bytes regardless of how big of a crate I build. Is there maybe a better way to determine if it is actually working?
Ah - when statically linking to jemalloc, the zone_register constructor function appears to be dropped by the linker: The compiler already manually marks other bits of jemalloc as : Extending that with Gets it registered properly for me with a little test crate.
Ah, I can confirm with those changes it seems to be working. I might do some benchmarking to see how it does, but pending , it may not be necessary.
I ran a few benchmarks, and it looks promising: (Not sure why the prebuilt nightly is so much slower. Maybe some random setting like MACOSXDEPLOYMENTTARGET?) These are pretty typical numbers of the various projects I tried. I also tested tikv-jemalloc-sys, but I didn't see much difference from the current jemalloc.
Pretty neat! would need macOS support too, so this should give clues on how to add it.
You should make sure this works on macOS pre-10.12, as this version changed how a number of things work (without looking at jemalloc, possibly most relevant being interpose)
Change:
//~| ERROR missing lifetime specifier } <ins> // This must not err, as the `&` actually resolves to `'a`. fn resolved_anonymous<'a, T>(f: impl Fn(&'a str) -> &T) { f("f") } </ins> fn main() {}

Discussion:
https://crater- https://crater- https://crater- https://crater- cc as possible root cause,
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Change:
} } <ins> impl From<GeneratorKind> for YieldSource { fn from(kind: GeneratorKind) -> Self { match kind { // Guess based on the kind of the current generator. GeneratorKind::Gen => Self::Yield, GeneratorKind::Async(_) => Self::Await, } } } </ins> // N.B., if you change this, you'll probably want to change the corresponding // type structure in middle/ty.rs as well. #[derive(RustcEncodable, RustcDecodable, Debug, HashStable)]

Discussion:
Consider for example this code (using ): This code will fail to compile due to types which cannot be fully inferred, with an error like this: However neither of these spans are anywhere near to the real problem which is the fact that variant is not inferred for . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
assign will do some investigation here and see if they can get an idea what's going on (and maybe fix)
Change:
} pub(super) fn type_is_sized(&self, ty: Ty<'tcx>) -> bool { <del> ty.is_sized(self.tcx, self.param_env, DUMMY_SP) </del> <ins> ty.is_sized(self.tcx.at(DUMMY_SP), self.param_env) </ins> } pub fn load_mir(

Discussion:
One example is the method on . Internally it creates a , when it could simply be taking exactly that as an argument. In miri I had to write which just feels a little riddiculous (taking apart the , just to have the method construct it back). There's probably many other similar methods and functions that should be taking a
Can I take this one if no one is working on that ?
it's all yours!
Change:
} /// Configuration for compiletest <del> #[derive(Clone)] </del> <ins> #[derive(Debug, Clone)] </ins> pub struct Config { /// `true` to to overwrite stderr/stdout files instead of complaining about changes in output. pub bless: bool,

Discussion:
Doctest test names have changed due to . Doc comments that pass through a macro defined in another crate now seem to report a different span. /// assert!(true); /// running with previously looked like this: Now the test names look like this: Frankly, neither are particularly great. It would be nice if the test name used the span from where the macro was invoked, not where it was defined.
I think this also affects normal backtraces :( Just got this rather unuseful backtrace while bootstrapping: full:
cc
What you're describing is entirely in the opposite direction, is the old (and arguably bad) kind of that's impossible to get anymore. I've hidden your comment to focus on the reported issue.
That makes sense, we have a way to get the outermost invocation, that is used by / and : We'd just need to use this in .
cc
cc
Removed label, left nomination for to decide about this issue.
Well, using what suggested seems like the best thing to do.
Change:
fn visit_assoc_type_binding(&mut self, type_binding: &'ast TypeBinding) { walk_assoc_type_binding(self, type_binding) } <del> fn visit_attribute(&mut self, _attr: &'ast Attribute) {} </del> <ins> fn visit_attribute(&mut self, attr: &'ast Attribute) { walk_attribute(self, attr) } fn visit_tt(&mut self, tt: TokenTree) { walk_tt(self, tt) } fn visit_tts(&mut self, tts: TokenStream) { walk_tts(self, tts) } fn visit_token(&mut self, _t: Token) {} // FIXME: add `visit_interpolated` and `walk_interpolated` </ins> fn visit_vis(&mut self, vis: &'ast Visibility) { walk_vis(self, vis) }

Discussion:
This issue probably needs a better title, perhaps someone more familiar with the compiler's handling of macros can suggest a better one. Some kind of error message, at least. panic with exit code :
Simplified: Same ICE will happen if is changed to ///. Update: Panic happens at this line: has keys and , but the is .
Change:
<ins> #![feature(layout_for_ptr)] use std::mem; #[repr(packed, C)] struct PackedSized { f: u8, d: [u32; 4], } #[repr(packed, C)] struct PackedUnsized { f: u8, d: [u32], } impl PackedSized { fn unsize(&self) -> &PackedUnsized { // We can't unsize via a generic type since then we get the error // that packed structs with unsized tail don't work if the tail // might need dropping. let len = 4usize; unsafe { mem::transmute((self, len)) } } } fn main() { unsafe { let p = PackedSized { f: 0, d: [1, 2, 3, 4] }; let p = p.unsize() as *const PackedUnsized; // Make sure the size computation does *not* think there is // any padding in front of the `d` field. assert_eq!(mem::size_of_val_raw(p), 1 + 4*4); // And likewise for the offset computation. let d = std::ptr::addr_of!((*p).d); assert_eq!(d.cast::<u32>().read_unaligned(), 1); } } </ins>

Discussion:
This code panics, but it should not: The panic disappears when the is inlined (because then we hit a different code path in ). What happens here is a bug in the logic that computes the offset of : since it is an unsized field, the offset is computed dynamically, by taking the statically known offset and then rounding it up to the dynamic alignment of the field. However, since the struct is packed, we need to cap the dynamic alignment of the field to the packing of the surrounding struct -- which we currently do not do. This is just yet another case where the non-compositional nature of is causing issues...
A slight variant of this code ICEs: It hits which, it seems, was never updated when support for was implemented.
WG-prioritization assigning priority (). label -I-prioritize +P-medium EDIT: lowered priority after discussion on Zulip
Change:
source_type: SourceType::Submodule, extra_features: Vec::new(), }) <del> .expect("expected to build -- essential tool") </del> <ins> .expect("expected to build -- essential tool"); let build_cred = |name, path| { // These credential helpers are currently experimental. // Any build failures will be ignored. let _ = builder.ensure(ToolBuild { compiler: self.compiler, target: self.target, tool: name, mode: Mode::ToolRustc, path, is_optional_tool: true, source_type: SourceType::Submodule, extra_features: Vec::new(), }); }; if self.target.contains("windows") { build_cred( "cargo-credential-wincred", "src/tools/cargo/crates/credential/cargo-credential-wincred", ); } if self.target.contains("apple-darwin") { build_cred( "cargo-credential-macos-keychain", "src/tools/cargo/crates/credential/cargo-credential-macos-keychain", ); } build_cred( "cargo-credential-1password", "src/tools/cargo/crates/credential/cargo-credential-1password", ); cargo_bin_path </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. --<!-- The steps to reproduce the bug. --(The actual target doesn't seem to matter, the feature just requires that we pass a argument.) The following error occurs: I think this issue occurs because already landed, while the cargo-side revert in did not. So this issue will likely go away after the next cargo update. I still decided to open this issue in case other people encounter the same problem. <!-- 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. --:
Cc for
This will be fixed by .
Change:
GoodPath, } <del> #[derive(Clone, Hash)] </del> <ins> #[derive(Clone, Hash, Debug)] </ins> pub enum ResolveDocLinks { /// Do not resolve doc links. None,

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
searched nightlies: from nightly-2023-02-10 to nightly-2023-03-18 regressed nightly: nightly-2023-02-12 searched commit range: regressed commit: cc
Could you assign it to me, I am willing to try to solve the problem
Change:
<ins> error[E0433]: failed to resolve: unresolved import --> $DIR/suggest-import-issue-120074.rs:10:35 | LL |     println!("Hello, {}!", crate::bar::do_the_thing); |                                   ^^^ unresolved import | help: a similar path exists | LL |     println!("Hello, {}!", crate::foo::bar::do_the_thing); |                                   ~~~~~~~~ help: consider importing this module | LL + use foo::bar; | help: if you import `bar`, refer to it directly | LL -     println!("Hello, {}!", crate::bar::do_the_thing); LL +     println!("Hello, {}!", bar::do_the_thing); | error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0433`. </ins>

Discussion:
just a minor formatting logic bug I think. If a module name is missing in the middle of a chain (here is used, but is defined) the suggestion is the full path, not just the bit in the middle that is missing. No response
looks like this was fixed already, but it's not on nightly yet (or at least, not on ) on commit I see the correct output:
seems it still not be fixed in nightly.