about summary refs log tree commit diff
path: root/compiler/rustc_codegen_llvm
AgeCommit message (Collapse)AuthorLines
2025-09-12Rollup merge of #144549 - folkertdev:va-arg-arm, r=saethlinStuart Cook-0/+15
match clang's `va_arg` assembly on arm targets tracking issue: https://github.com/rust-lang/rust/issues/44930 For this example ```rust #![feature(c_variadic)] #[unsafe(no_mangle)] unsafe extern "C" fn variadic(a: f64, mut args: ...) -> f64 { let b = args.arg::<f64>(); let c = args.arg::<f64>(); a + b + c } ``` We currently generate (via llvm): ```asm variadic: sub sp, sp, #12 stmib sp, {r2, r3} vmov d0, r0, r1 add r0, sp, #4 vldr d1, [sp, #4] add r0, r0, #15 bic r0, r0, #7 vadd.f64 d0, d0, d1 add r1, r0, #8 str r1, [sp] vldr d1, [r0] vadd.f64 d0, d0, d1 vmov r0, r1, d0 add sp, sp, #12 bx lr ``` LLVM is not doing a good job. In fact, it's well-known that LLVM's implementation of `va_arg` is kind of bad, and we implement it ourselves (based on clang) for many targets already. For arm, our own `emit_ptr_va_arg` saves 3 instructions. Next, it turns out it's important for LLVM to explicitly start and end the lifetime of the `va_list`. In https://github.com/rust-lang/rust/pull/146059 I already end the lifetime, but when looking at this again, I noticed that it is important to also start it, see https://godbolt.org/z/EGqvKTTsK: failing to explicitly start the lifetime uses an extra register. So, the combination of `emit_ptr_va_arg` with starting/ending the lifetime makes rustc emit exactly the instructions that clang generates:: ```asm variadic: sub sp, sp, #12 stmib sp, {r2, r3} vmov d16, r0, r1 vldr d17, [sp, #4] vadd.f64 d16, d16, d17 vldr d17, [sp, #12] vadd.f64 d16, d16, d17 vmov r0, r1, d16 add sp, sp, #12 bx lr ``` The arguments to `emit_ptr_va_arg` are based on [the clang implementation](https://github.com/llvm/llvm-project/blob/03dc2a41f3d9a500e47b513de5c5008c06860d65/clang/lib/CodeGen/Targets/ARM.cpp#L798-L844). r? ``@workingjubilee`` (I can re-roll if your queue is too full, but you do seem like the right person here) try-job: armhf-gnu
2025-09-10Rollup merge of #146178 - folkertdev:static-align, ↵Matthias Krüger-0/+2
r=jdonszelmann,ralfjung,traviscross Implement `#[rustc_align_static(N)]` on `static`s Tracking issue: https://github.com/rust-lang/rust/issues/146177 ```rust #![feature(static_align)] #[rustc_align_static(64)] static SO_ALIGNED: u64 = 0; ``` We need a different attribute than `rustc_align` because unstable attributes are tied to their feature (we can't have two unstable features use the same unstable attribute). Otherwise this uses all of the same infrastructure as `#[rustc_align]`. r? `@traviscross`
2025-09-09allow `#[rustc_align_static(N)]` on `static`sFolkert de Vries-0/+2
We need a different attribute than `rustc_align` because unstable attributes are tied to their feature (we can't have two unstable features use the same unstable attribute). Otherwise this uses all of the same infrastructure as `#[rustc_align]`.
2025-09-09Auto merge of #145717 - BoxyUwU:erase_regions_rename, r=lcnrbors-3/+3
rename erase_regions to erase_and_anonymize_regions I find it consistently confusing that `erase_regions` does more than replacing regions with `'erased`. it also makes some code look real goofy to be writing manual folders to erase regions with a comment saying "we cant use erase regions" :> or code that re-calls erase_regions on types with regions already erased just to anonymize all the bound regions. r? lcnr idk how i feel about the name being almost twice as long now
2025-09-09erase_regions to erase_and_anonymize_regionsBoxy-3/+3
2025-09-09Rollup merge of #146025 - Enselic:big-array-debuginfo-span, r=wesleywiserStuart Cook-4/+10
compiler: Include span of too huge array with `-Cdebuginfo=2` We have a few ui tests to ensure we emit an error if we encounter too big arrays. Before this fix, compiling the tests with `-Cdebuginfo=2` would not include the spans of the instantiation sites, because the error is then emitted from a different code path that does not include the span. Propagate the span to the error also in the debuginfo case, so the tests passes regardless of debuginfo level. r? ``@wesleywiser`` since this is a natural continuation of https://github.com/rust-lang/rust/pull/145967 that you approved (thanks!). cc https://github.com/rust-lang/rust/issues/61117 since this takes is one step closer to increasing `rust.debuginfo-level-tests` to `2` in the **x86_64-gnu-debug** CI job. ## Test failure output without the fix <details> <summary> Here is what the test failures look like if you run the tests without the fix. (Click to expand.) </summary> ``` $ ./x test --set rust.debuginfo-level-tests=2 tests/ui/limits/huge-array-simple-64.rs tests/ui/limits/huge-array.rs tests/ui/limits/issue-15919-64.rs Building bootstrap Finished `dev` profile [unoptimized] target(s) in 0.16s /home/martin/src/rust/build/x86_64-unknown-linux-gnu/ci-llvm/bin/llvm-strip does not exist; skipping copy Building stage1 compiler artifacts (stage0 -> stage1, x86_64-unknown-linux-gnu) Finished `release` profile [optimized + debuginfo] target(s) in 0.40s Creating a sysroot for stage1 compiler (use `rustup toolchain link 'name' build/host/stage1`) Building stage1 lld-wrapper (stage0 -> stage1, x86_64-unknown-linux-gnu) Finished `release` profile [optimized + debuginfo] target(s) in 0.08s Building stage1 library artifacts (stage1 -> stage1, x86_64-unknown-linux-gnu) Compiling addr2line v0.25.0 Compiling std v0.0.0 (/home/martin/src/rust/library/std) Compiling rustc-std-workspace-std v1.99.0 (/home/martin/src/rust/library/rustc-std-workspace-std) Compiling unicode-width v0.2.1 Compiling rustc-literal-escaper v0.0.5 Compiling proc_macro v0.0.0 (/home/martin/src/rust/library/proc_macro) Compiling getopts v0.2.23 Compiling test v0.0.0 (/home/martin/src/rust/library/test) Compiling sysroot v0.0.0 (/home/martin/src/rust/library/sysroot) Finished `release` profile [optimized + debuginfo] target(s) in 14.43s Building stage1 compiletest (stage0 -> stage1, x86_64-unknown-linux-gnu) Finished `release` profile [optimized + debuginfo] target(s) in 0.14s Testing stage2 compiletest suite=ui mode=ui (stage1 -> stage2, x86_64-unknown-linux-gnu) running 6 tests [ui] tests/ui/limits/huge-array.rs#full-debuginfo ... F [ui] tests/ui/limits/issue-15919-64.rs#full-debuginfo ... F [ui] tests/ui/limits/huge-array-simple-64.rs#full-debuginfo ... F ... failures: ---- [ui] tests/ui/limits/huge-array.rs#full-debuginfo stdout ---- Saved the actual stderr to `/home/martin/src/rust/build/x86_64-unknown-linux-gnu/test/ui/limits/huge-array.full-debuginfo/huge-array.full-debuginfo.stderr` diff of stderr: 1 error: values of the type `[[u8; 1518599999]; 1518600000]` are too big for the target architecture - --> $DIR/huge-array.rs:9:9 - | - LL | let s: [T; 1518600000] = [t; 1518600000]; - | ^ 6 7 error: aborting due to 1 previous error 8 The actual stderr differed from the expected stderr To update references, rerun the tests and pass the `--bless` flag To only update this specific test, also pass `--test-args limits/huge-array.rs` error in revision `full-debuginfo`: 1 errors occurred comparing output. status: exit status: 1 command: env -u RUSTC_LOG_COLOR RUSTC_ICE="0" RUST_BACKTRACE="short" "/home/martin/src/rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc" "/home/martin/src/rust/tests/ui/limits/huge-array.rs" "-Zthreads=1" "-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX" "-Ztranslate-remapped-path-to-local-path=no" "-Z" "ignore-directory-in-diagnostics-source-blocks=/home/martin/.cargo" "-Z" "ignore-directory-in-diagnostics-source-blocks=/home/martin/src/rust/vendor" "--sysroot" "/home/martin/src/rust/build/x86_64-unknown-linux-gnu/stage1" "--target=x86_64-unknown-linux-gnu" "--cfg" "full_debuginfo" "--check-cfg" "cfg(test,FALSE,no_debuginfo,full_debuginfo)" "--error-format" "json" "--json" "future-incompat" "-Ccodegen-units=1" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "-Zwrite-long-types-to-disk=no" "-Cstrip=debuginfo" "-C" "prefer-dynamic" "--out-dir" "/home/martin/src/rust/build/x86_64-unknown-linux-gnu/test/ui/limits/huge-array.full-debuginfo" "-A" "unused" "-A" "internal_features" "-A" "unused_parens" "-A" "unused_braces" "-Crpath" "-Lnative=/home/martin/src/rust/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "-Cdebuginfo=2" stdout: none --- stderr ------------------------------- error: values of the type `[[u8; 1518599999]; 1518600000]` are too big for the target architecture error: aborting due to 1 previous error ------------------------------------------ ---- [ui] tests/ui/limits/huge-array.rs#full-debuginfo stdout end ---- ---- [ui] tests/ui/limits/issue-15919-64.rs#full-debuginfo stdout ---- Saved the actual stderr to `/home/martin/src/rust/build/x86_64-unknown-linux-gnu/test/ui/limits/issue-15919-64.full-debuginfo/issue-15919-64.full-debuginfo.stderr` diff of stderr: 1 error: values of the type `[usize; usize::MAX]` are too big for the target architecture - --> $DIR/issue-15919-64.rs:10:9 - | - LL | let x = [0usize; 0xffff_ffff_ffff_ffff]; - | ^ 6 7 error: aborting due to 1 previous error 8 The actual stderr differed from the expected stderr To update references, rerun the tests and pass the `--bless` flag To only update this specific test, also pass `--test-args limits/issue-15919-64.rs` error in revision `full-debuginfo`: 1 errors occurred comparing output. status: exit status: 1 command: env -u RUSTC_LOG_COLOR RUSTC_ICE="0" RUST_BACKTRACE="short" "/home/martin/src/rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc" "/home/martin/src/rust/tests/ui/limits/issue-15919-64.rs" "-Zthreads=1" "-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX" "-Ztranslate-remapped-path-to-local-path=no" "-Z" "ignore-directory-in-diagnostics-source-blocks=/home/martin/.cargo" "-Z" "ignore-directory-in-diagnostics-source-blocks=/home/martin/src/rust/vendor" "--sysroot" "/home/martin/src/rust/build/x86_64-unknown-linux-gnu/stage1" "--target=x86_64-unknown-linux-gnu" "--cfg" "full_debuginfo" "--check-cfg" "cfg(test,FALSE,no_debuginfo,full_debuginfo)" "--error-format" "json" "--json" "future-incompat" "-Ccodegen-units=1" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "-Zwrite-long-types-to-disk=no" "-Cstrip=debuginfo" "-C" "prefer-dynamic" "--out-dir" "/home/martin/src/rust/build/x86_64-unknown-linux-gnu/test/ui/limits/issue-15919-64.full-debuginfo" "-A" "unused" "-A" "internal_features" "-A" "unused_parens" "-A" "unused_braces" "-Crpath" "-Lnative=/home/martin/src/rust/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "-Cdebuginfo=2" stdout: none --- stderr ------------------------------- error: values of the type `[usize; usize::MAX]` are too big for the target architecture error: aborting due to 1 previous error ------------------------------------------ ---- [ui] tests/ui/limits/issue-15919-64.rs#full-debuginfo stdout end ---- ---- [ui] tests/ui/limits/huge-array-simple-64.rs#full-debuginfo stdout ---- Saved the actual stderr to `/home/martin/src/rust/build/x86_64-unknown-linux-gnu/test/ui/limits/huge-array-simple-64.full-debuginfo/huge-array-simple-64.full-debuginfo.stderr` diff of stderr: 1 error: values of the type `[u8; 2305843011361177600]` are too big for the target architecture - --> $DIR/huge-array-simple-64.rs:12:9 - | - LL | let _fat: [u8; (1<<61)+(1<<31)] = - | ^^^^ 6 7 error: aborting due to 1 previous error 8 The actual stderr differed from the expected stderr To update references, rerun the tests and pass the `--bless` flag To only update this specific test, also pass `--test-args limits/huge-array-simple-64.rs` error in revision `full-debuginfo`: 1 errors occurred comparing output. status: exit status: 1 command: env -u RUSTC_LOG_COLOR RUSTC_ICE="0" RUST_BACKTRACE="short" "/home/martin/src/rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc" "/home/martin/src/rust/tests/ui/limits/huge-array-simple-64.rs" "-Zthreads=1" "-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX" "-Ztranslate-remapped-path-to-local-path=no" "-Z" "ignore-directory-in-diagnostics-source-blocks=/home/martin/.cargo" "-Z" "ignore-directory-in-diagnostics-source-blocks=/home/martin/src/rust/vendor" "--sysroot" "/home/martin/src/rust/build/x86_64-unknown-linux-gnu/stage1" "--target=x86_64-unknown-linux-gnu" "--cfg" "full_debuginfo" "--check-cfg" "cfg(test,FALSE,no_debuginfo,full_debuginfo)" "--error-format" "json" "--json" "future-incompat" "-Ccodegen-units=1" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "-Zwrite-long-types-to-disk=no" "-Cstrip=debuginfo" "-C" "prefer-dynamic" "--out-dir" "/home/martin/src/rust/build/x86_64-unknown-linux-gnu/test/ui/limits/huge-array-simple-64.full-debuginfo" "-A" "unused" "-A" "internal_features" "-A" "unused_parens" "-A" "unused_braces" "-Crpath" "-Lnative=/home/martin/src/rust/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "-Cdebuginfo=2" stdout: none --- stderr ------------------------------- error: values of the type `[u8; 2305843011361177600]` are too big for the target architecture error: aborting due to 1 previous error ------------------------------------------ ---- [ui] tests/ui/limits/huge-array-simple-64.rs#full-debuginfo stdout end ---- failures: [ui] tests/ui/limits/huge-array.rs#full-debuginfo [ui] tests/ui/limits/issue-15919-64.rs#full-debuginfo [ui] tests/ui/limits/huge-array-simple-64.rs#full-debuginfo test result: FAILED. 3 passed; 3 failed; 0 ignored; 0 measured; 19720 filtered out; finished in 117.18ms Some tests failed in compiletest suite=ui mode=ui host=x86_64-unknown-linux-gnu target=x86_64-unknown-linux-gnu Build completed unsuccessfully in 0:00:17 ``` </details> As can be seen, the span info is missing with debuginfo=2 without the fix.
2025-09-08implement `va_arg` for arm in rustc itselfFolkert de Vries-0/+15
2025-09-07Rollup merge of #146209 - bjorn3:lto_refactors5, r=dianqkMatthias Krüger-22/+15
Misc LTO cleanups Follow up to https://github.com/rust-lang/rust/pull/145955. * Remove want_summary argument from `prepare_thin`. Since https://github.com/rust-lang/rust/pull/133250 ThinLTO summary writing is instead done by `llvm_optimize`. * Two minor cleanups
2025-09-06Rollup merge of #146236 - hkBst:gpu-1, r=ZuseZ4Matthias Krüger-1/+1
gpu offload: change suspicious map into filter Fixes clippy warning: ```text warning: this call to `map()` won't have an effect on the call to `count()` --> compiler/rustc_codegen_llvm/src/builder/gpu_offload.rs:194:25 | 194 | let num_ptr_types = types | _________________________^ 195 | | .iter() 196 | | .map(|&x| matches!(cx.type_kind(x), rustc_codegen_ssa::common::TypeKind::Pointer)) 197 | | .count(); | |________________^ | = help: make sure you did not confuse `map` with `filter`, `for_each` or `inspect` = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#suspicious_map = note: `-W clippy::suspicious-map` implied by `-W clippy::suspicious` = help: to override `-W clippy::suspicious` add `#[allow(clippy::suspicious_map)]` ```
2025-09-06Remove want_summary argument from prepare_thinbjorn3-14/+7
It is always false nowadays. ThinLTO summary writing is instead done by llvm_optimize.
2025-09-06Remove thin_link_data method from ThinBufferMethodsbjorn3-8/+8
It is only used within cg_llvm.
2025-09-06Ensure fat LTO doesn't merge everything into the allocator modulebjorn3-1/+7
2025-09-05Rollup merge of #146144 - heiher:entry-func-features, r=petrochenkovLeón Orell Valerian Liehr-10/+22
compiler: Apply target features to the entry function Fixes rust-lang/rust#146143
2025-09-05gpu offload: change suspicious map into filterMarijn Schouten-1/+1
2025-09-04compiler: Apply target features to the entry functionWANG Rui-10/+22
2025-09-04Auto merge of #145955 - bjorn3:lto_refactors4, r=nnethercotebors-15/+7
Rework how the codegen coordinator code handles the allocator shim Continuing from https://github.com/rust-lang/rust/pull/144503 this centralizes most handling of the allocator shim to a single 4 line block in the codegen coordinator. The allocator shim is small enough that making it go through the main codegen loop and spawning a worker thread for it is wasted effort.
2025-09-04Special case allocator module submission to avoid special casing it elsewherebjorn3-15/+7
A lot of places had special handling just in case they would get an allocator module even though most of these places could never get one or would have a trivial implementation for the allocator module. Moving all handling of the allocator module to a single place simplifies things a fair bit.
2025-09-04Rollup merge of #145690 - sayantn:integer-funnel-shift, r=tgross35Jacob Pratt-8/+18
Implement Integer funnel shifts Tracking issue: rust-lang/rust#145686 ACP: https://github.com/rust-lang/libs-team/issues/642 This implements funnel shifts on primitive integer types. Implements this for cg_llvm, with a fallback impl for everything else Thanks `@folkertdev` for the fixes and tests cc `@rust-lang/libs-api`
2025-09-04Rollup merge of #146134 - maurer:nvptx-sync, r=durin42Stuart Cook-0/+4
llvm: nvptx: Layout update to match LLVM LLVM upstream switched layouts to support 256-bit vector load/store. ``````@rustbot`````` label llvm-main r? durin42
2025-09-04Rollup merge of #145932 - JamieCunliffe:target-feature-inlining, r=jackh726Stuart Cook-13/+47
Allow `inline(always)` with a target feature behind a unstable feature `target_feature_inline_always`. Rather than adding the inline always attribute to the function definition, we add it to the callsite. We can then check that the target features match and that the call would be safe to inline. If the function isn't inlined due to a mismatch, we emit a warning informing the user that the function can't be inlined due to the target feature mismatch. See tracking issue rust-lang/rust#145574
2025-09-03Add `funnel_sh{l,r}` functions and intrinsicssayantn-8/+18
- Add a fallback implementation for the intrinsics - Add LLVM backend support for funnel shifts Co-Authored-By: folkertdev <folkert@folkertdev.nl>
2025-09-02llvm: nvptx: Layout update to match LLVMMatthew Maurer-0/+4
LLVM upstream switched layouts to support 256-bit vector load/store.
2025-09-02Revert introduction of `[workspace.dependencies]`.Nicholas Nethercote-7/+7
This was done in #145740 and #145947. It is causing problems for people using r-a on anything that uses the rustc-dev rustup package, e.g. Miri, clippy. This repository has lots of submodules and subtrees and various different projects are carved out of pieces of it. It seems like `[workspace.dependencies]` will just be more trouble than it's worth.
2025-09-02Auto merge of #146059 - folkertdev:va-end-lifetime, r=saethlinbors-3/+6
explicitly end the lifetime of `va_list` tracking issue: https://github.com/rust-lang/rust/issues/44930 split out from: https://github.com/rust-lang/rust/pull/144549 The `va_list` is created in the compiler itself when the variable argument list `...` is desugared, and hence the lifetime end is not inserted automatically. The value can't outlive the function in which it was created, so it is correct to end the lifetime here. Ending the lifetime explicitly also appears to give slightly better codegen in https://github.com/rust-lang/rust/pull/144549. I also included a little drive-by improvement to not cast pointers to integers and back again. r? codegen
2025-09-01Auto merge of #145721 - dpaoliello:ar050, r=bjorn3bors-0/+7
Update to ar_archive_writer 0.5 This updates `ar_archive_writer` to 0.5, which in turn was updated to match LLVM 20.1.8: <https://github.com/rust-lang/ar_archive_writer/pull/24> As part of this, I refactored part of `SymbolWrapper.cpp` to pull common code that I was about to duplicate again into a new function. NOTE: `ar_archive_writer` does include a breaking change where it no longer supports mangling C++ mangled names for Arm64EC. Since we don't need the mangled name (it's not the "exported name" which we're trying to load from the external dll), I'm setting the `import_name` when building for Arm64EC to prevent error when failing to mangle. r? `@bjorn3`
2025-08-31round pointer to alignment without going via intFolkert de Vries-3/+6
2025-08-30compiler: Include span of too huge array with `-Cdebuginfo=2`Martin Nordholts-4/+10
We have a few ui tests to ensure we emit an error if we encounter too big arrays. Before this fix, compiling the tests with `-Cdebuginfo=2` would not include the spans of the instantiation sites, because the error is then emitted from a different code path that does not include the span. Propagate the span to the error also in the debuginfo case, so the tests passes regardless of debuginfo level.
2025-08-29Rollup merge of #145967 - Enselic:big-enum-debuginfo-span, r=wesleywiserTrevor Gross-6/+19
compiler: Include span of too huge enum with `-Cdebuginfo=2` We have the ui test `tests/ui/limits/huge-enum.rs` to ensure we emit an error if we encounter too big enums. Before this fix, compiling the test with `-Cdebuginfo=2` would not include the span of the instantiation site, because the error is then emitted from a different code path that does not include the span. Propagate the span to the error also in the debuginfo case, so the test passes regardless of debuginfo level. I'm sure we can propagate spans in more places, but let's start small. ## Test failure without the fix Here is what the failure looks like if you run the test without the fix: ``` [ui] tests/ui/limits/huge-enum.rs#full-debuginfo ... F . failures: ---- [ui] tests/ui/limits/huge-enum.rs#full-debuginfo stdout ---- Saved the actual stderr to `/home/martin/src/rust/build/x86_64-unknown-linux-gnu/test/ui/limits/huge-enum.full-debuginfo/huge-enum.full-debuginfo.stderr` diff of stderr: 1 error: values of the type `Option<TYPE>` are too big for the target architecture - --> $DIR/huge-enum.rs:17:9 - | - LL | let big: BIG = None; - | ^^^ 6 7 error: aborting due to 1 previous error 8 The actual stderr differed from the expected stderr To update references, rerun the tests and pass the `--bless` flag To only update this specific test, also pass `--test-args limits/huge-enum.rs` ``` as can be seen, the `span` used to be missing with `debuginfo=2`. ## See also This is one small step towards resolving rust-lang/rust#61117. cc https://github.com/rust-lang/rust/pull/144499 which began running UI tests with `rust.debuginfo-level-tests=1`. This PR is part of preparing for increasing that to debuglevel 2.
2025-08-29Update to ar_archive_writer 0.5.1Daniel Paoliello-0/+7
2025-08-29Rollup merge of #145947 - nnethercote:workspace-members-2, r=KobzolStuart Cook-4/+4
Add more to the `[workspace.dependencies]` section in the top-level `Cargo.toml` Following on from rust-lang/rust#145740. r? `@Kobzol`
2025-08-28Move ___asan_globals_registered exportbjorn3-0/+4
All other sanitizer symbols are handled in prepare_lto already.
2025-08-28Only export the sanitizer symbols for LTO and move export code to cg_llvmbjorn3-0/+28
Don't export them from cdylibs. There is no need to do so and it complicates exported_non_generic_symbols. In addition the GCC backend likely uses different symbols and may potentially not even need us to explicitly tell it to export the symbols it needs.
2025-08-28compiler: Include span of too huge enum with -Cdebuginfo=2Martin Nordholts-6/+19
We have a ui test to ensure we emit an error if we encounter too big enums. Before this fix, compiling the test with `-Cdebuginfo=2` would not include the span of the instantiation site, because the error is then emitted from a different code path that does not include the span. Propagate the span to the error also in the debuginfo case, so the test passes regardless of debuginfo level.
2025-08-28Add `rustc-demangle` to `[workspace.dependencies]`.Nicholas Nethercote-1/+1
2025-08-28Add `measureme` to `[workspace.dependencies]`.Nicholas Nethercote-1/+1
2025-08-28Add `serde_json` to `[workspace.dependencies]`.Nicholas Nethercote-1/+1
2025-08-28Add `libc` to `[workspace.dependencies]`.Nicholas Nethercote-1/+1
2025-08-28Auto merge of #145877 - nikic:capture-address, r=tmiaskobors-4/+6
Use captures(address) instead of captures(none) for indirect args While provenance cannot be captured through these arguments, the address / object identity can. Fixes https://github.com/rust-lang/rust/issues/137668. r? `@ghost`
2025-08-27inline at the callsite & warn when target features mismatchJames Barford-Evans-13/+47
Co-authored-by: Jamie Cunliffe <Jamie.Cunliffe@arm.com>
2025-08-27Add `itertools` to `[workspace.dependencies]`.Nicholas Nethercote-1/+1
2025-08-27Add `tracing` to `[workspace.dependencies]`.Nicholas Nethercote-1/+1
2025-08-27Add `bitflags` to `[workspace.dependencies]`.Nicholas Nethercote-1/+1
2025-08-26Rollup merge of #145867 - Zalathar:range-attr, r=nikicGuillaume Gomez-11/+27
cg_llvm: Assert that LLVM range-attribute values don't exceed 128 bits The underlying implementation of `LLVMCreateConstantRangeAttribute` assumes that each of `LowerWords` and `UpperWords` points to enough u64 values to define an integer of the specified bit-length, and will encounter UB if that is not the case. Our safe wrapper function always passes pointers to `[u64; 2]` arrays, regardless of the bit-length specified. That's fine in practice, because scalar primitives never exceed 128 bits, but it is technically a soundness hole in a safe function. We can close the soundness hole by explicitly asserting `size_bits <= 128`. This is effectively just a stricter version of the existing check that the value must be small enough to fit in `c_uint`. --- This is a narrower version of the fix in rust-lang/rust#145846.
2025-08-26Rollup merge of #145076 - ZhongyaoChen:feature/add-tier3-riscv64a23-target, ↵Guillaume Gomez-1/+1
r=davidtwco Add new Tier-3 target: riscv64a23-unknown-linux-gnu MCP: [Tier 3 target proposal: riscv64a23-unknown-linux-gnu](https://github.com/rust-lang/compiler-team/issues/894) Changes: - add new target: riscv64a23-unknown-linux-gnu - add target page
2025-08-26Use captures(address) instead of captures(none) for indirect argsNikita Popov-4/+6
While provenance cannot be captured through these arguments, the address / object identity can.
2025-08-26Rollup merge of #145814 - bjorn3:codegen_worker_fatal_error, r=petrochenkovStuart Cook-67/+66
Handle unwinding fatal errors in codegen workers Also directly unwind on fatal errors at the point they are emitted inside the codegen backends. Fixes the coordinator ICE of https://github.com/rust-lang/rust/issues/132240, https://github.com/rust-lang/rust/issues/135075 and https://github.com/rust-lang/rust/issues/145800.
2025-08-26Assert that LLVM range-attribute values don't exceed 128 bitsZalathar-11/+27
The underlying implementation of `LLVMCreateConstantRangeAttribute` assumes that each of `LowerWords` and `UpperWords` points to enough u64 values to define an integer of the specified bit-length, and will encounter UB if that is not the case. Our safe wrapper function always passes pointers to `[u64; 2]` arrays, regardless of the bit-length specified. That's fine in practice, because scalar primitives never exceed 128 bits, but it is technically a soundness hole in a safe function. We can close the soundness hole by explicitly asserting `size_bits <= 128`. This is effectively just a stricter version of the existing check that the value must be small enough to fit in `c_uint`.
2025-08-24Rename `llvm::Bool` aliases to standard const caseZalathar-34/+33
This avoids the need for `#![allow(non_upper_case_globals)]`.
2025-08-24Replace the `llvm::Bool` typedef with a proper newtypeZalathar-34/+75
2025-08-24Directly raise fatal errors inside the codegen backendsbjorn3-67/+66
As opposed to passing it around through Result.