| Age | Commit message (Collapse) | Author | Lines |
|---|
|
(cherry picked from commit b1a38313cb0dee9a7c5573ae37ad48b0a347cb7c)
|
|
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``
|
|
Also allow the SDK path to be non-UTF-8.
|
|
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.
|
|
|
|
|
|
bump thorin to 0.9 to drop duped deps
Bumps `thorin`, removing duped deps.
This also changes features for hashbrown:
```
hashbrown v0.15.2
`-- indexmap v2.7.0
|-- object v0.36.7
|-- wasmparser v0.219.1
|-- wasmparser v0.223.0
`-- wit-component v0.223.0
|-- indexmap feature "default"
|-- indexmap feature "serde"
`-- indexmap feature "std"
|-- hashbrown feature "default-hasher"
| |-- object v0.36.7 (*)
| `-- wasmparser v0.223.0 (*)
|-- hashbrown feature "nightly"
| |-- rustc_data_structures v0.0.0
| `-- rustc_query_system v0.0.0
`-- hashbrown feature "serde"
`-- wasmparser feature "serde"
```
to
```
hashbrown v0.15.2
`-- indexmap v2.7.0
|-- object v0.36.7
|-- wasmparser v0.219.1
|-- wasmparser v0.223.0
`-- wit-component v0.223.0
|-- indexmap feature "default"
|-- indexmap feature "serde"
`-- indexmap feature "std"
|-- hashbrown feature "allocator-api2"
| `-- hashbrown feature "default"
|-- hashbrown feature "default" (*)
|-- hashbrown feature "default-hasher"
| |-- object v0.36.7 (*)
| `-- wasmparser v0.223.0 (*)
| `-- hashbrown feature "default" (*)
|-- hashbrown feature "equivalent"
| `-- hashbrown feature "default" (*)
|-- hashbrown feature "inline-more"
| `-- hashbrown feature "default" (*)
|-- hashbrown feature "nightly"
| |-- rustc_data_structures v0.0.0
| `-- rustc_query_system v0.0.0
|-- hashbrown feature "raw-entry"
| `-- hashbrown feature "default" (*)
`-- hashbrown feature "serde"
`-- wasmparser feature "serde"
```
To be safe, as this can be perf-sensitive:
`@bors` rollup=never
|
|
Rollup of 11 pull requests
Successful merges:
- #138128 (Stabilize `#![feature(precise_capturing_in_traits)]`)
- #138834 (Group test diffs by stage in post-merge analysis)
- #138867 (linker: Fix staticlib naming for UEFI)
- #138874 (Batch mark waiters as unblocked when resuming in the deadlock handler)
- #138875 (Trusty: Fix build for anonymous pipes and std::sys::process)
- #138877 (Ignore doctests only in specified targets)
- #138885 (Fix ui pattern_types test for big-endian platforms)
- #138905 (Add target maintainer information for powerpc64-unknown-linux-musl)
- #138911 (Allow defining opaques in statics and consts)
- #138917 (rustdoc: remove useless `Symbol::is_empty` checks.)
- #138945 (Override PartialOrd methods for bool)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
linker: Fix staticlib naming for UEFI
And one minor refactoring in the second commit.
|
|
add FCW to warn about wasm ABI transition
See https://github.com/rust-lang/rust/issues/122532 for context: the "C" ABI on wasm32-unk-unk will change. The goal of this lint is to warn about any function definition and calls whose behavior will be affected by the change. My understanding is the following:
- scalar arguments are fine
- including 128 bit types, they get passed as two `i64` arguments in both ABIs
- `repr(C)` structs (recursively) wrapping a single scalar argument are fine (unless they have extra padding due to over-alignment attributes)
- all return values are fine
`@bjorn3` `@alexcrichton` `@Manishearth` is that correct?
I am making this a "show up in future compat reports" lint to maximize the chances people become aware of this. OTOH this likely means warnings for most users of Diplomat so maybe we shouldn't do this?
IIUC, wasm-bindgen should be unaffected by this lint as they only pass scalar types as arguments.
Tracking issue: https://github.com/rust-lang/rust/issues/138762
Transition plan blog post: https://github.com/rust-lang/blog.rust-lang.org/pull/1531
try-job: dist-various-2
|
|
|
|
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).
|
|
Lower to a memset(undef) when Rvalue::Repeat repeats uninit
Fixes https://github.com/rust-lang/rust/issues/138625.
It is technically correct to just do nothing. But if we actually do nothing, we may miss that this is de-initializing something, so instead we just lower to a single memset that writes undef. This is still superior to the memcpy loop, in both quality of code we hand to the backend and LLVM's final output.
|
|
|
|
Lower BinOp::Cmp to llvm.{s,u}cmp.* intrinsics
Lowers `mir::BinOp::Cmp` (`three_way_compare` intrinsic) to the corresponding LLVM `llvm.{s,u}cmp.i8.*` intrinsics.
These are the intrinsics mentioned in https://github.com/rust-lang/rust/pull/118310, which are now available in LLVM 19.
I couldn't find any follow-up PRs/discussions about this, please let me know if I missed something.
r? `@scottmcm`
|
|
|
|
|
|
It uses `libname.a` instead of the standard MSVC naming `name.lib`.
Naming for import libraries isn't touched.
|
|
|
|
Only use the new node hashmap for anonymous nodes
This is a rebase of https://github.com/rust-lang/rust/pull/112469.
cc `@cjgillot`
|
|
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`
|
|
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
|
|
Autodiff cleanups
Splitting out some cleanups to reduce the size of my batching PR and simplify ``@haenoe`` 's [PR](https://github.com/rust-lang/rust/pull/138314).
r? ``@oli-obk``
Tracking:
- https://github.com/rust-lang/rust/issues/124509
|
|
Otherwise the linker complains about EC symbols missing when compiling
for arm64ec.
|
|
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.
|
|
|
|
It's very useful. There are some false positives involving integration
tests in `rustc_pattern_analysis` and `rustc_serialize`. There is also a
false positive involving `rustc_driver_impl`'s
`rustc_randomized_layouts` feature. And I removed a `rustc_span` mention
in a doc comment in `rustc_log` because it wasn't integral to the
comment but caused a dev-dependency.
|
|
|
|
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
|
|
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
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
Fix the OperandRef type for NullOp::{UbChecks,ContractChecks}
Stumbled on this while looking at something totally unrelated 🙃
r? saethlin
|
|
|
|
Rollup of 5 pull requests
Successful merges:
- #138283 (Enforce type of const param correctly in MIR typeck)
- #138439 (feat: check ARG_MAX on Unix platforms)
- #138502 (resolve: Avoid some unstable iteration)
- #138514 (Remove fake borrows of refs that are converted into non-refs in `MakeByMoveBody`)
- #138524 (Mark myself as unavailable for reviews temporarily)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
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.
|
|
Though I doubt anyone running rustc outside Unix/Windows
|
|
This also updates the estimate on Windows of the length argument
list to `saturating_add` to avoid overflow.
|
|
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>
|
|
atomic intrinsics: clarify which types are supported and (if applicable) what happens with provenance
The provenance semantics match what Miri implements and what the `AtomicPtr` API expects.
|
|
Don't `alloca` just to look at a discriminant
Today we're making LLVM do a bunch of extra work when you match on trivial stuff like `Option<bool>` or `ControlFlow<u8>`.
This PR changes that so that simple types like `Option<u32>` or `Result<(), Box<Error>>` can stay as `OperandValue::ScalarPair` and we can still read the discriminant from them, rather than needing to write them into memory to have a `PlaceValue` just to get the discriminant out.
Fixes #137503
|
|
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
|
|
r=petrochenkov,jieyouxu
Cleanup sysroot locating a bit
All commits should preserve existing behavior.
|
|
attempt to support `BinaryFormat::Xcoff` in `naked_asm!`
Fixes https://github.com/rust-lang/rust/issues/137219
So, the inline assembly support for xcoff is extremely limited. The LLVM [XCOFFAsmParser](https://github.com/llvm/llvm-project/blob/1b25c0c4da968fe78921ce77736e5baef4db75e3/llvm/lib/MC/MCParser/XCOFFAsmParser.cpp) does not support many of the attributes that LLVM itself emits, and that should exist based on [the assembler docs](https://www.ibm.com/docs/en/ssw_aix_71/assembler/assembler_pdf.pdf). It also does accept some that should not exist based on those docs.
So, I've tried to do the best I can given those limitations. At least it's better than emitting the directives for elf and having that fail somewhere deep in LLVM. Given that inline assembly for this target is incomplete (under `asm_experimental_arch`), I think that's OK (and again I don't see how we can do better given the limitations in LLVM).
r? ```@Noratrieb``` (given that you reviewed https://github.com/rust-lang/rust/pull/136637)
It seems reasonable to ping the [`powerpc64-ibm-aix` target maintainers](https://doc.rust-lang.org/rustc/platform-support/aix.html), hopefully they have thoughts too: ```@daltenty``` ```@gilamn5tr```
|
|
naked functions: on windows emit `.endef` without the symbol name
tracking issue: https://github.com/rust-lang/rust/issues/90957
fixes https://github.com/rust-lang/rust/issues/138320
The `.endef` directive does not take the name as an argument. Apparently the LLVM x86_64 parser does accept this, but on i686 it's rejected. In general `i686` does some special name mangling stuff, so it's good to include it in the naked function tests.
r? ````@ChrisDenton```` (because windows)
|
