about summary refs log tree commit diff
path: root/compiler/rustc_codegen_ssa/src/back
AgeCommit message (Collapse)AuthorLines
2025-05-02check all crate-type to find staticlibxizheyin-6/+6
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
2025-05-02Update compiler/rustc_codegen_ssa/src/back/link.rsxizheyin-1/+1
Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com>
2025-05-02Emit warning while outputs is not exe and prints linkage infoxizheyin-0/+19
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
2025-05-02linker: Quote symbol names in .def filesVadim Petrochenkov-1/+3
To support weird symbol names, including dots in particular.
2025-05-01Auto merge of #138522 - osiewicz:shared-generics-respect-visibility, r=bjorn3bors-12/+59
shared-generics: Do not share instantiations that contain local-only types In Zed shared-generics loading takes up a significant chunk of time in incremental build, as rustc deserializes rmeta of all dependencies of a crate. I've recently realized that shared-generics includes all instantiations of some_generic_function in the following snippet: ```rs pub fn some_generic_function(_: impl Fn()) {} pub fn non_generic_function() { some_generic_function(|| {}); some_generic_function(|| {}); some_generic_function(|| {}); some_generic_function(|| {}); some_generic_function(|| {}); some_generic_function(|| {}); some_generic_function(|| {}); } ``` even though none of these instantiations can actually be created from outside of `non_generic_function`. This is a dummy example, but we do rely on invoking callbacks with FnOnce a lot in our codebase. This PR makes shared-generics account for visibilities of generic arguments; an item is only considered for exporting if it is reachable from the outside or if all of it's arguments are visible outside of the local crate. This PR reduces incremental build time for Zed (touch editor.rs scenario) from 12.4s to 10.4s. I'd love to see a perf run if possible; per my checks this PR does not incur new instantiations in downstream crates, so if there'd be perf regressions, I'd expect them to come from newly-introduced visibility checks.
2025-04-28shared-generics: Do not share instantiations that cannot be created outside ↵Piotr Osiewicz-12/+59
of the current crate In Zed shared-generics loading takes up a significant chunk of time in incremental build, as rustc deserializes rmeta of all dependencies of a crate. I've recently realized that shared-generics includes all instantiations of some_generic_function in the following snippet: ```rs pub fn some_generic_function(_: impl Fn()) {} pub fn non_generic_function() { some_generic_function(|| {}); some_generic_function(|| {}); some_generic_function(|| {}); some_generic_function(|| {}); some_generic_function(|| {}); some_generic_function(|| {}); some_generic_function(|| {}); } ``` even though none of these instantiations can actually be created from outside of `non_generic_function`. This PR makes shared-generics account for visibilities of generic arguments; an item is only considered for exporting if it is reachable from the outside or if all of it's arguments are visible outside of the local crate. This PR reduces incremental build time for Zed (touch edito.rs scenario) from 12.4s to 10.4s. Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com>
2025-04-28AsyncDrop implementation using shim codegen of ↵Andrew Zhogin-3/+20
async_drop_in_place::{closure}, scoped async drop added.
2025-04-26Rollup merge of #140086 - ChrisDenton:backoff, r=petrochenkovMatthias Krüger-5/+4
If creating a temporary directory fails with permission denied then retry with backoff On Windows, if creating a temporary directory fails with permission denied then use a retry/backoff loop. This hopefully fixes a recuring error in our CI. cc ```@jieyouxu,``` https://github.com/rust-lang/rust/issues/133959
2025-04-25Retry if creating temp fails with access deniedChris Denton-5/+4
On Windows, if creating a temporary directory fails with permission denied then use a retry/backoff loop. This hopefully fixes a recuring error in our CI.
2025-04-24strip underlying xcoff objectHenry Jiang-2/+2
2025-04-25set subsections_via_symbols for ld64 helper sectionsusamoi-0/+6
2025-04-07Prepend temp files with a string per invocation of rustcMichael Goulet-6/+30
2025-04-07Simplify temp path creation a bitMichael Goulet-18/+9
2025-04-04refactor: Move env parsing of deployment target to rustc_sessionMads Marquart-55/+5
2025-04-04refactor: Move Apple OSVersion (back) to rustc_targetMads Marquart-96/+16
Also convert OSVersion into a proper struct for better type-safety.
2025-04-04Rollup merge of #138949 - madsmtm:rename-to-darwin, r=WaffleLapkinMatthias Krüger-25/+25
Rename `is_like_osx` to `is_like_darwin` Replace `is_like_osx` with `is_like_darwin`, which more closely describes reality (OS X is the pre-2016 name for macOS, and is by now quite outdated; Darwin is the overall name for the OS underlying Apple's macOS, iOS, etc.). ``@rustbot`` label O-apple r? compiler
2025-04-03Make LevelAndSource a structOli Scherer-2/+2
2025-03-31Store only a metadata stub into `rlibs` and `dylibs` with `-Zembed-metadata=no`Jakub Beránek-3/+3
2025-03-28use `slice::contains` where applicableYotam Ofek-1/+1
2025-03-27Rollup merge of #139010 - madsmtm:parse-xcrun-better, r=wesleywiserJacob Pratt-65/+240
Improve `xcrun` error handling The compiler invokes `xcrun` on macOS when linking Apple targets, to find the Xcode SDK which contain all the necessary linker stubs. The error messages that `xcrun` outputs aren't always that great though, so this PR tries to improve that by providing extra context when an error occurs. Fixes https://github.com/rust-lang/rust/issues/56829. Fixes https://github.com/rust-lang/rust/issues/84534. Part of https://github.com/rust-lang/rust/issues/129432. See also the alternative https://github.com/rust-lang/rust/pull/131433. Tested on: - `x86_64-apple-darwin`, MacBook Pro running Mac OS X 10.12.6 - With no tooling installed - With Xcode 9.2 - With Xcode 9.2 Commandline Tools - `aarch64-apple-darwin`, MacBook M2 Pro running macOS 14.7.4 - With Xcode 13.4.1 - With Xcode 16.2 - Inside `nix-shell -p xcbuild` (nixpkgs' `xcrun` shim) - `aarch64-apple-darwin`, VM running macOS 15.3.1 - With no tooling installed - With Xcode 16.2 Commandline Tools ``@rustbot`` label O-apple r? compiler CC ``@BlackHoleFox`` ``@thomcc``
2025-03-27Emit better error messages when invoking xcrunMads Marquart-41/+222
Also allow the SDK path to be non-UTF-8.
2025-03-27Invoke xcrun inside sess.timeMads Marquart-1/+1
It can be a fairly expensive operation when the output is not cached, so it's nice to get some visibility into the runtime cost.
2025-03-27refactor: Move Apple SDK names to rustc_codegen_ssa::back::appleMads Marquart-27/+21
2025-03-26Always emit native-static-libs note, even if it is emptyMads Marquart-9/+5
2025-03-25Rollup merge of #138867 - petrochenkov:linkfix, r=nnethercoteJacob Pratt-12/+17
linker: Fix staticlib naming for UEFI And one minor refactoring in the second commit.
2025-03-25Rename `is_like_osx` to `is_like_darwin`Mads Marquart-25/+25
2025-03-25Auto merge of #136410 - saethlin:clean-up-cgu-internal-copy, r=compiler-errorsbors-9/+4
Remove InstanceKind::generates_cgu_internal_copy This PR should not contain any behavior changes. Before this PR, the logic for selecting instantiation mode is spread across all of * `instantiation_mode` * `cross_crate_inlinable` * `generates_cgu_internal_copy` * `requires_inline` The last two of those functions are not well-designed. The function that actually decides if we generate a CGU-internal copy is `instantiation_mode`, _not_ `generates_cgu_internal_copy`. The function `requires_inline` documents that it is about the LLVM `inline` attribute and that it is a hint. The LLVM attribute is called `inlinehint`, this function is also used by other codegen backends, and since it is part of instantiation mode selection it is *not* a hint. The goal of this PR is to start cleaning up the logic into a sequence of checks that have a more logical flow and are easier to customize in the future (to do things like improve incrementality or improve optimizations without causing obscure linker errors because you forgot to update another part of the compiler).
2025-03-24Remove InstanceKind::generates_cgu_internal_copyBen Kimock-9/+4
2025-03-25rustc_session: Add a helper function for obtaining staticlib prefix and suffixVadim Petrochenkov-12/+5
2025-03-25linker: Avoid calling `linker_and_flavor` twiceVadim Petrochenkov-6/+9
2025-03-25linker: Fix staticlib naming for UEFIVadim Petrochenkov-4/+13
It uses `libname.a` instead of the standard MSVC naming `name.lib`. Naming for import libraries isn't touched.
2025-03-23Rollup merge of #137736 - bjorn3:compiler_builtins_export_fix, r=petrochenkovJacob Pratt-2/+7
Don't attempt to export compiler-builtins symbols from rust dylibs They are marked with hidden visibility to prevent them from getting exported, so we shouldn't ask the linker to export them anyway. The only thing that does it cause a warning on macOS. Part of https://github.com/rust-lang/rust/issues/136096 cc `@jyn514`
2025-03-21Auto merge of #128320 - saethlin:link-me-maybe, r=compiler-errorsbors-6/+15
Avoid no-op unlink+link dances in incr comp Incremental compilation scales quite poorly with the number of CGUs. This PR improves one reason for that. The incr comp process hard-links all the files from an old session into a new one, then it runs the backend, which may just hard-link the new session files into the output directory. Then codegen hard-links all the output files back to the new session directory. This PR (perhaps unimaginatively) fixes the silliness that ensues in the last step. The old `link_or_copy` implementation would be passed pairs of paths which are already the same inode, then it would blindly delete the destination and re-create the hard-link that it just deleted. This PR lets us skip both those operations. We don't skip the other two hard-links. `cargo +stage1 b && touch crates/core/main.rs && strace -cfw -elink,linkat,unlink,unlinkat cargo +stage1 b` before and then after on `ripgrep-13.0.0`: ``` % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 52.56 0.024950 25 978 485 unlink 34.38 0.016318 22 727 linkat 13.06 0.006200 24 249 unlinkat ------ ----------- ----------- --------- --------- ---------------- 100.00 0.047467 24 1954 485 total ``` ``` % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 42.83 0.014521 57 252 unlink 38.41 0.013021 26 486 linkat 18.77 0.006362 25 249 unlinkat ------ ----------- ----------- --------- --------- ---------------- 100.00 0.033904 34 987 total ``` This reduces the number of hard-links that are causing perf troubles, noted in https://github.com/rust-lang/rust/issues/64291 and https://github.com/rust-lang/rust/issues/137560
2025-03-21Also check for compiler-builtins in linked_symbolsbjorn3-1/+3
Otherwise the linker complains about EC symbols missing when compiling for arm64ec.
2025-03-21Don't attempt to export compiler-builtins symbols from rust dylibsbjorn3-1/+4
They are marked with hidden visibility to prevent them from getting exported, so we shouldn't ask the linker to export them anyway. The only thing that does it cause a warning on macOS.
2025-03-18Auto merge of #138630 - matthiaskrgr:rollup-kk1gogr, r=matthiaskrgrbors-66/+54
Rollup of 7 pull requests Successful merges: - #138384 (Move `hir::Item::ident` into `hir::ItemKind`.) - #138508 (Clarify "owned data" in E0515.md) - #138531 (Store test diffs in job summaries and improve analysis formatting) - #138533 (Only use `DIST_TRY_BUILD` for try jobs that were not selected explicitly) - #138556 (Fix ICE: attempted to remap an already remapped filename) - #138608 (rustc_target: Add target feature constraints for LoongArch) - #138619 (Flatten `if`s in `rustc_codegen_ssa`) r? `@ghost` `@rustbot` modify labels: rollup
2025-03-17Auto merge of #127173 - bjorn3:mangle_rustc_std_internal_symbol, ↵bors-5/+11
r=wesleywiser,jieyouxu Mangle rustc_std_internal_symbols functions This reduces the risk of issues when using a staticlib or rust dylib compiled with a different rustc version in a rust program. Currently this will either (in the case of staticlib) cause a linker error due to duplicate symbol definitions, or (in the case of rust dylibs) cause rustc_std_internal_symbols functions to be silently overridden. As rust gets more commonly used inside the implementation of libraries consumed with a C interface (like Spidermonkey, Ruby YJIT (curently has to do partial linking of all rust code to hide all symbols not part of the C api), the Rusticl OpenCL implementation in mesa) this is becoming much more of an issue. With this PR the only symbols remaining with an unmangled name are rust_eh_personality (LLVM doesn't allow renaming it) and `__rust_no_alloc_shim_is_unstable`. Helps mitigate https://github.com/rust-lang/rust/issues/104707 try-job: aarch64-gnu-debug try-job: aarch64-apple try-job: x86_64-apple-1 try-job: x86_64-mingw-1 try-job: i686-mingw-1 try-job: x86_64-msvc-1 try-job: i686-msvc-1 try-job: test-various try-job: armhf-gnu
2025-03-17Flatten `if`s in `rustc_codegen_ssa`Yotam Ofek-66/+54
2025-03-17Rollup merge of #137449 - compiler-errors:control-flow, r=Amanieu,lnicolaMatthias Krüger-1/+1
Denote `ControlFlow` as `#[must_use]` I've repeatedly hit bugs in the compiler due to `ControlFlow` not being marked `#[must_use]`. There seems to be an accepted ACP to make the type `#[must_use]` (https://github.com/rust-lang/libs-team/issues/444), so this PR implements that part of it. Most of the usages in the compiler that trigger this new warning are "root" usages (calling into an API that uses control-flow internally, but for which the callee doesn't really care) and have been suppressed by `let _ = ...`, but I did legitimately find one instance of a missing `?` and one for a never-used `ControlFlow` value in #137448. Presumably this needs an FCP too, so I'm opening this and nominating it for T-libs-api. This PR also touches the tools (incl. rust-analyzer), but if this went into FCP, I'd split those out into separate PRs which can land before this one does. r? libs-api `@rustbot` label: T-libs-api I-libs-api-nominated
2025-03-17Remove implicit #[no_mangle] for #[rustc_std_internal_symbol]bjorn3-5/+11
2025-03-17Use `strip_{prefix|suffix}` instead of `{starts|ends}_with`+indexingYotam Ofek-2/+7
2025-03-16Suppress must_use in compiler and toolsMichael Goulet-1/+1
2025-03-14feat(linker): check ARG_MAX on Unix platformsWeihang Lo-7/+41
On Unix the limits can be gargantuan anyway so we're pretty unlikely to hit them, but might still exceed it. We consult ARG_MAX here to get an estimate.
2025-03-14fix(linker): use arg list estimate on only WindowsWeihang Lo-1/+1
Though I doubt anyone running rustc outside Unix/Windows
2025-03-14fix(linker): prevent overflow when estimating CLI arg list lengthWeihang Lo-1/+2
This also updates the estimate on Windows of the length argument list to `saturating_add` to avoid overflow.
2025-03-14Rollup merge of #138432 - weihanglo:lld, r=lqdJacob Pratt-7/+0
fix: remove the check of lld not supporting @response-file In LLVM v9, lld has supported `@response-file.` LLVM v9 was released on 2019-09-19. The check was added back to 2018-03-14 (1.26.0) via 04442af18bf0. It has been more than five years, and we ship our own lld regardlessly. This should be happily removed. See also: * <https://github.com/llvm/llvm-project/commit/bb12396f9175eaf4586d8e5c76441977d97ccf93> * <https://reviews.llvm.org/D63024>
2025-03-13Auto merge of #138450 - matthiaskrgr:rollup-4im25vf, r=matthiaskrgrbors-2/+1
Rollup of 6 pull requests Successful merges: - #137816 (attempt to support `BinaryFormat::Xcoff` in `naked_asm!`) - #138109 (make precise capturing args in rustdoc Json typed) - #138343 (Enable `f16` tests for `powf`) - #138356 (bump libc to 0.2.171 to fix xous) - #138371 (Update compiletest's `has_asm_support` to match rustc) - #138404 (Cleanup sysroot locating a bit) r? `@ghost` `@rustbot` modify labels: rollup
2025-03-13Rollup merge of #138404 - bjorn3:sysroot_handling_cleanup, ↵Matthias Krüger-2/+1
r=petrochenkov,jieyouxu Cleanup sysroot locating a bit All commits should preserve existing behavior.
2025-03-13Rollup merge of #138273 - petrochenkov:nonatroot, r=bjorn3Matthias Krüger-14/+12
metadata: Ignore sysroot when doing the manual native lib search in rustc This is the opposite alternative to https://github.com/rust-lang/rust/pull/138170 and another way to make native library search consistent between rustc and linker. This way the directory list searched by rustc is still a prefix of the directory list considered by linker, but it's a shorter prefix than in #138170. We can include the sysroot directories into rustc's search again later if the issues with #138170 are resolved, it will be a backward compatible change. This may break some code doing weird things on unstable rustc, or tier 2-3 targets, like bundling `libunwind.a` or sanitizers into something. Note that this doesn't affect shipped `libc.a`, because it lives in `self-contained` directories in sysroot, and `self-contained` sysroot is already not included into the rustc's search. All libunwind and sanitizer libs should be moved to `self-contained` sysroot too eventually. With the consistent search directory list between rustc and linker we can make rustc own the native library search (at least for static libs) and use linker search only as a fallback (like in #123436). This will allow addressing issues like https://github.com/rust-lang/rust/pull/132394 once and for all on all targets. r? ``@bjorn3``
2025-03-12fix: remove the check of lld not supporting @response-fileWeihang Lo-7/+0
In LLVM v9, lld has supported @response-file LLVM v9 was released on 2019-09-19. And the check was added back to 2018-03-14 (1.26.0) via 04442af18bf0. It has been more than five years, and we ship our own lld regardlessly. This should be happily removed. See also: * <https://github.com/llvm/llvm-project/commit/bb12396f9175eaf4586d8e5c76441977d97ccf93> * <https://reviews.llvm.org/D63024>
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-26 00:37:49 +0000