Rollup of 9 pull requests #85036
Merged
Rollup of 9 pull requests #85036
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This extracts a new `parse_cfg` function that's used between both. - Treat `#[doc(cfg(x), cfg(y))]` the same as `#[doc(cfg(x)] #[doc(cfg(y))]`. Previously it would be completely ignored. - Treat `#[doc(inline, cfg(x))]` the same as `#[doc(inline)] #[doc(cfg(x))]`. Previously, the cfg would be ignored. - Pass the cfg predicate through to rustc_expand to be validated Co-authored-by: Vadim Petrochenkov <vadim.petrochenkov@gmail.com>
Since the beginning of time the `-Ctarget-feature` flag on the command
line has largely been passed unmodified to LLVM. Afterwards, though, the
`#[target_feature]` attribute was stabilized and some of the names in
this attribute do not match the corresponding LLVM name. This is because
Rust doesn't always want to stabilize the exact feature name in LLVM for
the equivalent functionality in Rust. This creates a situation, however,
where in Rust you'd write:
#[target_feature(enable = "pclmulqdq")]
unsafe fn foo() {
// ...
}
but on the command line you would write:
RUSTFLAGS="-Ctarget-feature=+pclmul" cargo build --release
This difference is somewhat odd to deal with if you're a newcomer and
the situation may be made worse with upcoming features like [WebAssembly
SIMD](rust-lang#74372) which may be more
prevalent.
This commit implements a mapping to translate requests via
`-Ctarget-feature` through the same name-mapping functionality that's
present for attributes in Rust going to LLVM. This means that
`+pclmulqdq` will work on x86 targets where as previously it did not.
I've attempted to keep this backwards-compatible where the compiler will
just opportunistically attempt to remap features found in
`-Ctarget-feature`, but if there's something it doesn't understand it
gets passed unmodified to LLVM just as it was before.
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.
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>
In rust-lang#75979 several inlined modules were split out into multiple files. This PR keeps the multiple files but moves a few things around to organize things in a coherent way.
…chenkov
illumos should put libc last in library search order
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.
Unify rustc and rustdoc parsing of `cfg()` This extracts a new `parse_cfg` function that's used between both. - Treat `#[doc(cfg(x), cfg(y))]` the same as `#[doc(cfg(x)] #[doc(cfg(y))]`. Previously it would be completely ignored. - Treat `#[doc(inline, cfg(x))]` the same as `#[doc(inline)] #[doc(cfg(x))]`. Previously, the cfg would be ignored. - Pass the cfg predicate through to rustc_expand to be validated Technically this is a breaking change, but doc_cfg is still nightly so I don't think it matters. Fixes rust-lang#84437. r? `````````@petrochenkov`````````
Cleanup of `wasm` Some more cleanup of `sys`, this time `wasm` - Reuse `unsupported::args` (functionally equivalent implementation, just an empty iterator). - Split out `atomics` implementation of `wasm::thread`, the non-`atomics` implementation is reused from `unsupported`. - Move all of the `atomics` code to a separate directory `wasm/atomics`. ````@rustbot```` label: +T-libs-impl r? ````@m-ou-se````
…lacrum linker: Avoid library duplication with `/WHOLEARCHIVE` Looks like in rust-lang#72785 I misinterpreted how the `link.exe`'s `/WHOLEARCHIVE` flag works. It's not necessary to write `mylib /WHOLEARCHIVE:mylib` to mark `mylib` as whole archive, `/WHOLEARCHIVE:mylib` alone is enough. https://docs.microsoft.com/en-us/cpp/build/reference/wholearchive-include-all-library-object-files?view=msvc-160
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
…r=nagisa
rustc: Support Rust-specific features in -Ctarget-feature
Since the beginning of time the `-Ctarget-feature` flag on the command
line has largely been passed unmodified to LLVM. Afterwards, though, the
`#[target_feature]` attribute was stabilized and some of the names in
this attribute do not match the corresponding LLVM name. This is because
Rust doesn't always want to stabilize the exact feature name in LLVM for
the equivalent functionality in Rust. This creates a situation, however,
where in Rust you'd write:
#[target_feature(enable = "pclmulqdq")]
unsafe fn foo() {
// ...
}
but on the command line you would write:
RUSTFLAGS="-Ctarget-feature=+pclmul" cargo build --release
This difference is somewhat odd to deal with if you're a newcomer and
the situation may be made worse with upcoming features like [WebAssembly
SIMD](rust-lang#74372) which may be more
prevalent.
This commit implements a mapping to translate requests via
`-Ctarget-feature` through the same name-mapping functionality that's
present for attributes in Rust going to LLVM. This means that
`+pclmulqdq` will work on x86 targets where as previously it did not.
I've attempted to keep this backwards-compatible where the compiler will
just opportunistically attempt to remap features found in
`-Ctarget-feature`, but if there's something it doesn't understand it
gets passed unmodified to LLVM just as it was before.
…ou-se SGX mutex is movable r? ``@m-ou-se``
…nagisa Rearrange SGX split module files In rust-lang#75979 several inlined modules were split out into multiple files. This PR keeps the multiple files but moves a few things around to organize things in a coherent way.
some further small cleanups
|
@bors r+ rollup=never p=5 |
|
📌 Commit 4284809 has been approved by |
bors
added
the
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
This was referenced May 7, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
cfg()#84442 (Unify rustc and rustdoc parsing ofcfg())wasm#84655 (Cleanup ofwasm)/WHOLEARCHIVE#84866 (linker: Avoid library duplication with/WHOLEARCHIVE)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup