jiebi/CodeConvo huggingface dataset:
Code change:
COPY build-emscripten.sh /tmp/ RUN ./build-emscripten.sh ENV PATH=$PATH:/tmp/emsdk_portable <del> ENV PATH=$PATH:/tmp/emsdk_portable/clang/tag-e1.37.1/build_tag-e1.37.1_32/bin </del> <ins> ENV PATH=$PATH:/tmp/emsdk_portable/clang/tag-e1.37.10/build_tag-e1.37.10_32/bin </ins> ENV PATH=$PATH:/tmp/emsdk_portable/node/4.1.1_32bit/bin <del> ENV PATH=$PATH:/tmp/emsdk_portable/emscripten/tag-1.37.1 ENV EMSCRIPTEN=/tmp/emsdk_portable/emscripten/tag-1.37.1 </del> <ins> ENV PATH=$PATH:/tmp/emsdk_portable/emscripten/tag-1.37.10 ENV EMSCRIPTEN=/tmp/emsdk_portable/emscripten/tag-1.37.10 </ins> ENV RUST_CONFIGURE_ARGS --target=asmjs-unknown-emscripten

Related discussion:
text: It seems like that could be a big effort. Another alternative is to use the LLVM wasm backend, but I still have not heard that it is generally usable yet. cc
I can look into the effort needed to update emscripten's fastcomp LLVM version, but I need to know a commit to aim for. Sounds like the goal here is 4.0, which hasn't released yet, so I guess I have to wait on that?
So far as AVR is concerned, any commit within the last month will do. There will likely be a few more months until 4.0 is actually tagged (every ~6 months a new release is made). It is quite common for projects to track LLVM master, which I'm personally a fan of.
But is it common to release snapshots from LLVM master? When LLVM itself only releases every 6 months, it seems incongruous for Rust to pick arbitrary snapshots in its 6-week release cycle.
LLVM 4.0 will branch in a week and the final release will happen in late feburary (schedule says 21st for final tag, but this is flexible IIRC).
From the llvm-dev mailing list:
branch has happened
An update on the "powidf2 / powisf2 calling convention changed" situation: The regression has been fixed on llvm master () however from what I can tell the fixes are not yet in the 4.0 branch, although the fix may be backported ().
I've started working on updating emscripten kripken/emscripten-fastcomp kripken/emscripten-fastcomp-clang I've also created a new bug requesting that the regression fix be merged into 4.0 .
says the emcc LLVM upgrade is ready to go. or are we prepared to begin the Rust LLVM upgrade? I think what needs to happen is to submit the Rust PR and start throwing it against the bots. Once it looks like that is close to landing then we'll have to coordinate both project's upgrades to minimize the breakage window where rustc and emcc have different backends. I'm not sure how best to do that - we might just try to upgrade as simultaneously as possible and accept up to a few days of breakage, or we might ask emscripten to stage their build such that they can swap their incoming branch right after we land to master.
Code change:
COPY build-emscripten.sh /tmp/ RUN ./build-emscripten.sh ENV PATH=$PATH:/tmp/emsdk_portable <del> ENV PATH=$PATH:/tmp/emsdk_portable/clang/tag-e1.37.1/build_tag-e1.37.1_32/bin </del> <ins> ENV PATH=$PATH:/tmp/emsdk_portable/clang/tag-e1.37.10/build_tag-e1.37.10_32/bin </ins> ENV PATH=$PATH:/tmp/emsdk_portable/node/4.1.1_32bit/bin <del> ENV PATH=$PATH:/tmp/emsdk_portable/emscripten/tag-1.37.1 ENV EMSCRIPTEN=/tmp/emsdk_portable/emscripten/tag-1.37.1 </del> <ins> ENV PATH=$PATH:/tmp/emsdk_portable/emscripten/tag-1.37.10 ENV EMSCRIPTEN=/tmp/emsdk_portable/emscripten/tag-1.37.10 </ins> ENV RUST_CONFIGURE_ARGS --target=asmjs-unknown-emscripten

Related discussion:
text: needs to know the exact LLVM commit we're moving to as well, and that will become clear once the PR starts working through the queue. The stars are aligning. Let's make this happen. Thanks for doing the fastcomp upgrade.
We are not fully compatible with LLVM 4.0. I have heard from at least one person (on IRC) that building against stock LLVM 4.0 (RC) does not work. I haven't personally inspected all failures, but there's at least two things still missing: (and possibly ). It shouldn't be a conceptually difficult patch to apply the equivalent changes to rustc, but possibly a big diff. I haven't digested the implications yet, but it might be a relatively simple change localized to the function in that currently calls .
The fix has been merged into the 4.0 release (). I'm going to try and build Rust against stock LLVM 4.0 and figure out what needs modifying.
On top of what mentioned: now takes an instead of a and ()
I've got a half-baked patch to use the new signature for I'm not familiar enough with Rust internals to finish it off. I ran into a problem in as it is given a but in order to use we need a . We need to call in order to build an instance of .
I've opened for the change that mentioned. I've also opened for the 32-bit alignment change. I believe that is the only thing we need to update aside from these two PRs in order to get the compiler to successfully be built with LLVM 4.0.
So to summarize where we are with LLVM 4 (correct me if I'm wrong): 4.0 will be released in about 1 week (2/21). are no known issues with supporting LLVM 4.0, but there are probably issues that will be discovered once we try to use it in nightlies. runs on in-tree LLVM + LLVM 3.7 (so PRs haven't actually been tested on LLVM 4.0 yet). support LLVM back to ~3.6(?
Code change:
COPY build-emscripten.sh /tmp/ RUN ./build-emscripten.sh ENV PATH=$PATH:/tmp/emsdk_portable <del> ENV PATH=$PATH:/tmp/emsdk_portable/clang/tag-e1.37.1/build_tag-e1.37.1_32/bin </del> <ins> ENV PATH=$PATH:/tmp/emsdk_portable/clang/tag-e1.37.10/build_tag-e1.37.10_32/bin </ins> ENV PATH=$PATH:/tmp/emsdk_portable/node/4.1.1_32bit/bin <del> ENV PATH=$PATH:/tmp/emsdk_portable/emscripten/tag-1.37.1 ENV EMSCRIPTEN=/tmp/emsdk_portable/emscripten/tag-1.37.1 </del> <ins> ENV PATH=$PATH:/tmp/emsdk_portable/emscripten/tag-1.37.10 ENV EMSCRIPTEN=/tmp/emsdk_portable/emscripten/tag-1.37.10 </ins> ENV RUST_CONFIGURE_ARGS --target=asmjs-unknown-emscripten

Related discussion:
text: )~ 3.7 and will continue to support it until either: a. It's so old that it can be removed without bothering package maintainers b. We need at least version X in order to fix an important bug c. The API is so different from version Y that it's a huge pain to support will open a PR to update the submodule shortly after release but it will take a month to land due to: a. Waiting for emscripten ( -) b. Bugs in upstream c. Missed LLVM API changes d. Making bors happy e. All of the above
Thanks for the summary The only correction I'd make is that in your point (4) you can s/3.6/3.7/, but otherwise it's accurate :) If you'd like to start preparing a PR to update to LLVM 4.0 I don't think we need to block waiting for LLVM itself to release 4.0. Currently only one Travis builder runs on each PR but we could temporarily allow more builders running on an LLVM 4.0 PR to start weeding out bugs before it hits
I gave it a go but I don't think my git-fu (or patience) is strong enough to handle a big merge like this. What I can do is try to run rustc with upstream LLVM and file/fix issues as I find them. There is at least one issue remaining as of (details to come).
Whoever ends up doing the LLVM upgrade, please also upgrade the compiler-rt submodule so that the sanitizer related LLVM passes don't diverge from what the sanitizer runtimes expect.
In fact, if you upgrade before the release, they usually mention your project in the release notes. :)
So whats the next issue(s) to subscribe to in the race-to-AVR? :)
As says on , we can integrate the latest Rust master into the avr-rust compiler. After that, we can spend some time getting compiling for AVR. Once that is working, we could then start looking into upstreaming the AVR target to Rust.
AVR-specific issues can be raised / tracked in For example, there are two that I'm aware of right now:
has been closed, so that can be checked off in the top post.
Code change:
rm -rf /tmp/rustc-pgo <del> python3 ../x.py build --target=$PGO_HOST --host=$PGO_HOST  </del> <ins> python2.7 ../x.py build --target=$PGO_HOST --host=$PGO_HOST  </ins> --stage 2 library/std --rust-profile-generate=/tmp/rustc-pgo ./build/$PGO_HOST/stage2/bin/rustc --edition=2018 

Related discussion:
text: When I install the latest master toolchains via and try to build with them, linking fails: I did some bisection, and it looks like the problem started happening with Cc
The error is actually already mentioned in However, I am building Miri with cargo, so I don't know how I'd "use LLD instead".
Hm, we probably need to revert that PR. I did not realize we'd need lld downstream too, I thought that was only on our builder. cc
Yes, a revert seems appropriate. We're going to have to figure out where that's actually coming from. The only change I saw between 10 and 11 by grepping was the removal of llgo, but maybe there's some bad remnant.
Yeah, I thought this issue would be limited to the rustc build, but it makes sense that it can also affect project linking against rustc shared objects. I've looked a bit into what the root cause is, and what I have so far as that the symbol comes from and is present as a weak symbol both when compiling with clang-10 and clang-11. The only difference I see from is this: So apparently was treated as a symbol of the library, while now it's treated as a symbol of -- I'm not sure what that actually means, but presumably that refers to the compiler runtime libraries. My guess is that previously it just ended up being nulled out as a missing weak symbol, but now it's actually being found and linking fails because ... reasons. I'm not good at linkers :) Edit: shows these as:
can you prepare a revert PR?
Done in . If nobody has an idea on how to avoid the linker error, two more options would be to comment out the symbol in our llvm-project fork, or to avoid upgrading clang altogether and just build both Python 2 and Python 3 for that image.
The issue is probably going to be in how exactly the objects that comprise are compiled, not linked. I suspect just ends up ignoring the malformed object or otherwise not reporting the issue, but the object and the relevant symbols ultimately end up in the anyway. Alas, reasons these obscure failures can occur are many – I've seen them occur from things as trivial as forgetting to . The question is: is there perhaps a way to disable ExecutionEngine entirely? Intuitively nothing we do should depend on that code.
Code change:
rm -rf /tmp/rustc-pgo <del> python3 ../x.py build --target=$PGO_HOST --host=$PGO_HOST  </del> <ins> python2.7 ../x.py build --target=$PGO_HOST --host=$PGO_HOST  </ins> --stage 2 library/std --rust-profile-generate=/tmp/rustc-pgo ./build/$PGO_HOST/stage2/bin/rustc --edition=2018 

Related discussion:
text: And if not, I'm comfortable patching out in our fork as we get closer to Feb 11 and continue having trouble pinpointing exact cause of this problem.
We normally don't link ExecutionEngine, but dist-x8664-linux in particular builds LLVM with ThinLTO, in which case we link as shared, instead of statically linking individual components into rustcllvm.
It seems to be possible to configure the components in using , but I'm not sure to what degree we can restrict those (not sure if this job also ships LLVM tools).
So, I think we could have used to exclude unnecessary parts from , as LLVM tools can still statically link the parts not in the dylib. But in the end, we can't use the option anyway due to
Looks like I'm getting this locally when trying to bootstrap rustc (while building ), might happen since the llvm upgrade but I'm not 100% sure. Are there some workarounds I can put into my for this? I'm using lld to link. <details<summaryBacktrace</summary<p</p</details
which commit are you trying to build?
latest git master
Probably best to open a new issue then; this one has been closed and the steps to reproduce it still work without error -- you might be having a different problem.
Opened
Did anyone file an upstream bug report about this? I'm observing it outside of Rust, but with a similar setup ( with lld+ThinLTO, then linking it into a binary with ). If not, I'd try to build a reproducer.
I've opened for this.
The bug has been fixed, the fix will be in LLVM 12.0.1.
Thanks! We can try updating clang again once the 12.0.1 tag is there.
Code change:
{ unreachable!("Always specialized"); } <ins> #[inline] default fn fold<Acc, F>(self, init: Acc, f: F) -> Acc where F: FnMut(Acc, Self::Item) -> Acc, { SpecFold::spec_fold(self, init, f) } </ins> } #[doc(hidden)]

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:
{ unreachable!("Always specialized"); } <ins> #[inline] default fn fold<Acc, F>(self, init: Acc, f: F) -> Acc where F: FnMut(Acc, Self::Item) -> Acc, { SpecFold::spec_fold(self, init, f) } </ins> } #[doc(hidden)]

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 main = P(ast::Item { ident: main_id, <del> attrs: thin_vec![main_attr], </del> <ins> attrs: thin_vec![main_attr, no_coverage_attr], </ins> id: ast::DUMMY_NODE_ID, kind: main, vis: ast::Visibility { span: sp, kind: ast::VisibilityKind::Public, tokens: None },

Related discussion:
text: <!-- 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. --Take this simple crate: If I try to gather code coverage for , I end up with the first line mysteriously duplicated as a covered region: (I'm using for convenience, but the same thing happens when I use and process the coverage data manually with and .) Note that in the report produced by , the first line of the file appears twice. It is marked as having executed once, even though it is a comment. Instead, the line should only appear once, and its execution count (if any) should be the execution count of the actual code on that line. <!-- 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<summaryBacktrace</summary<p</p</details--
I did some initial investigation, and discovered a few things: The coverage mapping that embeds in the test binary contains entries for two different functions named . One is the actual that appears in the file, and the other is the that is injected by the test harness. The mapping for the injected function spans from (1,0) to (1,1). Coverage mapping regions use 1-based line numbers and column numbers, so a column number of 0 should be impossible. This unexpected column number confuses the processing code in , and results in line 1 being duplicated in the output. : There are special circumstances where it's legal for a region to have 0 for its start column and its end column, but that isn't what's happening here.
The origin of the bogus (1,0) to (1,1) region seems to be: The test harness entry point is created with a dummy span: When that dummy span is converted into a region, its 0-based start is decremented in an attempt to make the region non-empty. This decrement overflows to , and a subsequent increment (to make it 1-based) overflows back to 0.
My first thought was to sidestep the whole issue by adding to the test harness's injected .
Code change:
let main = P(ast::Item { ident: main_id, <del> attrs: thin_vec![main_attr], </del> <ins> attrs: thin_vec![main_attr, no_coverage_attr], </ins> id: ast::DUMMY_NODE_ID, kind: main, vis: ast::Visibility { span: sp, kind: ast::VisibilityKind::Public, tokens: None },

Related discussion:
text: However, I couldn’t get that to work, because is unstable and can't necessarily be used by the crate it is being injected into. So I think the fix will involve having the instrumentor detect and skip code with dummy spans.
label +A-code-coverage
fixes the overflow, which gets rid of the duplicate line. However, the instrumentor still ends up emitting an empty region from (1,1) to (1,1) for the test harness's , so I'd still like to find a way to avoid instrumenting that function.
I think the empty region now confusing the reporter in more subtle ways, because now I see weird stuff like this: It makes sense that line 1 is “covered” (via the injected ), but it's strange that lines 2 and 3 also have non-zero counts.
It looks like does have special handling for empty regions, but it doesn't properly anticipate the first region being empty, and ends up in a slightly confused state.
Code change:
base.cpu = "x86-64".to_string(); base.max_atomic_width = Some(64); base.pre_link_args.get_mut(&LinkerFlavor::Gcc).unwrap().push("-mx32".to_string()); <del> // BUG: temporarily workaround #59674 base.stack_probes = false; </del> <ins> base.stack_probes = true; </ins> base.has_elf_tls = false; // BUG(GabrielMajeri): disabling the PLT on x86_64 Linux with x32 ABI // breaks code gen. See LLVM bug 36743

Related discussion:
text: I've got a Rust minimal repro code (a.rs), its mir output (a.mir), its x86 codegen output () and its gnu-x32 codegen output () All these files are in this this . Currently, fails, saying "llvm error cannot emit physreg copy instruction". I don't understand llvm ir at all myself, but i tried commenting out L309, L311 & L314 out (all accessing a special 'variable?' called 'unsizedtmp') and it passes, then i uncomment L309 and llc fails again. This issue is blocking . Maybe or someone else who's familiar with could have a look or give me a hint about this?
Forgot to mention: I generated these files with to make the files shorter, but that's unimportant detail, i guess.
If you haven't yet, you might try using  to minimize the ll to a smaller reproducer.
Using bugpoint, i got this(I used llvm-dis to convert it to text):
Looks like it can't deal with the "probe-stack" attribute: removing that makes it work. My guess is the probe stack code doesn't do well with gnux32 targets which is 64bit but has 32bit pointers. The LLVM debug log re: why it fails:
Speaking of stack probing, I guess might know more about this?
To unblock things, I think it is reasonable to delete line in file while we investigate the issue. Stack probes are x86-only feature that is disabled on other architectures anyway.
I guess LLVM needs a upstream fix for stack probing on x32 (it probably emits code using 64-bit registers). We may also want a x32 specific stack probe function in
I've pushed as the temporary workaround.
Filed: LLVM: compiler-builtins:
Fixed upstream by I believe a separate stack probing function for x32 is not necessary, the one for x86_64 should work fine.
The LLVM fix is now in nightly, so we can try re-enabling this again.
Code change:
is_unwindsafe(async { //~^ ERROR the type `&mut Context<'_>` may not be safely transferred across an unwind boundary <del> //~| ERROR the type `&mut (dyn Any + 'static)` may not be safely transferred across an unwind boundary </del> use std::ptr::null; use std::task::{Context, RawWaker, RawWakerVTable, Waker}; let waker = unsafe {

Related discussion:
text: https://crater-
I'll need to re-check later but this seems to bisect to somehow.
The UI test changes from that PR appear to back this up, as confusing as it is.
I'm not sure what's going on in that crate, if it built successfully by mistake, or how that PR interacts with it, so let's cc the PR author and reviewer for validation.
After , no longer implements and , because the context now contains a which doesn't implement those traits. So this is an issue with the standard library and not the crate being built. Repro: label -T-compiler +T-libs +S-has-mcve
WG-prioritization assigning priority (). Noticing this on which says that was meant to be confined on nightly. Unsure about the fallout of this regression but for now marking as critical for tracking purposes. label -I-prioritize +P-critical
Revert up:
Isn't not unwind safe?
That line was by your PR, so while what you say is technically true, talking about what "already happened" when we are traveling back and forth through time via version control may be more confusing than helpful.
That line was already there. I the line below it though. Original PR:
Apologies, I guess I can't count numbers today? Hm, so, the full error of the regression is this: Note that it's trying to make a pointer implement . And for what it's worth, stable does indeed document is . Thus unfortunately that line you pointed to, as opposed to the one I thought you were referring to, is effectively just documenting that all are , and that will include regardless of whether it is is . And confusingly, , unlike .
I have opened as an alternative.
Code change:
} SaveIn(lldest) => { match ty::eval_repeat_count(bcx.tcx(), &**count_expr) { <del> 0 => bcx, </del> <ins> 0 => expr::trans_into(bcx, &**element, Ignore), </ins> 1 => expr::trans_into(bcx, &**element, SaveIn(lldest)), count => { let elem = unpack_datum!(bcx, expr::trans(bcx, &**element));

Related discussion:
text: Currently, will panic, but will not, because the expression is not evaluated in that case.
Also, crashes the compiler. Maybe it's the same issue?
Thanks for the reminder, fixes that as well.