jiebi/CodeConvo huggingface dataset:
Code change:
_marker: PhantomData<&'f mut &'f c_void>, } <ins> /// s390x ABI implementation of a `va_list`. #[cfg(target_arch = "s390x")] #[repr(C)] #[derive(Debug)] #[unstable( feature = "c_variadic", reason = "the `c_variadic` feature has not been properly tested on  all supported platforms", issue = "44930" )] #[lang = "va_list"] pub struct VaListImpl<'f> { gpr: i64, fpr: i64, overflow_arg_area: *mut c_void, reg_save_area: *mut c_void, _marker: PhantomData<&'f mut &'f c_void>, } </ins> /// x86_64 ABI implementation of a `va_list`. #[cfg(all(target_arch = "x86_64", not(target_os = "uefi"), not(windows)))] #[repr(C)]

Related discussion:
text: fails this test on native : (This is not a new failure, but I am cleaning up issues from downstream Red Hat bugzilla.)
We started discussing this in , and looking at the clang implementation here: I tried that minimal step with , but it still gives the same "Cannot select" error. I don't see any lowering of in like other targets, only stuff implementing the calling convention. So I guess we do need custom support, or perhaps the clang bits could be moved down into the LLVM lowering?
Hi , I ran into the same problem and noticed you had already opened an issue. I've now submitted a PR to implement valist and vaarg for s390x to fix this.
Code change:
// memmove back untouched tail, update to new length let start = source_vec.len(); let tail = self.tail_start; <del> let src = source_vec.as_ptr().offset(tail as isize); let dst = source_vec.as_mut_ptr().offset(start as isize); ptr::copy(src, dst, self.tail_len); </del> <ins> if tail != start { let src = source_vec.as_ptr().offset(tail as isize); let dst = source_vec.as_mut_ptr().offset(start as isize); ptr::copy(src, dst, self.tail_len); } </ins> source_vec.set_len(start + self.tail_len); } }

Related discussion:
text: The build time of html5ever has gone up by more than 70% for debug builds recently: There are quite a few candidates for introducing this regression in the changeset: Would anybody from or care to bisect further?
The "tuple stress" benchmark is affected even more while most of the other things have improved. Maybe that gives a hint?
My first guess would be quadratic or exponential blowup. Maybe someone can do a ?
Yes, good idea!
Bisection for tuple-stress points to (cc Before that PR took ~4s and afterwards I killed it after 2m as I didn't want to wait for it to finish
That may also be the source of the html5ever regression. takes 10s before that commit (the entire time) and 21s afterwards.
Thanks, cc also &
Could you post instructions for replicating the slow down? Neither or I could reproduce it -- despite running perf on the appropriate commit range locally.
So should we revert that PR's commits?
sure yeah, using I did the equivalent of:
We should probably only run the disaggregation pass if the opt level is 1. That's what's done for the copy prop pass already
assuming and can reproduce I think yeah we'll probably want to start off by reverting and possibly doing what suggests in a follow-up
I cannot reproduce, which is odd, since I can't tell what the difference could be that would make this much of a difference...
No repro on macOS, although the c116 version is consistently slower than a272. <details</details
Ok I swear I'm not going crazy! I think though given this data it may only be reproducible on Ubuntu 16.04? I can reproduce with this : Can y'all reproduce the slowdown for html5ever?
Sure enough starting the docker image from 18.04 means I cannot reproduce the regression. Maybe some glibc bug was fixed which I was accidentally running into? The html5ever regression though is still worrisome and seems like it may not be connected to a glibc bug
I can repro the tuple-stress slow down on 16.04.4 LTS. indicates it is stuck at the step.
Code change:
// memmove back untouched tail, update to new length let start = source_vec.len(); let tail = self.tail_start; <del> let src = source_vec.as_ptr().offset(tail as isize); let dst = source_vec.as_mut_ptr().offset(start as isize); ptr::copy(src, dst, self.tail_len); </del> <ins> if tail != start { let src = source_vec.as_ptr().offset(tail as isize); let dst = source_vec.as_mut_ptr().offset(start as isize); ptr::copy(src, dst, self.tail_len); } </ins> source_vec.set_len(start + self.tail_len); } }

Related discussion:
text: <details<summaryGDB backtrace sample</summary</details<details<summaryCode surrounding the call of that memmove</summary</details
Presuming the same two commits would be responsible for the html5ever regression, I also cannot reproduce it on 18.04 Ubuntu.
Using this dockerfile: I can reproduce the regression from 10s to 20s on html5ever. Starting from 18.04 it does indeed not show a regression. The perf server is indeed 16.04. Ok so it looks like this is a regression specific to something that changed between glibc 2.23 and 2.27. With the profiles it looks like it's something related to the efficiency of memcpy/memmove. It also seems like this isn't reproducible on OSX (thanks ). I can, however, reproduce it locally on Windows 64-bit MSVC. Since could reproduce a slightly slowdown on OSX, I wonder if these code paths do something like exercise a ton of moves? It may be the case that glibc optimized one of its routines in the 2.23 -2.27 transition (and OSX already had it). In that case it may appear like there's no regression on Linux/OSX but on glibc 2.23 and Windows they may have unoptimized versions of the routines causing slowdowns. All in all I think that this is a regression that is still worth fixing, despite it not immediately being applicable on glibc 2.27 or OSX. The fact that it affects somewhat-recent versions of Ubuntu and Windows is enough for me.
Isn't glibc 2.27 the version released after the spectre/meltdown/whatever fixes that slow (primarily Intel but to a lesser extent AMD as well) systems down?
No sorry glibc 2.27 is just what I tested. I've now narrowed it down (conveniently) to glibc 2.23 and 2.24. Ubuntu 16.04 ships with 2.23 and 16.10 ships with 2.24. On 2.24 I'm seeing a faster compilation Perusing the it looks like may be why we're not seeing the regression in newer Linux
Ok I've found the source of the regression, will post a PR soon.
It's a pleasure watching you folks work!
Code change:
// memmove back untouched tail, update to new length let start = source_vec.len(); let tail = self.tail_start; <del> let src = source_vec.as_ptr().offset(tail as isize); let dst = source_vec.as_mut_ptr().offset(start as isize); ptr::copy(src, dst, self.tail_len); </del> <ins> if tail != start { let src = source_vec.as_ptr().offset(tail as isize); let dst = source_vec.as_mut_ptr().offset(start as isize); ptr::copy(src, dst, self.tail_len); } </ins> source_vec.set_len(start + self.tail_len); } }

Related discussion:
text: I've posted what I believe is a fix to
triage: P-high Has pending fix.
Code change:
// if a test does not crash, consider it an error if proc_res.status.success() || matches!(proc_res.status.code(), Some(1 | 0)) { self.fatal(&format!( <del> "crashtest no longer crashes/triggers ICE, horray! Please give it a meaningful name,  add a doc-comment to the start of the test explaining why it exists and  move it to tests/ui or wherever you see fit. Adding 'Fixes #<issueNr>' to your PR description  ensures that the corresponding ticket is auto-closed upon merge." </del> <ins> "crashtest no longer crashes/triggers ICE, horray! Please give it a meaningful  name, add a doc-comment to the start of the test explaining why it exists and  move it to tests/ui or wherever you see fit. Adding 'Fixes #<issueNr>' to your PR  description ensures that the corresponding ticket is auto-closed upon merge.  If you want to see verbose output, set `COMPILETEST_VERBOSE_CRASHES=1`." </ins> )); } }

Related discussion:
text: E.g. if a test doesn't have a fn it can prevent the test from ICEing because ICEing codepath might not yet be reached before compilation is aborted. In this case, the stderr should be printed to help the person figure out that "I forgor to annotate crate type" is the cause.
you can set env var which should print stdout, stderr and exit code
Oh right, good point, I forgor this existed. We should (I'll do this later unless you want to work on it): Mention this env var in the panic message for when the crashes test no longer crash. () Mention this env var in rustc-dev-guide. () EDIT: ended up duplicating some description of ` in because I would not have thought to look there for docs specifically.
Code change:
// not covered via the Shared impl above b/c the inner contents use // Cell/AtomicUsize, but the usage here is recover safe so we can lift the // impl up one level to Arc/Rc itself <del> impl<T: NoUnsafeCell + ?Sized> RecoverSafe for Rc<T> {} impl<T: NoUnsafeCell + ?Sized> RecoverSafe for Arc<T> {} </del> <ins> impl<T: RefRecoverSafe + ?Sized> RecoverSafe for Rc<T> {} impl<T: RefRecoverSafe + ?Sized> RecoverSafe for Arc<T> {} </ins> <del> // Pretty simple implementations for the `NoUnsafeCell` marker trait, basically // just saying that this is a marker trait and `UnsafeCell` is the only thing // which doesn't implement it (which then transitively applies to everything // else. impl NoUnsafeCell for .. {} impl<T: ?Sized> !NoUnsafeCell for UnsafeCell<T> {} </del> <ins> // Pretty simple implementations for the `RefRecoverSafe` marker trait, // basically just saying that this is a marker trait and `UnsafeCell` is the // only thing which doesn't implement it (which then transitively applies to // everything else. impl RefRecoverSafe for .. {} impl<T: ?Sized> !RefRecoverSafe for UnsafeCell<T> {} impl<T> RefRecoverSafe for AssertRecoverSafe<T> {} </ins> impl<T> AssertRecoverSafe<T> { /// Creates a new `AssertRecoverSafe` wrapper around the provided type.

Related discussion:
text: The PR is in but'll take a few hours at least to land.
the problem with moving at this point in time is that I call in different branches of a but I pass the same closed-over value to it; I can't do the branch in the closure because I need to do some FFI cleanup afterwards regardless of whether a panic happened or not (which also requires the closed-over value). It would help if derived and/or so I could reuse it without constructing a new value for each arm, but that would probably require some discussion because I don't know if it's safe or not. I'll probably just implement and fix the name after your PR drops. A quick check confirms that it works just fine. Thanks anyways!
Oh yeah we could totally add more traits like and to , there shouldn't be any safety concerns there.
Updating code to modern functions and traits in makes this compile, so I'm going to close.
Code change:
builder.install(&exe, &dst_bindir, 0o755); } <ins> // Copy libLLVM.so to the target lib dir as well, so the RPATH like // `$ORIGIN/../lib` can find it. It may also be used as a dependency // of `rustc-dev` to support the inherited `-lLLVM` when using the // compiler libraries. maybe_install_llvm_target(builder, target, &image); </ins> // Prepare the overlay let overlay = tmp.join("llvm-tools-overlay"); drop(fs::remove_dir_all(&overlay));

Related discussion:
text: Since , has been distributed in the component in two locations: (presumably as a runtime dependency of ) (not sure, maybe for linking custom drivers?) likely belongs in the component, if the duplication can't be avoided <hr/The difference can be seen in these consecutive nightlies' components: has just the second maybe it's used via relative by ? separate codegen backends are gone, maybe we should just try removing it? first nightly to include has both copies All 3 of those files are identical (even across nightlies, yay for deterministic builds): One fascinating aspect is that the size only increases from to , despite alone being uncompressed, so compression is really helping. Even the only goes from to . (I'm using archive sizes from the and directory listings in , FWIW) <hr/This part of the build system seems relevant, but I'm not sure which of the two this creates: cc
cc -- you've touched code related to this a bunch recently I think, so maybe would have some time to investigate fixing this. I suspect we want to only ship one LLVM per tarball, at least, though ideally we would only have just the one LLVM library total as well.
Half-way through writing up this issue I realized the connection. I'd suggest we try to get rid of the copy and see what breaks, it's possible it's been dead weight for a while now. And only if we have to keep both for some odd reason, we'd move it to .
The purposely orders the tarred files so that similar filenames are adjacent in the compression stream, especially in hope of helping with such duplicate files. I think we may still want the copy for the odd cross-compiled tool using , but that definitely belongs in .
Is that... even possible? Is a per-target component in the same way is?
Yes it is -- try -- but I don't know if anyone really needs that...
Actually, can you try something like cross-compiling a copy of to , after deleting the per-target ? I suspect that it would actually run just fine on a host, because 's s should only really contain the information and maybe some object code that is missing (which we could get rid of if we kept MIR for everything but idk how feasible that is). That is, the result of linking against should still use at runtime, so in is unnecessary. But maybe I'm missing something.
Code change:
builder.install(&exe, &dst_bindir, 0o755); } <ins> // Copy libLLVM.so to the target lib dir as well, so the RPATH like // `$ORIGIN/../lib` can find it. It may also be used as a dependency // of `rustc-dev` to support the inherited `-lLLVM` when using the // compiler libraries. maybe_install_llvm_target(builder, target, &image); </ins> // Prepare the overlay let overlay = tmp.join("llvm-tools-overlay"); drop(fs::remove_dir_all(&overlay));

Related discussion:
text: Like running the cross-compiled on a host without anything more than the component?
Hmm, I can't actually get cross-builds to work with . I this to : ... so it would pick that up from the sysroot. Trying to cross-compile i686, I get: I do have both i686 and x8664 builds of in the sysroot. I suspect the error is because the i686 build has different metadata than my host build, so it can't find the one it wants for the host. That may mean that is really tied to being used on the same host. It works if I just compile native x86_64 though. Then I tried removing the , and it gets essentially the same error as : AFAICS, building normal crates still works fine with that extra removed though. In short: Cross-compiling with seems broken -- maybe it should be shipped native-only. The only difference would be in the manifest created for rustup. Linking to crates will inherit , so that needs to be in the library path.
Ah, fascinating. What happens if you build such an executable and then remove the component entirely? Can it pick up the dylibs outside or does it hardcode the paths inside?
The final executable still isn't actually linked to LLVM, since it didn't need any of those symbols: I can run this with , which set , or even if I set that path myself. But doesn't work if we've removed that library, since needs itself.
Okay, it being dependent on makes sense. Overall, probably the safe thing to do would be to move the duplicate to , oh well.
Oh, also needs LLVM, and those binaries are installed in with RUNPATH . I guess they might be able to find the LLVM in anyway?
Code change:
COMPILE_FLAGS=-O -Ccodegen-units=1 -Cprofile-generate="$(TMPDIR)" <del> # LLVM doesn't yet support instrumenting binaries that use unwinding on MSVC: # https://github.com/rust-lang/rust/issues/61002 # # Things work fine with -Cpanic=abort though. ifdef IS_MSVC COMPILE_FLAGS+= -Cpanic=abort endif </del> all: $(RUSTC) $(COMPILE_FLAGS) --emit=llvm-ir test.rs # We expect symbols starting with "__llvm_profile_".

Related discussion:
text: LLVM's "IR-level" instrumentation, which is used by to generate PGO instrumented binaries, does not yet work with exception handling on Windows MSVC. The problem has been reported to LLVM for C++ here: This also affects Rust programs built with for Windows MSVC. As long as LLVM does not support exception handling there, it is a known limitation that PGO can only be used with on this platform.
PGO does not yet work on for other reasons (see ). Once it does, we should check if this problem is specific to MSVC.
I have working x86_64 windows-gnu (64 bit builds use SEH) build with PGO I'll open PR once is merged. I can do testing in meantime. FWIW simple hello world example works fine after going through PGO.
if you test, be sure to compile your LLVM with assertions: Thanks for looking into it!
I'll recompile it with assertions today later. Should the test case be using any specific code like ?
The following test case runs into the problem with MSVC: See for how the file is compiled.
It does not reproduce with gnu toolchain with Rust and LLVM assertions enabled, I'll try to remember about fixing along with gnu profiler.
Cool!
I just confirmed that (for me locally) PGO seems to work on Windows GNU. That is, I built with instrumentation, ran it, and rebuilt it with the profiling data collected. It worked just fine, no crashes. So I updated the original issue text to just mention MSVC instead of Windows in general.
It looks like is a bit too aggressive with its error reporting. For example when invoking rustc, but not compiling in our Firefox build we can the following : I'm not sure the best solution while mw is away; perhaps we should revert for now.
Maybe we can just convert the error to a warning?
Not the best long-term solution but seems ok
It looks like the was marked fixed a year ago. What's the status of this issue in rustc?
Code change:
} }; <del> bfs_queue.push_back(DefId { krate: cnum, index: CRATE_DEF_INDEX }); </del> while let Some(def) = bfs_queue.pop_front() { for child in tcx.item_children(def).iter() { add_child(bfs_queue, child, def);

Related discussion:
text: On nightly rustc (cargo) I get misleading expected type errors. If a crate has the same(?) type it is displayed instead of the std type. I tried this code: I expected to see this happen: (stable rust) Instead, this happened: (nightly) :
Confirming - broken on nightly (1.23), good on beta.
bisected across nightlys: bug was injected between and
Skimming output from , there are a number of different potential culprits. Rather than guess and "point fingers" right now, I'll just continue bisecting within that commit range.
This is recent enough that we should be able to run bisect-rust on it (cc
it is cc .
I'm a little surprised that this would be caused by that PR. I can push a revert but would like to first test locally to make sure that revert that PR will fix this.
I have misread 's statement. Your PR is not at fault, sorry. I'm doing another search further back to find the causing PR.
I tried it locally in the meantime and I can confirm it is not :)
Okay so the bug dates as far back as from September 2nd which is as close to the limit as I dare to go. So to the people in control, please, prolong the limit :).
suggests that the bug was introduced much more recently (11-08 to 11-09). Maybe the bisection script was wrong?
I should probably have read the original issue more closely :). sorry for pinging you! It seems to be cc
In particular, I have bisected it down to the commit: I have been trying to further dissect that commit to figure out why it causes the change we observe here. My current hypothesis (that I have not yet managed to confirm) is that it has to do with how we seed the hashmap's hashers with randomized state. (This commit changes our behavior in certain scenarios.) If this hypothesis is actually true, though, then I would think that this represents either a bug in hashmap itself, or a bug in how the compiler is using the hashmap...
Hmm. Its something more subtle than a hashmap-related bug.
Code change:
} }; <del> bfs_queue.push_back(DefId { krate: cnum, index: CRATE_DEF_INDEX }); </del> while let Some(def) = bfs_queue.pop_front() { for child in tcx.item_children(def).iter() { add_child(bfs_queue, child, def);

Related discussion:
text: In particular, I can reproduce the old behavior on master by just linking in the old crate into (in addtion to linking in the one from ; doing this requires changing the name of the old ), without making any actual calls into the old crate. That, to me, seems very strange. I'm now trying to reduce down the size of the crate that I am linking in (while still causing this delta in behavior).
triage: P-high
I still get a non std types in erros when the path has the same length. That would be okay if it is somehow deterministic, but I get different type errors within the same file for the same types.
is that a regression from the stable channel? While I absolutely agree that a deterministic result would be better (and better stilll, a deterministic result that favored minimal-length paths rooted at ), I want to triage this appropriately.
Hmm I guess since is the person who filed the original ticket then it is reasonable to infer that they are indeed seeing the described regression compared to the stable channel.
gives me: seems to work now: Maybe this was some sort of partial compile cache issue? I haven't found a way to reproduce these mixed errors yet.
This looks like a duplicate of . That issue has some repro cases that affect the 1.22.1 stable compiler but not 1.21.0.
When I bisected the nightlies by hand on I ended up with a range (...) that does not include the commit identified here. Is it possible that the nondeterministic nature of the bug is also messing with our attempts to bisect? I wonder whether merely linking affects in the same way as it affected this issue.
Any evidence of this problem existing with the newest nightly?
All the cases I tried seem to have been fixed by and . Nicely done! I reported one follow-up in .
Code change:
<ins> // This is a non-regression test for issue #127052 where unreferenced `#[used]` statics couldn't be // removed by the MSVC linker, causing linking errors. //@ build-pass: needs linking //@ only-msvc #[used] static FOO: u32 = 0; fn main() {} </ins>

Related discussion:
text: I tried this code: I expected to see this happen: Compiles successfully. Instead, this happened: Fails with this error: nightly-2024-06-26 and earlier. nightly-2024-06-27 and later, starting with . See for a discussion of the issue. : cc
To elaborate, the difference is in symbols.o. Here's a dump of symbols.o before the change: And here's after: Spot the difference. Spoiler: is now present.
So is that right or wrong? The static is "used" so marking it exported to ensure it does not get optimized away seems to make sense? I don't understand why this is a problem only on Windows.
Well that's not a problem per se but if we want to do that then we have to do it properly. is defined as a in (on my machine). This is linked directly and not in a lib file. So it's already being included. There's no reason for to include it. The only issue is that is being emitted as a comdat, meaning the linker is still allowed to remove it. We could just not do that (or add a linker directive). But that's a pre-existing issue.
I don't understand any part of that.^^ Should my PR get reverted or is there a better way to fix this regression? If there is a better way, I am afraid I lack the knowledge to implement and test it. I don't understand symbol handling on Linux, let alone on Windows.
I don't know enough about the Rust compiler to say. My complete guess would be that was silently broken before but now it's nosily broken.
Hm, who would understand our Windows linking story? ?
After CGU partitioning, we try to internalize symbols when possible. What is surprising to me is that this process only looks at export level, ignoring used attribute (in the contrast to say the internalization during fat LTO). Consequently we have a situation where synthetic object file references a symbol that is no longer exported (on Linux that does not result in a linking error, even though reference is unresolved). Anyway, if the consequence of would be to export those symbols for no reason, that seems rather counter productive to me.