| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Switch to only using aarch64 runners (implying we are now
cross-compiling) and stop running tests. In the future, we could
enable (some?) tests via Rosetta 2.
(cherry picked from commit c574c91e5739519b2fd3fdb5f07fa6e102705703)
|
|
Make tier 3 musl targets link dynamically by default
Since we don't build std for these and don't provide any support for them, these can trivially be changed to link dynamically by default.
|
|
|
|
Enable outline-atomics for aarch64-unknown-linux-musl
They were disabled in bd287fa5084f2e153c1044632f9f3d190f090d69 and haven't been causing problems for a while anymore, see https://github.com/rust-lang/rust/issues/89626 for details.
The entire testsuite still passes on `aarch64-unknown-linux-musl` with this feature enabled.
|
|
They were disabled in bd287fa5084f2e153c1044632f9f3d190f090d69 and haven't been
causing problems for a while anymore.
The entire testsuite still passes on aarch64-unknown-linux-musl with this feature
enabled.
Signed-off-by: Jens Reidel <adrian@travitia.xyz>
|
|
Since we don't build std for these and don't provide any support for
them, these can trivially be changed to link dynamically by default.
Signed-off-by: Jens Reidel <adrian@travitia.xyz>
|
|
Use serde for target spec json deserialize
The previous manual parsing of `serde_json::Value` was a lot of complicated code and extremely error-prone. It was full of janky behavior like sometimes ignoring type errors, sometimes erroring for type errors, sometimes warning for type errors, and sometimes just ICEing for type errors (the icing on the top).
Additionally, many of the error messages about allowed values were out of date because they were in a completely different place than the FromStr impls. Overall, the system caused confusion for users.
I also found the old deserialization code annoying to read. Whenever a `key!` invocation was found, one had to first look for the right macro arm, and no go to definition could help.
This PR replaces all this manual parsing with a 2-step process involving serde.
First, the string is parsed into a `TargetSpecJson` struct. This struct is a 1:1 representation of the spec JSON. It already parses all the enums and is very simple to read and write.
Then, the fields from this struct are copied into the actual `Target`. The reason for this two-step process instead of just serializing into a `Target` is because of a few reasons
1. There are a few transformations performed between the two formats
2. The default logic is implemented this way. Otherwise all the default field values would have to be spelled out again, which is suboptimal. With this logic, they fall out naturally, because everything in the json struct is an `Option`.
Overall, the mapping is pretty simple, with the vast majority of fields just doing a 1:1 mapping that is captured by two macros. I have deliberately avoided making the macros generic to keep them simple.
All the `FromStr` impls now have the error message right inside them, which increases the chance of it being up to date. Some "`from_str`" impls were turned into proper `FromStr` impls to support this.
The new code is much less involved, delegating all the JSON parsing logic to serde, without any manual type matching.
This change introduces a few breaking changes for consumers. While it is possible to use this format on stable, it is very much subject to change, so breaking changes are expected. The hope is also that because of the way stricter behavior, breaking changes are easier to deal with, as they come with clearer error messages.
1. Invalid types now always error, everywhere. Previously, they would sometimes error, and sometimes just be ignored (which meant the users JSON was still broken, just silently!)
2. This now makes use of `deny_unknown_fields` instead of just warning on unused fields, which was done previously. Serde doesn't make it easy to get such warning behavior, which was the primary reason that this now changed. But I think error behavior is very reasonable too. If someone has random stale fields in their JSON, it is likely because these fields did something at some point but no longer do, and the user likely wants to be informed of this so they can figure out what to do.
This is also relevant for the future. If we remove a field but someone has it set, it probably makes sense for them to take a look whether they need this and should look for alternatives, or whether they can just delete it. Overall, the JSON is made more explicit.
This is the only expected breakage, but there could also be small breakage from small mistakes. All targets roundtrip though, so it can't be anything too major.
fixes rust-lang/rust#144153
|
|
Add modern AVR mcus like avr128db28 and attiny3224
Related to https://github.com/llvm/llvm-project/pull/143914
r? ```@Patryk27```
|
|
The previous manual parsing of `serde_json::Value` was a lot of
complicated code and extremely error-prone. It was full of janky
behavior like sometimes ignoring type errors, sometimes erroring for
type errors, sometimes warning for type errors, and sometimes just
ICEing for type errors (the icing on the top).
Additionally, many of the error messages about allowed values were out
of date because they were in a completely different place than the
FromStr impls. Overall, the system caused confusion for users.
I also found the old deserialization code annoying to read. Whenever a
`key!` invocation was found, one had to first look for the right macro
arm, and no go to definition could help.
This PR replaces all this manual parsing with a 2-step process involving
serde.
First, the string is parsed into a `TargetSpecJson` struct. This struct
is a 1:1 representation of the spec JSON. It already parses all the
enums and is very simple to read and write.
Then, the fields from this struct are copied into the actual `Target`.
The reason for this two-step process instead of just serializing into a
`Target` is because of a few reasons
1. There are a few transformations performed between the two formats
2. The default logic is implemented this way. Otherwise all the default
field values would have to be spelled out again, which is
suboptimal. With this logic, they fall out naturally, because
everything in the json struct is an `Option`.
Overall, the mapping is pretty simple, with the vast majority of fields
just doing a 1:1 mapping that is captured by two macros. I have
deliberately avoided making the macros generic to keep them simple.
All the `FromStr` impls now have the error message right inside them,
which increases the chance of it being up to date. Some "`from_str`"
impls were turned into proper `FromStr` impls to support this.
The new code is much less involved, delegating all the JSON parsing
logic to serde, without any manual type matching.
This change introduces a few breaking changes for consumers. While it is
possible to use this format on stable, it is very much subject to
change, so breaking changes are expected. The hope is also that because
of the way stricter behavior, breaking changes are easier to deal with,
as they come with clearer error messages.
1. Invalid types now always error, everywhere. Previously, they would
sometimes error, and sometimes just be ignored (which meant the users
JSON was still broken, just silently!)
2. This now makes use of `deny_unknown_fields` instead of just warning
on unused fields, which was done previously. Serde doesn't make it
easy to get such warning behavior, which was the primary reason that
this now changed. But I think error behavior is very reasonable too.
If someone has random stale fields in their JSON, it is likely
because these fields did something at some point but no longer do,
and the user likely wants to be informed of this so they can figure
out what to do.
This is also relevant for the future. If we remove a field but
someone has it set, it probably makes sense for them to take a look
whether they need this and should look for alternatives, or whether
they can just delete it. Overall, the JSON is made more explicit.
This is the only expected breakage, but there could also be small
breakage from small mistakes. All targets roundtrip though, so it can't
be anything too major.
|
|
|
|
Enable xgot feature for mips64 musl targets
This was missed in b65c2afdfd9aaee977302516c9ef177861abfe74, which only enabled it for the glibc targets.
I didn't feel comfortable touching the OpenWRT target, whoever maintains that will probably want to take a look whether it is necessary there as well.
|
|
This stabilizes a subset of the `-Clinker-features` components on x64 linux:
the lld opt-out.
The opt-in is not stabilized, as interactions with other stable flags require
more internal work, but are not needed for stabilizing using rust-lld by default.
Similarly, since we only switch to rust-lld on x64 linux, the opt-out is
only stabilized there. Other targets still require `-Zunstable-options`
to use it.
|
|
default data address space
|
|
This was missed in b65c2afdfd9aaee977302516c9ef177861abfe74, which only
enabled it for the glibc targets.
I didn't feel comfortable touching the OpenWRT target, whoever maintains
that will probably want to take a look whether it is necessary there as
well.
Signed-off-by: Jens Reidel <adrian@travitia.xyz>
|
|
Expose elf abi on ppc64 targets
Fixes https://github.com/rust-lang/rust/issues/60617 (after MCP https://github.com/rust-lang/compiler-team/issues/885 is accepted) by exposing the abi information on ppc64 targets.
Conditional compilation can now use `cfg(target_abi = "elfv1")` or `cfg(target_abi = "elfv2")` to determine the abi in use.
Technical details are included in the other PR https://github.com/rust-lang/rust/pull/142598
|
|
Convert some ABI tests to use `extern "rust-invalid"`
|
|
|
|
|
|
|
|
rustc_target: document public AbiMap-related fn and variants
|
|
|
|
|
|
workingjubilee:redescribe-rustc_target-more-accurately, r=wesleywiser
Refresh module-level docs for `rustc_target::spec`
We have long since gone on a curveball from the flexible-target-specification RFC by introducing stability and soundness promises to the language and compiler which we often struggle with extending to target-specific implementation details. Indeed, we often *literally cannot*. We also have modified the search algorithm details. Update the comments for `rustc_target::spec` considerably.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
add `extern "custom"` functions
tracking issue: rust-lang/rust#140829
previous discussion: https://github.com/rust-lang/rust/issues/140566
In short, an `extern "custom"` function is a function with a custom ABI, that rust does not know about. Therefore, such functions can only be defined with `#[unsafe(naked)]` and `naked_asm!`, or via an `extern "C" { /* ... */ }` block. These functions cannot be called using normal rust syntax: calling them can only be done from inline assembly.
The motivation is low-level scenarios where a custom calling convention is used. Currently, we often pick `extern "C"`, but that is a lie because the function does not actually respect the C calling convention.
At the moment `"custom"` seems to be the name with the most support. That name is not final, but we need to pick something to actually implement this.
r? `@traviscross`
cc `@tgross35`
try-job: x86_64-apple-2
|
|
|
|
|
|
|
|
r=workingjubilee
Add (back) `unsupported_calling_conventions` lint to reject more invalid calling conventions
This adds back the `unsupported_calling_conventions` lint that was removed in https://github.com/rust-lang/rust/pull/129935, in order to start the process of dealing with https://github.com/rust-lang/rust/issues/137018. Specifically, we are going for the plan laid out [here](https://github.com/rust-lang/rust/issues/137018#issuecomment-2672118326):
- thiscall, stdcall, fastcall, cdecl should only be accepted on x86-32
- vectorcall should only be accepted on x86-32 and x86-64
The difference to the status quo is that:
- We stop accepting stdcall, fastcall on targets that are windows && non-x86-32 (we already don't accept these on targets that are non-windows && non-x86-32)
- We stop accepting cdecl on targets that are non-x86-32
- (There is no difference for thiscall, this was already a hard error on non-x86-32)
- We stop accepting vectorcall on targets that are windows && non-x86-*
Vectorcall is an unstable ABI so we can just make this a hard error immediately. The others are stable, so we emit the `unsupported_calling_conventions` forward-compat lint. I set up the lint to show up in dependencies via cargo's future-compat report immediately, but we could also make it show up just for the local crate first if that is preferred.
try-job: i686-msvc-1
try-job: x86_64-msvc-1
try-job: test-various
|
|
store `target.min_global_align` as an `Align`
Parse the alignment properly when the target is defined/parsed, and error out on invalid alignment values. That means this work doesn't need to happen for every global in each backend.
|
|
compiler: Add track_caller to AbiMapping::unwrap
Same reason as it is on Option's.
|
|
Add new Tier-3 targets: `loongarch32-unknown-none*`
MCP: https://github.com/rust-lang/compiler-team/issues/865
NOTE: LoongArch32 ELF object support is available starting with object v0.37.0.
|
|
calling conventions
|
|
|
|
workingjubilee:apple-likes-frame-pointers-but-not-that-much, r=madsmtm
compiler: set Apple frame pointers by architecture
All Apple targets stop overriding this configuration and instead use the default base of FramePointer::NonLeaf, which means some Apples will have less frame pointers in leaf functions.
r? ``@madsmtm``
cc ``@thomcc``
|
|
Apple targets can now overriding this configuration and instead use the
default based on their architecture, which means aarch64 targets now
have less frame pointers in leaf functions.
|
|
Same reason as it is on Option's.
|
|
MCP: https://github.com/rust-lang/compiler-team/issues/865
|
|
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",
```
|
|
`adjust_abi` is not needed and `is_abi_supported` can be a 1-liner.
|
|
makes entry_abi a lowering of the ABI string, so now it can be
```json
"entry_abi": "C",
"entry_abi": "win64",
"entry_abi": "aapcs",
```
|
|
- Add AbiMapping for encoding the nuance of deprecated ABIs
|
|
|
|
|
|
* https://maskray.me/blog/2023-06-18-port-llvm-xray-to-apple-systems
* https://github.com/llvm/llvm-project/blob/llvmorg-20.1.4/clang/lib/Driver/XRayArgs.cpp#L31
|
