| Age | Commit message (Collapse) | Author | Lines |
|
As suggested by Ralf in 142005.
|
|
MCP: https://github.com/rust-lang/compiler-team/issues/865
|
|
compiler: Document the offset invariant of `OperandValue::Pair`
A subtle invariant of `OperandValue::Pair` that came up during review and was found to be undocumented.
Visible in code like this:
https://github.com/rust-lang/rust/blob/4b27a04cc8ed4da10a546a871e23e665d03f7a79/compiler/rustc_codegen_ssa/src/mir/operand.rs#L376-L392
|
|
Make #[used(linker)] the default on ELF too
`#[used]` currently is an alias for `#[used(linker)]` on all platforms except ELF based ones where it is an alias for `#[used(compiler)]`. The latter has surprising behavior and the LLVM LangRef explicitly states that it "should only be used in rare circumstances, and should not be exposed to source languages." [^2]
The reason `#[used]` still was an alias to `#[used(compiler)]` on ELF is because the gold linker has issues with it. Luckily gold has been deprecated with GCC 15 [^1] and seems to be unable to bootstrap rustc anyway [^3]. As such we shouldn't really care about supporting gold.
This would also allow re-enabling start-stop-gc with lld.
cc https://github.com/rust-lang/rust/issues/93798
Likely fixes https://github.com/rust-lang/rust/issues/85045
[^1]: https://lists.gnu.org/archive/html/info-gnu/2025-02/msg00001.html
[^2]: https://llvm.org/docs/LangRef.html#the-llvm-compiler-used-global-variable
[^3]: https://github.com/rust-lang/rust/issues/139425
|
|
|
|
#[used] currently is an alias for #[used(linker)] on all platforms
except ELF based ones where it is an alias for #[used(compiler)]. The
latter has surprising behavior and the LLVM LangRef explicitly states
that it "should only be used in rare circumstances, and should not be
exposed to source languages."
The reason #[used] still was an alias to #[used(compiler)] on ELF is
because the gold linker has issues with it. Luckily gold has been
deprecated with GCC 15 and seems to be unable to bootstrap rustc anyway.
As such we shouldn't really care about supporting gold.
|
|
|
|
|
|
It was already available as a generic parameter anyway, and it's not like we'll ever put a tag in the 5-billionth field.
|
|
Replace ad-hoc ABI "adjustments" with an `AbiMap` to `CanonAbi`
Our `conv_from_spec_abi`, `adjust_abi`, and `is_abi_supported` combine to give us a very confusing way of reasoning about what _actual_ calling convention we want to lower our code to and whether we want to compile the resulting code at all. Instead of leaving this code as a miniature adventure game in which someone tries to combine stateful mutations into a Rube Goldberg machine that will let them escape the maze and arrive at the promised land of codegen, we let `AbiMap` devour this complexity. Once you have an `AbiMap`, you can answer which `ExternAbi`s will lower to what `CanonAbi`s (and whether they will lower at all).
Removed:
- `conv_from_spec_abi` replaced by `AbiMap::canonize_abi`
- `adjust_abi` replaced by same
- `Conv::PreserveAll` as unused
- `Conv::Cold` as unused
- `enum Conv` replaced by `enum CanonAbi`
target-spec.json changes:
- If you have a target-spec.json then now your "entry-abi" key will be specified in terms of one of the `"{abi}"` strings Rust recognizes, e.g.
```json
"entry-abi": "C",
"entry-abi": "win64",
"entry-abi": "aapcs",
```
|
|
|
|
This deduplicates some code between codegen backends and may in the
future allow adding extra metadata that is only known at link time.
|
|
And move passing it to the linker to the driver code.
|
|
It is only used within cg_llvm.
|
|
It is only used within cg_llvm.
|
|
Warn when gold was used as the linker
gold has been deprecated recently and is known to behave incorrectly around Rust programs, including miscompiling `#[used(linker)]`. Tell people to switch to a different linker instead.
closes rust-lang/rust#141748
r? bjorn3
|
|
Improve intrinsic handling in cg_ssa (part 2)
* Avoid computing function type and signature for intrinsics where possible
* Nicer handling of bool returning intrinsics
Follow up to https://github.com/rust-lang/rust/pull/141404
|
|
gold has been deprecated recently and is known to behave incorrectly
around Rust programs, including miscompiling `#[used(linker)]`.
Tell people to switch to a different linker instead.
Co-Authored-By: bjorn3 <17426603+bjorn3@users.noreply.github.com>
|
|
Noratrieb:RUSTC_ACTUALLY_DO_NOT_RETRY_LINKER_ON_SEGFAULT, r=petrochenkov
Remove RUSTC_RETRY_LINKER_ON_SEGFAULT hack
It looks like this was added in rust-lang/rust#40422 6 years ago because of issues with the MacOS linker. MacOS got a new linker in the meantime, so that should probably be resolved now. Hopefully.
r? petrochenkov
|
|
|
|
|
|
This avoids having to get the function signature.
|
|
atomic_load intrinsic: use const generic parameter for ordering
We have a gazillion intrinsics for the atomics because we encode the ordering into the intrinsic name rather than making it a parameter. This is particularly bad for those operations that take two orderings. Let's fix that!
This PR only converts `load`, to see if there's any feedback that would fundamentally change the strategy we pursue for the const generic intrinsics.
The first two commits are preparation and could be a separate PR if you prefer.
`@BoxyUwU` -- I hope this is a use of const generics that is unlikely to explode? All we need is a const generic of enum type. We could funnel it through an integer if we had to but an enum is obviously nicer...
`@bjorn3` it seems like the cranelift backend entirely ignores the ordering?
|
|
It looks like this was added 6 years ago because of issues with the
MacOS linker. MacOS got a new linker in the meantime, so that should
probably be resolved now. Hopefully.
|
|
A variety of improvements to the codegen backends
Some are just general improvements to cg_ssa or cg_llvm, while others will make it slightly easier to use cg_ssa in cg_clif in the future.
|
|
Emit warning while outputs is not exe and prints linkage info
cc #137384
```bash
$ rustc +stage1 /dev/null --print native-static-libs --crate-type staticlib --emit metadata
warning: skipping link step due to conflict: cannot output linkage information without emitting executable
note: consider emitting executable to print link information
warning: 1 warning emitted
```
|
|
|
|
|
|
|
|
There is no safety contract and I don't think any of them can actually
cause UB in more ways than passing malicious source code to rustc can.
While LtoModuleCodegen::optimize says that the returned ModuleCodegen
points into the LTO module, the LTO module has already been dropped by
the time this function returns, so if the returned ModuleCodegen indeed
points into the LTO module, we would have seen crashes on every LTO
compilation, which we don't. As such the comment is outdated.
|
|
|
|
|
|
It is only relevant when using cg_ssa for driving compilation.
|
|
|
|
|
|
|
|
|
|
Improve intrinsic handling in cg_ssa
* Move all intrinsic handling code to the start of `codegen_call_terminator`.
* Push some intrinsic handling code into `codegen_intrinsic_call`.
* Don't depend on FnAbi for intrinsics.
|
|
|
|
|
|
Intrinsics are not real functions and as such don't have any calling
convention. Trying to compute a calling convention for an intrinsic
anyway is a nonsensical operation.
|
|
|
|
|
|
|
|
|
|
|
|
Describe lifetime of call argument temporaries passed indirectly
Fixes #132014.
|
|
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#140066 (Stabilize `<[T; N]>::as_mut_slice` as `const`)
- rust-lang/rust#141105 (additional edge cases tests for `path.rs` 🧪 )
- rust-lang/rust#141487 (Update askama to `0.14.0`)
- rust-lang/rust#141498 (Use C-string literals to reduce boilerplate)
- rust-lang/rust#141505 (rename internal panicking::try to catch_unwind)
- rust-lang/rust#141511 (Cleanup CodegenFnAttrFlags)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
- Rename `USED` to `USED_COMPILER` to better reflect its behavior.
- Reorder some items to group the used and allocator flags together
- Renumber them without gaps
|
|
Use the fn_span when emitting function calls for better debug info.
This especially improves the developer experience for long chains of function calls that span multiple lines, which is common with builder patterns, chains of iterator/future combinators, etc.
try-job: armhf-gnu
try-job: test-various
try-job: x86_64-msvc-1
try-job: arm-android
r? `@jieyouxu`
|