jiebi/CodeConvo huggingface dataset:
Change:
fn merge_codegen_units<'tcx>( tcx: TyCtxt<'tcx>, initial_partitioning: &mut PreInliningPartitioning<'tcx>, <del> mut target_cgu_count: usize, </del> <ins> target_cgu_count: usize, </ins> ) { assert!(target_cgu_count >= 1); let codegen_units = &mut initial_partitioning.codegen_units; <del> if tcx.is_compiler_builtins(LOCAL_CRATE) { // Compiler builtins require some degree of control over how mono items // are partitioned into compilation units. Provide it by keeping the // original partitioning when compiling the compiler builtins crate. target_cgu_count = codegen_units.len(); } </del> // Note that at this point in time the `codegen_units` here may not be in a // deterministic order (but we know they're deterministically the same set). // We want this merging to produce a deterministic ordering of codegen units

Discussion:
I'm currently doing some benchmarks and I've seen that is taking a really long time to calculate on wasm. Turns out that none of the helper functions it uses are inlined at all, so it does a ton of unnecessary calls and misses a lot of potential optimizations: The same is probably true for the Float trait.
It seems like initially had a lot more inline annotations but removed them later on. That may have regressed the performance on wasm, but I'm not entirely sure. This makes me wonder if compiler-builtins is even compiled with LTO at all as it supposedly is meant to be?!
Looks like this is indeed a regression that started with Rust 1.44, which switched from compiler-builtins 0.1.25 to 0.1.27, which is where this PR is part of. These are the instructions in 1.43: cc
There's been a few various changes around codegen units handling and compiler-builtins recently, and it looks like this is caused by compiling this crate with . The compiler but with only one CGU.
Ok I've transferred this to the rust-lang/rust repository since this isn't a bug with compiler-builtins itself I believe but rather how we build compiler-builtins. I believe this is an accidental regression from because only part of the compiler knows that compiler-builtins is built with more than one CGU, the rest of the compiler thinks it's one CGU (respecting CLI flags). I'll be opening a PR shortly to fix this.
Assigning as and removing .
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. #![feature(const_fn)] pub const fn foo() {} pub const unsafe fn bar() {} pub struct Foo; impl Foo { pub const unsafe fn baz() {} } </ins>

Discussion:
Doc inclusion / doc reexport does not show properly (example: std::cell::Cell::new). Reexport metabug: rustdoc: Pain points of reexports const fn tracker:
Change:
) -> Bx::Value { let is_float = input_ty.is_floating_point(); let is_signed = input_ty.is_signed(); <del> let is_unit = input_ty.is_unit(); </del> match op { mir::BinOp::Add => if is_float { bx.fadd(lhs, rhs)

Discussion:
libcore however doesn't use those for the implementations for and for the unit type. This means that the special case in cg_ssa can be removed.
Hi I'd like to work on this. Would be a good initial contribution to Rust :)
I'm really new to the code base, though. Could you clarify what the means above?
That's , a part of the code generation code in rustc. The code in the first snippet is located there.
Thanks for clarifying that! I'll go through the code and post any questions here.
Would love to help but don't know where to start. If mentoring is still possible please ping me or send me in the right direction somehow .
or maybe if your up to the task :)
I think you just need to look at and remove the check for that was mentioned. You can check https://rust- for an overview of the compiler and instruction on how to build it and run tests.
Thanks seems to be a little simpler then I thought once I dug into the docs. Will do hope your having a good one .
Change:
PathSegment { name: item.name, args: GenericArgs::AngleBracketed { <del> args: ty.substs[generics.parent_count..] .iter() .map(|ty| match ty.unpack() { ty::subst::GenericArgKind::Lifetime(lt) => { GenericArg::Lifetime(lt.clean(cx).unwrap()) } ty::subst::GenericArgKind::Type(ty) => GenericArg::Type(ty.clean(cx)), ty::subst::GenericArgKind::Const(c) => GenericArg::Const(Box::new(c.clean(cx))), }) .collect(), </del> <ins> args: substs_to_args(cx, &ty.substs[generics.parent_count..], false), </ins> bindings: Default::default(), }, }

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --Minimized example: Command: <!-- 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. --Platform: See backtrace <!-- 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 --<!-- TRIAGEBOT_END --
I'll look into it! claim
Minimized this to a local-crate-only test, and working on a solution currently:
Change:
<ins> // Issue #52544 // run-rustfix fn main() { let i: &i64 = &1; if *i < 0 {} //~^ ERROR mismatched types [E0308] } </ins>

Discussion:
What I actually wanted was . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The problem is by the time this error is emittedwe don't have the information about the root cause anymore. In this case that would be the type of being checked for and figuring out the the rhs needs to be of the same type. Clippy has a lint that will tell you to clean it up afterwards, but we should probably issue a better diagnostic to begin with.
can you please create a ?
Please excuse my naïvety, but why is this (according to csmoes MCVE) a problem? You can actually write if i < &0 {} and everything works just fine. Can you please explain this part (to me)?
The comparison operator already takes references to both sides. so it seems simpler to dereference the lhs and save the monomorphizer and the optimizer some effort
Resurrecting this. what're the benefits of dereferencing the lhs instead of referencing the rhs? Also, if I were to go about fixing this, where would I start?
The benefit is that expands to , so if you start out with you get , seems better to just do instead (since is a no-op that gets easily removed). I'm not sure how to solve this or whether we should try at all.
claim
I want to get started with this, but would appreciate some mentoring from someone before I do, to point me in the right direction please
There's a reason I marked this as . I have no idea how to do this reasonably. I'm sorry, but I have no hints for you, and I don't even know if it's possible to do in a reasonable way.
cue terminator background music Leaving this here for future generations to see. I'm gonna try attempting to solve this and see if I can do something about it. I don't know if I can, or if I'll even survive this, but there's only one way to find out. Lol in all seriousness, if someone wants to claim this up, feel free to. Until then, I'll try and fix this.
Hi, are you still working on this issue
Hey I've been meaning to fix this up.

I've reached a point where I know exactly how to fix this as well. I just haven't found the time to fix this. Feel free to take it up, considering I wouldn't be having the time to work on this in the forseeable future.
release-assignment If do you find the time in the future, please claim this issue again. Until then I'll free it up in case anybody else wants it
Is anyone currently working on this? If not, I'd be happy to give it a go. claim
Change:
let predicates_of = tcx.predicates_of(def_id); debug!("instantiate_opaque_types: predicates={:#?}", predicates_of,); let bounds = predicates_of.instantiate(tcx, substs); <ins> let param_env = tcx.param_env(def_id); let InferOk { value: bounds, obligations } = infcx.partially_normalize_associated_types_in(span, self.body_id, param_env, &bounds); self.obligations.extend(obligations); </ins> debug!("instantiate_opaque_types: bounds={:?}", bounds); let required_region_bounds = tcx.required_region_bounds(ty, bounds.predicates.clone());

Discussion:
With the following code: comes the following error: However, this function compiles correctly without the keyword.
cc
You can trigger this without async/await using : cc
Some more reduction in genericity and clearing up a few things: The problem is that is not know in impl trait items. It's also not related to the return position, but refers to any impl trait in the function. Outside of impl trait can be resolved without a problem, so it must be something related to the way impl trait reuses the generics of its parent.
It seems to be a missing normalization, most likely.
I have a local fix for reduction above, but is making this rather difficult as it makes output not work properly.
This also happens for definitions: My fix only seems to turn this into a cycle error for some reason. EDIT: Nevermind I just broke existential types in general lol
Marking as blocking, although I think there's minimal future compat risk. If push came to shove I personally would be ok with removing this from the blocking list. But then it looks like already fixed it =)
I think the problem is on this line of code: in particular, we "instantiate" the predicates -- meaning, substitute in the values for their type parameters -- but we never normalize them. We should be able to invoke the methods. Note that in this code we do have an available, as well, in . I think we should be able to invoke: this returns an  value, which contains obligations that must be pushed into .
Hmm, that code is only invoked if is true, which I think wouldn't be the case here since there are no region bounds at all (right?). I also noticed that does not exist in this context ( is an ), and there's no nearby either. However, another place where is called without normalizing the result is here, further down in the same file: there does exist (as does ). Quick testing shows that normalizing there fixes this issue as well, and as a bonus also fixes the issue with without ICEs!
good catch -- actually I think the lines you found are the ones I meant to direct you to in the first place. I see you have some other problems on the PR, looking now.
Change:
// modify their locations. let all_facts = &mut None; let mut constraints = Default::default(); <ins> let mut type_tests = Default::default(); </ins> let mut closure_bounds = Default::default(); let mut liveness_constraints = LivenessValues::new(Rc::new(RegionValueElements::new(&promoted_body)));

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. --: (latest nightly as of today) </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label: +F-inline_const
Note the missing bound. requires , and should throw a lifetime bounds error, but I think the inline const block is tripping something up. It works fine if you require or without the inline const block.
claim
Change:
bt_fmt.add_context()?; let mut idx = 0; let mut res = Ok(()); <ins> // Start immediately if we're not using a short backtrace. let mut start = print_fmt != PrintFmt::Short; </ins> backtrace_rs::trace_unsynchronized(|frame| { if print_fmt == PrintFmt::Short && idx > MAX_NB_FRAMES { return false;

Discussion:
v.s. is less verbose, but I remember it also filtering out some stack frames in some previous compiler versions. (Only frame # 6 is really useful to me here.) Indeed, contains some code that looks for a symbol on the stack to find out what to filter. It looks like some functionality has regressed. Stepping through the program in gdb it looks like the function is called, but despite there’s apparently no stack frame (anymore?) for it. CC and for , , and .
contains a fix for this
Now being worked on in instead afaict?
It is.
This issue hasn't been active in almost two years, and so have the issues linked here. Is there any intention of resuming work on this? It's mostly a small papercut because currently when crashing, programs suggest: run with environment variable to display a backtrace. and after setting that, also claim that: Some details are omitted, run with for a verbose backtrace. even though no details were omitted at all (which is the issue of course)
A simple fix would be to just look for "std::rt::lang_start::{{closure}}" instead until the real solution to the disappearing function is found..
This single fix is likely to have the biggest positive effect on my use of Rust since async/await. Thank you so much!
Awesome! I'm happy to see this finally fixed :D Thanks to everyone who had a part in this fix :)
Change:
closure_def_id: DefId, capture_clause: hir::CaptureBy, span: Span, <del> body: &'tcx hir::Body<'tcx>, </del> ) { let need_migrations = self.compute_2229_migrations( closure_def_id, span, capture_clause, <del> body, </del> self.typeck_results.borrow().closure_min_captures.get(&closure_def_id), );

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. --Removing allows the code to compile successfully. <!-- 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 --<!-- TRIAGEBOT_END --
cc
I dont have too much context on how type folding works, but my guess is we are calling fold sooner that we should. I have this to the for RFC 2229, I'll bring it up during our sync tomorrow.
We want to use .
assign
Error: Parsing assign command in failed: ...'bot assign' ''... Please let know if you're having trouble with this bot.
claim
Thanks
Change:
<ins> error[E0191]: the value of the associated type `X` in `Super` must be specified --> $DIR/associated-type-shadowed-from-supertrait.rs:12:27 | LL |     type X; |     ------ `Super::X` defined here, consider renaming it ... LL |     type X; |     ------ `Super::X` shadowed here, consider renaming it ... LL | impl<T> Clone for Box<dyn Sub<X = T>> { |                           ^^^^^^^^^^ associated type `X` must be specified error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0191`. </ins>

Discussion:
Given the following code: The current output is: is wrong, specifying another isn't going to fix the problem. Writing just has a suggestion where`, which is good, but the concrete syntax would be nice. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
We probably should modify E0191 to hint that an supertrait's associated type is shadowed. I think E0719 here is fine to keep as-is, imo.
I agree the message for E0719 is good as-is.
Is this issue fixed ? If not can I take this up, please. Also how exactly should E0191 be modified. Imo, I don't think E0191 should pop up in this case as E0719 conveys the message.
claim
claim
Ask for help How do I specify the association type of supertrait with the same name? In other words, is there an easy way to modify the code in the issue to make it pass compilation? Here's my clumsy way of creating a new trait.
Is this issue still open? If so I would like to take a crack at it.
If you can still reproduce it, then yes indeed. assign
Error: Parsing assign command in failed: ...'zyDutchman' ''... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
I have now a hint about the shadowing: But I am not quite sure about what to do about the actual message. Do we want to suggest renaming to something else Or do we want to suggest the work-around by
If the trait is local, then we could suggest renaming it. It's not required to be super specific here--we could just note the conflict to make the user aware of it, for example.
I have updated the help message so that this case: gives this error message: The rename help message is emitted for both the super trait and the subtrait, if they are local. I think I am ready to make a merge request, or does somebody have something else to add?
I recommend you to just open a PR. Any further discussions can happen over there :)
Change:
pub fn clear(&mut self) { self.drain(); } } <ins> /// Hole represents a hole in a slice i.e. an index without valid value /// (because it was moved from or duplicated). /// In drop, `Hole` will restore the slice by filling the hole /// position with the value that was originally removed. struct Hole<'a, T: 'a> { data: &'a mut [T], /// `elt` is always `Some` from new until drop. elt: Option<T>, pos: usize, } impl<'a, T> Hole<'a, T> { /// Create a new Hole at index `pos`. fn new(data: &'a mut [T], pos: usize) -> Self { unsafe { let elt = ptr::read(&data[pos]); Hole { data: data, elt: Some(elt), pos: pos, } } } #[inline(always)] fn pos(&self) -> usize { self.pos } /// Return a reference to the element removed #[inline(always)] fn removed(&self) -> &T { self.elt.as_ref().unwrap() } /// Return a reference to the element at `index`. /// /// Panics if the index is out of bounds. /// /// Unsafe because index must not equal pos. #[inline(always)] unsafe fn get(&self, index: usize) -> &T { debug_assert!(index != self.pos); &self.data[index] } /// Move hole to new location /// /// Unsafe because index must not equal pos. #[inline(always)] unsafe fn move_to(&mut self, index: usize) { debug_assert!(index != self.pos); let index_ptr: *const _ = &self.data[index]; let hole_ptr = &mut self.data[self.pos]; ptr::copy_nonoverlapping(index_ptr, hole_ptr, 1); self.pos = index; } } impl<'a, T> Drop for Hole<'a, T> { fn drop(&mut self) { // fill the hole again unsafe { let pos = self.pos; ptr::write(&mut self.data[pos], self.elt.take().unwrap()); } } } </ins> /// `BinaryHeap` iterator. #[stable(feature = "rust1", since = "1.0.0")] pub struct Iter <'a, T: 'a> {

Discussion:
BinaryHeap is using and may not be exception safe. I.e. it is in an inconsistent state after being recovered after panic. See issue and others. Relevant code is cc
My immediate ideas are one of Use PPYP and set vector length to zero temporarily. Panicing in comparison functions will leak all elements in the heap Use more swaps
got the idea:
Long ago I suggested two other strategies: A two-pass phase where you do all comparisons first, then once you've found the Final Destination you actually do the swaps (which requires no untrusted code to run). A panic guard which on drop puts the "working" element back in the "uninit" location in the array
triage: I-nominated, T-libs
I'm trying gankro's panic guard idea.
Change:
# $(3) is host # $(4) tag define DEF_PREPARE_HOST_LIB <del> prepare-host-lib-$(1)-$(2)-$(3)-$(4): PREPARE_WORKING_SOURCE_LIB_DIR=$$(PREPARE_SOURCE_LIB_DIR) prepare-host-lib-$(1)-$(2)-$(3)-$(4): PREPARE_WORKING_DEST_LIB_DIR=$$(PREPARE_DEST_LIB_DIR) </del> <ins> prepare-host-lib-$(1)-$(2)-$(3)-$(4):  PREPARE_WORKING_SOURCE_LIB_DIR=$$(HLIB$(2)_H_$(3)) prepare-host-lib-$(1)-$(2)-$(3)-$(4):  PREPARE_WORKING_DEST_LIB_DIR=$$(PREPARE_DEST_DIR)/$$(notdir $$(HLIB$(2)_H_$(3))) </ins> prepare-host-lib-$(1)-$(2)-$(3)-$(4): prepare-maybe-clean-$(4)  $$(foreach dep,$$(RUST_DEPS_$(1)),prepare-host-lib-$$(dep)-$(2)-$(3)-$(4))  $$(HLIB$(2)_H_$(3))/stamp.$(1) 

Discussion:
There are no Windows nightlies currently being published: They appear to have been broken since at least Nov. 1. This prevents Servo from updating Rust. CC:
was looking into this earlier.
Change:
endif <ins> $$(TBIN$(1)_T_$(2)_H_$(3))/: mkdir -p $$@ </ins> $$(TLIB$(1)_T_$(2)_H_$(3))/: mkdir -p $$@

Discussion:
There comes a time in the life of every Rust developer when they have to blow away various parts of the directory to avoid messages about "multiple matching crates". Then when they do the next build they get things like: . It would be better if the Makefile would just create all the needed parent directories automatically.
+1
I'm pretty sure I know how to do this. (I think the right tools for the job are some in and )
I haven't actually waited for a whole build to go through yet, and I have to leave for the evening. But I'd welcome it if you would be willing to pull this (SHA: ) into your repo and give it a spin. If you don't get around to it, no sweat; it can obviously wait until Monday.
argh ignore comment above; the commit isn't anywhere near fully baked yet; somethings off with my make syntax.
Okay. It would be nice to do this in the interim, but eventually when rustpkg is the build system it will do this (much more easily than with Makefile hacking), so no sweat if you don't get it done :-)
Change:
MY_STRUCT.use_mut(); //~ WARN taking &mut MY_STRUCT; //~ WARN taking (&mut MY_STRUCT).use_mut(); //~ WARN taking <ins> // Test that we don't warn when writing through // a raw pointer // This is U.B., but this test is check-pass, // so this never actually executes unsafe { *RAW_PTR = 0; *MY_STRUCT.raw_ptr = 0; } </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 have quite a lot of MMIO in an embedded project, defined and used like this: (see a ) When I , I'm getting a whole host of warnings of the type: I expect no warnings, because I'm not assigning to a , I'm assigning to a dereferenced , aka a mutable u32. I couldn't figure out a playground example that would show the value actually mutating, but by hitting hardware registers I can prove that the value does get mutated, and it makes sense that it would: The pointer is , but it's pointing to a able . Dereferencing shouldn't care whether the pointer variable is . <!-- 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. --: No backtrace for this bug; it's a warning.
There's a... fine, I guess, workaround of in my case, since all the MMIO code is bundled into a module away from the rest.
cc
This will be fixed by
Awesome, thanks so much!
Change:
let bx = self; <ins> match coverage.kind { // Marker statements have no effect during codegen, // so return early and don't create `func_coverage`. CoverageKind::SpanMarker => return, // Match exhaustively to ensure that newly-added kinds are classified correctly. CoverageKind::CounterIncrement { .. } | CoverageKind::ExpressionUsed { .. } => {} } </ins> let Some(function_coverage_info) = bx.tcx.instance_mir(instance.def).function_coverage_info.as_deref() else {

Discussion:
The immediate symptoms of were fixed by , but some users reported that their builds now encounter another coverage-related ICE:
label +T-compiler +A-code-coverage
This ICE does not occur on current stable/beta, but does occur on nightly. label +regression-from-stable-to-nightly
(This will be fixed by , which is awaiting review.)
WG-prioritization assigning priority (). label -I-prioritize +P-high