jiebi/CodeConvo huggingface dataset:
Code change:
run_pass_manager(cgcx, tm, llmod, config, true); cgcx.save_temp_bitcode(&mtrans, "thin-lto-after-pm"); timeline.record("thin-done"); <ins> // FIXME: this is a hack around a bug in LLVM right now. Discovered in // #46910 it was found out that on 32-bit MSVC LLVM will hit a codegen // error if there's an available_externally function in the LLVM module. // Typically we don't actually use these functions but ThinLTO makes // heavy use of them when inlining across modules. // // Tracked upstream at https://bugs.llvm.org/show_bug.cgi?id=35736 this // function call (and its definition on the C++ side of things) // shouldn't be necessary eventually and we can safetly delete these few // lines. llvm::LLVMRustThinLTORemoveAvailableExternally(llmod); cgcx.save_temp_bitcode(&mtrans, "thin-lto-after-rm-ae"); timeline.record("no-ae"); </ins> Ok(mtrans) } }

Related discussion:
text: With one CPU we'd split the preexisting one huge CGU into N different ones, probably take roughly the same amount of time to opimize those, and then tack on ThinLTO and more optimization passes. My guess is that with one CPU we'd easily see 50% regressions. With 2+ CPUs however I'd probably expect to see benefits to compile time. Anything giving us twice the resources to churn the cgus more quickly should quickly start seeing wins in theory I think. For now though the deterministic builds wins me over in terms of leaving this as-is for all hardware configurations. That and I doubt anyone's compiling Rust on single-core machines nowadays!
One thing I think that's also worth pointing out is that up to this point we've mostly been measuring the runtime of an entire . That's actually, I believe, the absolute worst case scenario for where ThinLTO will provide benefit. Despite this, it's showing huge improvements for lots of projects! The benefit of ThinLTO and multiple CGUs is leveraging otherwise idle parallelism on the build machine. It's overall increasing the amount of work the compiler does. For a from scratch, though, you typically already have tons of crates compiling for the first half of the build in parallel. In that sense there's not actually any idle parallelism. Put another way, ThinLTO and multiple CGUs should only be beneficial for builds which dont have many crates compiling in parallel for long parts of the build. If a build is 100% parallel for the entire time then ThinLTO will likely regress compile time performance. Now you might realize, however, that one very common case where you're only building one crate is in an incremental build! Typically if you do an incremental build you're only building a handful of crates, often serially. In that sense I think that there's some massive wins of ThinLTO + multiple CGUs in incremental builds rather than entire crate builds. Although improving both is of course great as well :)
For deterministic builds you have to do some extra configuration anyway (e.g. path remapping) so I would not consider that a blocker. And I guess there are single core VMs around somewhere.
Code change:
run_pass_manager(cgcx, tm, llmod, config, true); cgcx.save_temp_bitcode(&mtrans, "thin-lto-after-pm"); timeline.record("thin-done"); <ins> // FIXME: this is a hack around a bug in LLVM right now. Discovered in // #46910 it was found out that on 32-bit MSVC LLVM will hit a codegen // error if there's an available_externally function in the LLVM module. // Typically we don't actually use these functions but ThinLTO makes // heavy use of them when inlining across modules. // // Tracked upstream at https://bugs.llvm.org/show_bug.cgi?id=35736 this // function call (and its definition on the C++ side of things) // shouldn't be necessary eventually and we can safetly delete these few // lines. llvm::LLVMRustThinLTORemoveAvailableExternally(llmod); cgcx.save_temp_bitcode(&mtrans, "thin-lto-after-rm-ae"); timeline.record("no-ae"); </ins> Ok(mtrans) } }

Related discussion:
text: But all of this is such a niche case that I don't really care MIR-only RLIBs should put us into a pretty good spot regarding this, so I'm quite confident that we're on the right path overall.
That's really interesting. For incremental compilation enabled the situation might be different (because pre-trans inlining hurts re-use) but for the non-incremental case it sounds like it's pretty clear what to do.
Yeah, maybe we should revisit this at some point. Although I have to say the current solution of only and symbols and nothing in between is really nice and simple.
Hm yeah that's a good point about needing configuration anyway for deterministic builds. It now seems like a more plausible route to take! Also that's a very interesting apoint about incremental and inlining on our own end... Maybe we should dig more into those ThinLTO runtime regressions at some point! Also yeah I don't really want to change how we trans inline functions just yet, I do like the simplicity too :)
out of curiosity how did you figure out this and which function it was. I've wanted to look into why the webrender build is so slow and would welcome tips.
oh sure I'd love to explain! So I originally found as a problematic crate when compiling rust-belt as it just took awhile and I decided to dig deeper. I checked out the crate and ran: That drops in the current directory, and opening that up I see: ! The graph here isn't always the easiest to read, but we've clearly got two huge bars, both of which correspond to taking a huge amount of time for that one CGU (first is optimization, second is ThinLTO + codegen). Next I ran: and that command dumps a bunch of IR files into . Our interesting CGU is so I opened up (we sure do love our long filenames). Inside that file it was 70k lines and some poking around showed that one function was 66k lines of IR. I sort of forget now how at this point I went from that IR to determining there was a huge function in there though...
I don't know if this is the right place, but I think it should be considered whether the symbol issues reported in the Nightly section here: should be considered a blocker or not.
Code change:
run_pass_manager(cgcx, tm, llmod, config, true); cgcx.save_temp_bitcode(&mtrans, "thin-lto-after-pm"); timeline.record("thin-done"); <ins> // FIXME: this is a hack around a bug in LLVM right now. Discovered in // #46910 it was found out that on 32-bit MSVC LLVM will hit a codegen // error if there's an available_externally function in the LLVM module. // Typically we don't actually use these functions but ThinLTO makes // heavy use of them when inlining across modules. // // Tracked upstream at https://bugs.llvm.org/show_bug.cgi?id=35736 this // function call (and its definition on the C++ side of things) // shouldn't be necessary eventually and we can safetly delete these few // lines. llvm::LLVMRustThinLTORemoveAvailableExternally(llmod); cgcx.save_temp_bitcode(&mtrans, "thin-lto-after-rm-ae"); timeline.record("no-ae"); </ins> Ok(mtrans) } }

Related discussion:
text: The tl;dr is that certain versions of llvm, (i've seen this on 3.8, and whatever llvm rustc nightly uses) appends seemingly random garbage to the end of some names, e.g. we get: instead of: This knocks the debuginfo out of sync (it doesn't have the garbage appended). I've been able to repro this with clang3.8 for c++ files as well (haven't tested on other llvm), and switching to 5.0 seems to have fixed the issue. I don't know if its within reach, but perhaps we should attempt upgrading to llvm 5.0 before releasing this on stable? Note I understand this is for release mode, but i see this in debug mode on rustc nightly right now as well...
Code change:
self_ty: Ty<'tcx>, sig: ty::PolyGenSig<'tcx>, ) -> ty::Binder<'tcx, (ty::TraitRef<'tcx>, Ty<'tcx>, Ty<'tcx>)> { <del> debug_assert!(!self_ty.has_escaping_bound_vars()); </del> <ins> assert!(!self_ty.has_escaping_bound_vars()); </ins> let trait_ref = tcx.mk_trait_ref(fn_trait_def_id, [self_ty, sig.skip_binder().resume_ty]); sig.map_bound(|sig| (trait_ref, sig.yield_ty, sig.return_ty)) }

Related discussion:
text: An there actually does panic for the test. I only moved this code between the files, the same comment and code pattern exists as well for normal closures: Originally posted by in
I couldn't repro this failure, maybe was doing instead of ? The ordering is important here.
I believe I did, yes.
Code change:
linker_flavor: LinkerFlavor::Ld, linker: Some("arm-none-eabi-ld".into()), asm_args: cvs!["-mthumb-interwork", "-march=armv4t", "-mlittle-endian",], <del> features: "+soft-float,+strict-align".into(), </del> <ins> // Force-enable 32-bit atomics, which allows the use of atomic load/store only. // The resulting atomics are ABI incompatible with atomics backed by libatomic. features: "+soft-float,+strict-align,+atomics-32".into(), </ins> main_needs_argc_argv: false, atomic_cas: false, has_thumb_interworking: true,

Related discussion:
text: If you try to compile the crate with , it fails with the following error: This seems to be a regression from to , and my best guess for the change that caused it is this pull request: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Filed to fix this. FYI, a short-term workaround is to enable the target feature (). claim
Possibly related: This is seen cross-compiling from Linux to Windows. Giant 1MB linker error message related to atomicload, only in release mode, for target x8664-pc-windows-gnu. Failing in rustc 1.67.1 stable. Currently asking for help comments; will file an issue in a day or two if nobody reports a known fix.
Since native atomic ops exist in x86_64, I don't believe this and are related to your problem. Given that rend3 has enabled , your problem may be related to
Code change:
<ins> // check-pass #![feature(generic_const_exprs)] #![allow(incomplete_features)] #![deny(const_evaluatable_unchecked)] pub struct If<const CONDITION: bool>; pub trait True {} impl True for If<true> {} pub struct FixedI8<const FRAC: u32> { pub bits: i8, } impl<const FRAC_LHS: u32, const FRAC_RHS: u32> PartialEq<FixedI8<FRAC_RHS>> for FixedI8<FRAC_LHS> where If<{ FRAC_RHS <= 8 }>: True, { fn eq(&self, _rhs: &FixedI8<FRAC_RHS>) -> bool { unimplemented!() } } impl<const FRAC: u32> PartialEq<i8> for FixedI8<FRAC> { fn eq(&self, rhs: &i8) -> bool { let rhs_as_fixed = FixedI8::<0> { bits: *rhs }; PartialEq::eq(self, &rhs_as_fixed) } } fn main() {} </ins>

Related discussion:
text: While checking whether the can be ported from typenum to nightly with , I hit this warning. I am not sure whether it's a false positive or whether the behavior I want is meant to be disallowed, but I think it should be allowed when enabling . I've reduced the code though I left some stuff to show why it would be useful. Originally posted by in
is emitted if we successfully evaluate an anonymous constant with generic const arguments. Anonymous constants currently inherit all of their parents generics, so for the constant has both and in scope, even though it only uses . This would mean that pretty much all anonymous constants would cause that lint, so we add a flag to their MIR to detect whether they actually use any generic parameter: uses so that flag is true. The problem is now that is concrete, so evaluating the constant is successful, but the constant refers to which is still generic. We should just disable the lint if is enabled :shrug: cc
Another similar. Short example failing on Nightly (thanks to ilyvion for narrowing it down): My use case: I know it's a semantic/voluntary constraint only, and it's quite recursive, but I believe it deserves its place. (Alternatives I tried are at )
this has been fixed, needs test to close
Code change:
#[stable(feature = "array_value_iter_impls", since = "1.40.0")] unsafe impl<T, const N: usize> TrustedLen for IntoIter<T, N> {} <ins> #[doc(hidden)] #[unstable(issue = "none", feature = "std_internals")] #[rustc_unsafe_specialization_marker] pub trait NonDrop {} // T: Copy as approximation for !Drop since get_unchecked does not advance self.alive // and thus we can't implement drop-handling #[unstable(issue = "none", feature = "std_internals")] impl<T: Copy> NonDrop for T {} #[doc(hidden)] #[unstable(issue = "none", feature = "std_internals")] unsafe impl<T, const N: usize> TrustedRandomAccessNoCoerce for IntoIter<T, N> where T: NonDrop, { const MAY_HAVE_SIDE_EFFECT: bool = false; } </ins> #[stable(feature = "array_value_iter_impls", since = "1.40.0")] impl<T: Clone, const N: usize> Clone for IntoIter<T, N> { fn clone(&self) -> Self {

Related discussion:
text: <!-- 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: same codegen or similar in performance Instead, this happened: array has way worse codegen <details<summaryAssembly</summary<p</p</details<!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.64 <!-- Provide the version you are using that has the regression. --65 till now. Regressed in nightly-2022-08-13, maybe LLVM 15 ?: : <!-- 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-stable -regression-untriaged <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
WG-prioritization assigning priority (). cc since this regressed in the LLVM 15 update label -I-prioritize +P-medium +T-compiler
I've seen llvm doing these strange 1-byte-at-a-time "vectorizations" in other places too. This might be a more general problem. In this case we can probably paper over it by implementing TrustedRandomAccess for the array iter.
Unfortunately, the array iterator is fundamentally worse right now, because indexing into it -- a fundamental part of being a by-value array iterator -- keeps it from SRoAing and thus doesn't optimize well. This is why when I was making better I ended up making to not have to use . Sadly, for the foreseeable future you're better off using the "weaker" slice iterator when you can.
My guess is that the SROA is missing something in the opaque pointer mode.
Code change:
#[stable(feature = "array_value_iter_impls", since = "1.40.0")] unsafe impl<T, const N: usize> TrustedLen for IntoIter<T, N> {} <ins> #[doc(hidden)] #[unstable(issue = "none", feature = "std_internals")] #[rustc_unsafe_specialization_marker] pub trait NonDrop {} // T: Copy as approximation for !Drop since get_unchecked does not advance self.alive // and thus we can't implement drop-handling #[unstable(issue = "none", feature = "std_internals")] impl<T: Copy> NonDrop for T {} #[doc(hidden)] #[unstable(issue = "none", feature = "std_internals")] unsafe impl<T, const N: usize> TrustedRandomAccessNoCoerce for IntoIter<T, N> where T: NonDrop, { const MAY_HAVE_SIDE_EFFECT: bool = false; } </ins> #[stable(feature = "array_value_iter_impls", since = "1.40.0")] impl<T: Clone, const N: usize> Clone for IntoIter<T, N> { fn clone(&self) -> Self {

Related discussion:
text: claim
It's not about vectorization. This optimization can be restored by using . But highly unrecommended. Upstream issue:
The upstream issue is closed. claim
Code change:
let r = match datum.ty.sty { ty::ty_uniq(content_ty) => { <ins> // Make sure we have an lvalue datum here to get the // proper cleanups scheduled let datum = unpack_datum!( bcx, datum.to_lvalue_datum(bcx, "deref", expr.id)); </ins> if type_is_sized(bcx.tcx(), content_ty) { <del> deref_owned_pointer(bcx, expr, datum, content_ty) </del> <ins> let ptr = load_ty(bcx, datum.val, datum.ty); DatumBlock::new(bcx, Datum::new(ptr, content_ty, LvalueExpr)) </ins> } else { // A fat pointer and a DST lvalue have the same representation // just different types. Since there is no temporary for `*e` // here (because it is unsized), we cannot emulate the sized // object code path for running drop glue and free. Instead, // we schedule cleanup for `e`, turning it into an lvalue. <del> let datum = unpack_datum!( bcx, datum.to_lvalue_datum(bcx, "deref", expr.id)); </del> let datum = Datum::new(datum.val, content_ty, LvalueExpr); DatumBlock::new(bcx, datum)

Related discussion:
text: Rust compiler (rustc 1.1.0-nightly ( 2015-05-14) (built 2015-05-14) fails to compile this source: With the error: I can reproduce this ICE also on
Reduced it a bit:
The broken IR:
Looking through it quickly, it seems like the order of the cleanups is messed up? If is then from the switch we go to the label which just jumps to where we memcpy the value for into the alloca and then continue to the label. This is where the problem is since it tries to call on the value returned from . But that's the thing, we wouldn't have called in that arm of the branch and hence shouldn't need to call free either.
Adding a block around suppresses the error. I feel like we had a similar problem not too long ago.
This is "caused" by the micro optimization for dereferencing owned pointer rvalues in . Since is the "trailing" expression for the arm its cleanup will be scheduled in the same scope as the match expression. cc
Either way, this is a dupe of I believe had an idea for a fix.
it's simple, we remove the micro-optimization and always return an datum from . The possibility of returning datum also caused issues with field accesses - see for that fix. We have a static type system and the / marker types are there for a reason. If there is no answer to "how is an rvalue dereference or field meaningful?", then the return type for both of those should be .
Code change:
let r = match datum.ty.sty { ty::ty_uniq(content_ty) => { <ins> // Make sure we have an lvalue datum here to get the // proper cleanups scheduled let datum = unpack_datum!( bcx, datum.to_lvalue_datum(bcx, "deref", expr.id)); </ins> if type_is_sized(bcx.tcx(), content_ty) { <del> deref_owned_pointer(bcx, expr, datum, content_ty) </del> <ins> let ptr = load_ty(bcx, datum.val, datum.ty); DatumBlock::new(bcx, Datum::new(ptr, content_ty, LvalueExpr)) </ins> } else { // A fat pointer and a DST lvalue have the same representation // just different types. Since there is no temporary for `*e` // here (because it is unsized), we cannot emulate the sized // object code path for running drop glue and free. Instead, // we schedule cleanup for `e`, turning it into an lvalue. <del> let datum = unpack_datum!( bcx, datum.to_lvalue_datum(bcx, "deref", expr.id)); </del> let datum = Datum::new(datum.val, content_ty, LvalueExpr); DatumBlock::new(bcx, datum)

Related discussion:
text: Original testcase by (reduced from ): The debug log reveals that a (shallow free) cleanup of the rvalue is scheduled in the scope of AST node , while the dereference expression itself has id : reveals that id refers to the entire function's block: This means the cleanup of a value valid only within a match arm is scheduled outside the arm. cc
Dupe of Leaving open for now but we can close either.
This is caused by a micro-optimization specific to dereferences of rvalues. Is this used oftenly enough to justify its existence in the first place? Even if it is, I guess we can disable it in problematic cases like this, where the temporary scope of the match arm's RHS is outside the arm.
I think we can probably remove it, in general removing special treatment of seems like a Good Thing
Triage: this still ICEs.
can you point me/us at the micro-optimization that you mentioned above, so that I (we) can try removing it ourselves and measure the impact?
I only vaguely recall this issue, but I'm pretty sure I was talking about .
triage: still ICEs.
Indeed, it doesn't even need : Does this at least continue to ICE even if LLVM is compiled without assertions? If not, we may want to up the priority on this ticket.
Code change:
/// # Examples /// /// ``` <del> /// format!("test"); /// format!("hello {}", "world!"); /// format!("x = {}, y = {y}", 10, y = 30); </del> <ins> /// format!("test");                             // => "test" /// format!("hello {}", "world!");               // => "hello world!" /// format!("x = {}, y = {val}", 10, val = 30);  // => "x = 10, y = 30" </ins> /// let (x, y) = (1, 2); <del> /// format!("{x} + {y} = 3"); </del> <ins> /// format!("{x} + {y} = 3");                    // => "1 + 2 = 3" </ins> /// ``` #[macro_export] #[stable(feature = "rust1", since = "1.0.0")]

Related discussion:
text: I was sent here from the . Please advise if I am posting in the wrong area. format! macro documentation could be improved by changing one of the examples to be more obvious to new users. Change the example to Additionally, assert! could be used to demonstrate final string values: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Something like ? claim
I think the use of "val" certainly makes it more obvious than my suggestion to use "z". Your suggestion would also do it in one line... I guess the question is whether you would prefer to make it more obvious (readable) by splitting it into two lines. This is my first contribution to Rust in any form, so I'm happy to go with your suggestion.
Thanks all!
Code change:
_ => unreachable!(), }; <del> write_or_print(&out, ofile); </del> <ins> write_or_print(&out, ofile, sess); </ins> } pub fn print_after_hir_lowering<'tcx>(

Related discussion:
text: If you , you get a normal error like but if you try to at the same time: rust will panic which is a bit weird. Mayne that panic should be demoted to a regular error? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
To reproduce: `
claim