CTFE core engine allocation & memory API improvemenets
This is a first step towards https://github.com/rust-lang/miri/issues/841.
- make `Allocation` API offset-based (no more making up `Pointer`s just to access an `Allocation`)
- make `Memory` API higher-level (combine checking for access and getting access into one operation)
The Miri-side PR is at https://github.com/rust-lang/miri/pull/1804.
r? `@oli-obk`
Only pass --[no-]gc-sections if linker is GNU ld.
Fixes a regression from #84468 where linking now fails with solaris linkers. LinkerFlavor::Gcc does not always mean GNU ld specifically. And in the case of at least the solaris ld in illumos, that flag is unrecognized and will cause the linking step to fail.
Even though removing the `is_like_solaris` branch from `gc_sections` in #84468 made sense as `-z ignore/record` are more analogous to the `--[no-]-as-needed` flags, it inadvertently caused solaris linkers to be passed the `--gc-sections` flag. So let's just change it to be more explicit about when we pass those flags.
Fix unused attributes on macro_rules.
The `unused_attributes` lint wasn't firing on attributes of `macro_rules` definitions. The consequence is that many attributes are silently ignored on `macro_rules`. The reason is that `unused_attributes` is a late-lint pass, and only has access to the HIR, which does not have macro_rules definitions.
My solution here is to change `non_exported_macro_attrs` to be `macro_attrs` (a list of all attributes used for `macro_rules`, instead of just those for `macro_export`), and then to check this list in the `unused_attributes` lint. There are a number of alternate approaches, but this seemed the most reliable and least invasive. I am open to completely different approaches, though.
One concern is that I don't fully understand the implications of extending `non_exported_macro_attrs` to include non-exported macros. That list was originally added in #62042 to handle stability attributes, so I suspect it was just an optimization since that was all that was needed. It was later extended to be included in SVH in #83901. #80641 also added a use to check for `invalid` attributes, which seems a little odd to me (it didn't validate non-exported macros, and seems highly specific).
Overall, there doesn't seem to be a clear story of when `unused_attributes` should be used versus an error like E0518. I considered alternatively using an "allow list" of built-in attributes that can be used on macro_rules (allow, warn, deny, forbid, cfg, cfg_attr, macro_export, deprecated, doc), but I feel like that could be a pain to maintain.
Some built-in attributes already present hard-errors when used with macro_rules. These are each hard-coded in various places:
- `derive`
- `test` and `bench`
- `proc_macro` and `proc_macro_derive`
- `inline`
- `global_allocator`
The primary motivation is that I sometimes see people use `#[macro_use]` in front of `macro_rules`, which indicates there is some confusion out there (evident that there was even a case of it in rustc).
Add default search path to `Target::search()`
The function `Target::search()` accepts a target triple and returns a `Target` struct defining the requested target.
There is a `// FIXME 16351: add a sane default search path?` comment that indicates it is desirable to include some sort of default. This was raised in https://github.com/rust-lang/rust/issues/16351 which was closed without any resolution.
https://github.com/rust-lang/rust/pull/31117 was proposed, however that has platform-specific logic that is unsuitable for systems without `/etc/`.
This patch implements the suggestion raised in https://github.com/rust-lang/rust/issues/16351#issuecomment-180878193 where a `target.json` file may be placed in `$(rustc --print sysroot)/lib/rustlib/<target-triple>/target.json`. This allows shipping a toolchain distribution as a single file that gets extracted to the sysroot.
rename LLVM target for RustyHermit
- RustyHermit is a library operating system, where the user-
and the kernel-space use the same target
- by a mistake a previous patch changes the target to an incorect value
- this merge request revert the previous changes
RustyHermit ist is a library operating system. In this case, we link a static library as kernel to the application. The final result is a bootable application. The library and the application have to use the same target. Currently, the targets are different (see also https://github.com/rust-lang/rust/blob/master/compiler/rustc_target/src/spec/x86_64_unknown_hermit.rs). Consequently, this commit change the LLVM target to 'hermit'.
This kernel spec is needed to disable the usage of FPU registers, which are not allowed in kernel space. In contrast to Linux, everything is running in ring 0 and also in the same address space.
Signed-off-by: Stefan Lankes <slankes@eonerc.rwth-aachen.de>
Under some conditions, the toolchain will produce a sequence of linker
arguments that result in a NEEDED list that puts libc before libgcc_s;
e.g.,
[0] NEEDED 0x2046ba libc.so.1
[1] NEEDED 0x204723 libm.so.2
[2] NEEDED 0x204736 libsocket.so.1
[3] NEEDED 0x20478b libumem.so.1
[4] NEEDED 0x204763 libgcc_s.so.1
Both libc and libgcc_s provide an unwinder implementation, but libgcc_s
provides some extra symbols upon which Rust directly depends. If libc
is first in the NEEDED list we will find some of those symbols in libc
but others in libgcc_s, resulting in undefined behaviour as the two
implementations do not use compatible interior data structures.
This solution is not perfect, but is the simplest way to produce correct
binaries on illumos for now.
Be stricter about rejecting LLVM reserved registers in asm!
LLVM will silently produce incorrect code if these registers are used as operands.
cc `@rust-lang/wg-inline-asm`
We had already reverted the change on stable back in PR #83412.
Since then, we've had some movement on issue #83139, but not a 100% fix.
But also since then, we had bug reported, issue #84667, that looks like outright
codegen breakage, rather than problems confined to debuginfo issues.
So we are reverting PR #77885 on stable and beta. We'll reland PR #77885 (or some
variant) switching back to an LLVM-dependent selection of out-of-line call vs
inline-asm, after these other issues have been resolved.
further split up const_fn feature flag
This continues the work on splitting up `const_fn` into separate feature flags:
* `const_fn_trait_bound` for `const fn` with trait bounds
* `const_fn_unsize` for unsizing coercions in `const fn` (looks like only `dyn` unsizing is still guarded here)
I don't know if there are even any things left that `const_fn` guards... at least libcore and liballoc do not need it any more.
`@oli-obk` are you currently able to do reviews?
This enables us to set more generic labels shared between targets. For
example `target_family="wasm"` across all targets that are conceptually
"wasm".
See https://github.com/rust-lang/reference/pull/1006
This commit implements the idea of a new ABI for the WebAssembly target,
one called `"wasm"`. This ABI is entirely of my own invention
and has no current precedent, but I think that the addition of this ABI
might help solve a number of issues with the WebAssembly targets.
When `wasm32-unknown-unknown` was first added to Rust I naively
"implemented an abi" for the target. I then went to write `wasm-bindgen`
which accidentally relied on details of this ABI. Turns out the ABI
definition didn't match C, which is causing issues for C/Rust interop.
Currently the compiler has a "wasm32 bindgen compat" ABI which is the
original implementation I added, and it's purely there for, well,
`wasm-bindgen`.
Another issue with the WebAssembly target is that it's not clear to me
when and if the default C ABI will change to account for WebAssembly's
multi-value feature (a feature that allows functions to return multiple
values). Even if this does happen, though, it seems like the C ABI will
be guided based on the performance of WebAssembly code and will likely
not match even what the current wasm-bindgen-compat ABI is today. This
leaves a hole in Rust's expressivity in binding WebAssembly where given
a particular import type, Rust may not be able to import that signature
with an updated C ABI for multi-value.
To fix these issues I had the idea of a new ABI for WebAssembly, one
called `wasm`. The definition of this ABI is "what you write
maps straight to wasm". The goal here is that whatever you write down in
the parameter list or in the return values goes straight into the
function's signature in the WebAssembly file. This special ABI is for
intentionally matching the ABI of an imported function from the
environment or exporting a function with the right signature.
With the addition of a new ABI, this enables rustc to:
* Eventually remove the "wasm-bindgen compat hack". Once this
ABI is stable wasm-bindgen can switch to using it everywhere.
Afterwards the wasm32-unknown-unknown target can have its default ABI
updated to match C.
* Expose the ability to precisely match an ABI signature for a
WebAssembly function, regardless of what the C ABI that clang chooses
turns out to be.
* Continue to evolve the definition of the default C ABI to match what
clang does on all targets, since the purpose of that ABI will be
explicitly matching C rather than generating particular function
imports/exports.
Naturally this is implemented as an unstable feature initially, but it
would be nice for this to get stabilized (if it works) in the near-ish
future to remove the wasm32-unknown-unknown incompatibility with the C
ABI. Doing this, however, requires the feature to be on stable because
wasm-bindgen works with stable Rust.
This commit adds an additional target property – `supported_sanitizers`,
and replaces the hardcoded allowlists in argument parsing to use this
new property.
Fixes#81802
rustc_target: Avoid unwraps when adding linker flags
These `unwrap`s assume that some linker flags were already added by `*_base::opts()` methods, but that's doesn't necessarily remain the case when we are reducing the number of flags hardcoded in targets, as https://github.com/rust-lang/rust/pull/83587 shows.
r? `@nagisa`
The frontend shouldn't be deciding whether or not to use mutable
noalias attributes, as this is a pure LLVM concern. Only provide
the necessary information and do the actual decision in
codegen_llvm.
