| Age | Commit message (Collapse) | Author | Lines |
|---|
|
See llvm/llvm-project#121851
For LLVM 20+, this function (`renameModuleForThinLTO`) has no return
value. For prior versions of LLVM, this never failed, but had a
signature which allowed an error value people were handling.
|
|
|
|
We are currently unconditionally verifying the LLVM IR in the
backend (twice), ignoring the value of the verify-llvm-ir option.
|
|
As described here UseOdrIndicator should be disabled on Windows
since link.exe does not support duplicate weak definitions
(https://reviews.llvm.org/D137227).
Co-Authored-By: Bastian Kersting <bkersting@google.com>
|
|
Trim and tidy includes in `rustc_llvm`
These includes tend to accumulate over time, and are usually only removed when something breaks in a new LLVM version, so it's nice to clean them up manually once in a while.
General strategy used for this PR:
- Remove all includes from `LLVMWrapper.h` that aren't needed by the header itself, transplanting them to individual source files as necessary.
- For each source file, temporarily remove each include if doing so doesn't cause a compile error.
- If a “required” include looks like it shouldn't be needed, try replacing it with its sub-includes, then trim that list.
- After doing all of the above, go back and re-add any removed include if the file does actually use things defined in that header, even if the header happens to also be included by something else.
|
|
|
|
llvm/llvm-project@390300d9f41df6ad71f0f4196ef4885d4bd5dc48 added a new
parameter to some callbacks, so we have to handle them.
@rustbot label: +llvm-main
|
|
|
|
Rollup of 15 pull requests
Successful merges:
- #129329 (Implement `From<&mut {slice}>` for `Box/Rc/Arc<{slice}>`)
- #131377 (Add LowerExp and UpperExp implementations to NonZero)
- #132393 (Docs: added brief colon explanation)
- #132437 (coverage: Regression test for inlining into an uninstrumented crate)
- #132499 (unicode_data.rs: show command for generating file)
- #132503 (better test for const HashMap; remove const_hash leftovers)
- #132511 (stabilize const_arguments_as_str)
- #132520 (NFC add known bug nr to test)
- #132522 (make codegen help output more consistent)
- #132523 (Added regression test for generics index out of bounds)
- #132528 (Use `*_opt` typeck results fns to not ICE in fallback suggestion)
- #132537 (PassWrapper: adapt for llvm/llvm-project@5445edb5d)
- #132540 (Do not format generic consts)
- #132543 (add and update some crashtests)
- #132550 (compiler: Continue introducing rustc_abi to the compiler)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Port most of `--print=target-cpus` to Rust
The logic and formatting needed by `--print=target-cpus` has historically been carried out in C++ code. Originally it used `printf` to write directly to the console, but later it switched over to writing to a `std::ostringstream` and then passing its buffer to a callback function pointer.
This PR replaces that C++ code with a very simple function that writes a list of CPU names to a `&RustString`, with the rest of the logic and formatting being handled by ordinary safe Rust code.
|
|
PassWrapper: adapt for llvm/llvm-project@5445edb5d
As with ab5583ed1e75869b765a90386dac9119992f8ed7, we had been explicitly passing defaults whose type have changed. Rather than do an ifdef, we simply rely on the defaults.
````@rustbot```` label: +llvm-main
|
|
PassWrapper: adapt for llvm/llvm-project@b01e2a8b5620466c3b
A boolean turned into an enum. None matches the old behavior of false, so we pass that.
`@rustbot` label: +llvm-main
|
|
As with ab5583ed1e75869b765a90386dac9119992f8ed7, we had been explicitly
passing defaults whose type have changed. Rather than do an ifdef, we
simply rely on the defaults.
@rustbot label: +llvm-main
|
|
llvm/llvm-project@b01e2a8b5620466c3b80cc6f049efbc90b9d103a
We don't see a reason to explicitly pass the default here, so just use
the default instead of explicitly passing it and needing an ifdef.
@rustbot label: +llvm-main
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fixes string manipulation errors introduced in #130446.
|
|
|
|
rustc_llvm: adapt to flattened CLI args in LLVM
This changed in
llvm/llvm-project@e190d074a0a77c9f8a7d7938a8187a7e2076e290. I decided to stick with more duplication between the ifdef blocks to make the code easier to read for the next two years before we can plausibly drop LLVM 19.
`@rustbot` label: +llvm-main
try-job: x86_64-msvc
|
|
|
|
|
|
Revert #129749 to fix segfault in LLVM
This reverts commit 8c7a7e346be4cdf13e77ab4acbfb5ade819a4e60, reversing changes made to a00bd75b6c5c96d0a35afa2dc07ce3155112d278.
Reported in https://github.com/rust-lang/rust/pull/129749#issuecomment-2354417960. `@nikic's` theory is that the LLVM API changed in a way that makes it impossible to use concurrently from multiple threads (https://github.com/llvm/llvm-project/pull/106427#issuecomment-2354783802). I pinged `@krasimirgg` who was fine with reverting.
r? `@rust-lang/wg-llvm`
|
|
This reverts commit 8c7a7e346be4cdf13e77ab4acbfb5ade819a4e60, reversing
changes made to a00bd75b6c5c96d0a35afa2dc07ce3155112d278.
|
|
|
|
This changed in
llvm/llvm-project@e190d074a0a77c9f8a7d7938a8187a7e2076e290. I decided to
stick with more duplication between the ifdef blocks to make the code
easier to read for the next two years before we can plausibly drop LLVM
19.
@rustbot label: +llvm-main
|
|
llvm/llvm-project@2ae968a0d9fb61606b020e898d884c82dd0ed8b5
Just a simple header move.
@rustbot label: +llvm-main
|
|
llvm-wrapper: adapt for LLVM API changes
No functional changes intended.
Updates the wrapper for https://github.com/5c4lar/llvm-project/commit/21eddfac3d75879b3e0b09c5bc848526dcab6ab0.
````@rustbot```` label: +llvm-main
r? ````@nikic````
|
|
Add `-Zlint-llvm-ir`
This flag is similar to `-Zverify-llvm-ir` and allows us to lint the generated IR.
r? compiler
|
|
Updates the wrapper for https://github.com/5c4lar/llvm-project/commit/21eddfac3d75879b3e0b09c5bc848526dcab6ab0.
|
|
|
|
No functional changes intended.
Adapts llvm-wrapper for the LLVM commits https://github.com/llvm/llvm-project/commit/0f22d47a7a1f70ec77ea8ccdf08a6487827937db and https://github.com/llvm/llvm-project/commit/d6d8243dcd4ea768549904036ed31b8e59e14c73.
|
|
Since this codegen flag now only controls LLVM-generated comments rather than
all assembly comments, make the name more accurate (and also match Clang).
|
|
|
|
|
|
|
|
If we don't do this, some versions of LLVM (at least 17, experimentally)
will double-emit some error messages, which is how I noticed this. Given
that it seems to be costing some extra work, let's only request the
summary bitcode production if we'll actually bother writing it down,
otherwise skip it.
|
|
Typical uses of ThinLTO don't have any use for this as a standalone
file, but distributed ThinLTO uses this to make the linker phase more
efficient. With clang you'd do something like `clang -flto=thin
-fthin-link-bitcode=foo.indexing.o -c foo.c` and then get both foo.o
(full of bitcode) and foo.indexing.o (just the summary or index part of
the bitcode). That's then usable by a two-stage linking process that's
more friendly to distributed build systems like bazel, which is why I'm
working on this area.
I talked some to @teresajohnson about naming in this area, as things
seem to be a little confused between various blog posts and build
systems. "bitcode index" and "bitcode summary" tend to be a little too
ambiguous, and she tends to use "thin link bitcode" and "minimized
bitcode" (which matches the descriptions in LLVM). Since the clang
option is thin-link-bitcode, I went with that to try and not add a new
spelling in the world.
Per @dtolnay, you can work around the lack of this by using `lld
--thinlto-index-only` to do the indexing on regular .o files of
bitcode, but that is a bit wasteful on actions when we already have all
the information in rustc and could just write out the matching minimized
bitcode. I didn't test that at all in our infrastructure, because by the
time I learned that I already had this patch largely written.
|
|
|
|
@rustbot label: +llvm-main
|
|
C++ style guides I am aware of recommend specifically preferring = syntax
for any classes with fairly obvious constructors[^0] that do not perform
any complicated logic in their constructor. I contend that all constructors
that the `rustc_llvm` code uses qualify. This has only become more common
since C++ 17 guaranteed many cases of copy initialization elision.
The other detail is that I tried to ask another contributor with
infinitely more C++ experience than me (i.e. any) what this constructor
syntax was, and they thought it was a macro. I know of no other language
that has adopted this same syntax. As the rustc codebase features many
contributors experienced in many other languages, using a less...
unique... style has many other benefits in making this code more
lucid and maintainable, which is something it direly needs.
[^0]: e.g. https://abseil.io/tips/88
|
|
Adds initial support for DataFlowSanitizer to the Rust compiler. It
currently supports `-Zsanitizer-dataflow-abilist`. Additional options
for it can be passed to LLVM command line argument processor via LLVM
arguments using `llvm-args` codegen option (e.g.,
`-Cllvm-args=-dfsan-combine-pointer-labels-on-load=false`).
|
|
Update to LLVM 18
LLVM 18 final is planned to be released on Mar 5th. Rust 1.78 is planned to be released on May 2nd.
Tested images: dist-x86_64-linux, dist-s390x-linux, dist-aarch64-linux, dist-riscv64-linux, dist-loongarch64-linux, dist-x86_64-freebsd, dist-x86_64-illumos, dist-x86_64-musl, x86_64-linux-integration, test-various, armhf-gnu, i686-msvc, x86_64-msvc, i686-mingw, x86_64-mingw, x86_64-apple-1, x86_64-apple-2, dist-aarch64-apple
r? `@ghost`
|
|
This method is now available in upstream LLVM \o/
|
|
llvm/llvm-project@93cdd1b5cfa3735c599949b77e24dbfbe570441a
Should be no functional change.
@rustbot label: +llvm-main
|
|
|
|
effectively reverts https://github.com/rust-lang/rust/commit/9a8acea78355b604dbeb29bc38bd4dbf7bfce95f
|
