Support dynamically-linked and/or native musl targets
These changes allow native compilation on musl-based distributions and the use of dynamic libraries on linux-musl targets. This is intended to remove limitations based on past assumptions about musl targets, while maintaining existing behavior by default.
A minor related bugfix is included.
Before `#[must_use]` for functions was implemented, a `#[must_use]` attribute
on a function was a no-op. To avoid a breaking change in this behavior, we add
an option for "this-and-such feature is experimental" feature-gate messages to
be a mere warning rather than a compilation-halting failure (so old code that
used to have a useless no-op `#[must_use]` attribute now warns rather than
breaking). When we're on stable, we add a help note to clarify that the feature
isn't "on."
This is in support of #43302.
std: Respect formatting flags for str-like OsStr
Historically many `Display` and `Debug` implementations for `OsStr`-like
abstractions have gone through `String::from_utf8_lossy`, but this was updated
in #42613 to use an internal `Utf8Lossy` abstraction instead. This had the
unfortunate side effect of causing a regression (#43765) in code which relied on
these `fmt` trait implementations respecting the various formatting flags
specified.
This commit opportunistically adds back interpretation of formatting trait flags
in the "common case" where where `OsStr`-like "thing" is all valid utf-8 and can
delegate to the formatting implementation for `str`. This doesn't entirely solve
the regression as non-utf8 paths will format differently than they did before
still (in that they will not respect formatting flags), but this should solve
the regression for all "real world" use cases of paths and such. The door's also
still open for handling these flags in the future!
Closes#43765
We'll actually want a new "soft" warning-only gate to maintain
backwards-compatibility, but it's cleaner to start out with the established,
well-understood gate before implementing the alternative warn-only behavior in
a later commit.
This is in the matter of #43302.
Fix logic error in test guarding prototype MIR borrowck code.
Fix logic error in test guarding prototype MIR borrowck code.
tl;dr: 🤦
(This crept in during the shift from a transform to a query (#44009); I didn't notice because my muscle memory was still always passing `-Z mir-borrowck`, while my test cases *also* had the `#[rustc_mir_borrowck]` attribute attached to them.)
Now that musl supports dynamic libraries (although not by default)
enable the tests that now pass. Additional currently-ignored tests
will pass if rustc is built with crt_static=false in config.toml.
Use libgcc_s when linking dynamically. Convert the static libunwind to
static-nobundle, as libunwind.a is copied from musl_root and available
in the library search path.
Static PIE support, while supported on musl, requires a patch to GCC.
Until/unless it is merged, adding '-pie' to the linker command line will
override '-static' and create a binary that requires a dynamic
interpreter (ld.so).
Most UNIX-like platforms do not allow shared libraries to statically
link their own libc, as libc expects to have consistent process-global
state. On those platforms, when we do not have a shared libc available,
we must not attempt to link dylibs or cdylibs. On Windows, however, it
is expected to statically link the CRT into dynamic libraries.
This feature is only relevant for targets that support both fully-static
and fully-dynamic linkage, such as musl on Linux.
This feature allows targets to opt in to full support of the crt-static
feature. Currently, crt-static is allowed on all targets, even those
that really can't or really shouldn't support it. This works because it
is very loose in the specification of its effects. Changing the behavior
of crt-static to be more strict in how it chooses libraries and links
executables would likely cause compilation to fail on these platforms.
To avoid breaking existing uses of crt-static, whitelist targets that
support the new, stricter behavior. For all other targets, this changes
crt-static from being "mostly a no-op" to "explicitly a no-op".
This controls the value of the crt-static feature used when building the
standard library for a target, as well as the compiler itself when that
target is the host.
They are required for linking it, even though it is a library, because
crtn.o in post_link_objects, as hardcoded in src/librustc_back/target/
linux_musl_base.rs, is added to the linker command line for both
executables and libraries.
The old wording made me think you were supposed to do `python x.py --build=msvc`, which is not the case. Specify that you need to use the target triple.
Add the libraries and objects that have to be linked to a get working L4Re
Binary using pre- and post-link-args. Additionaly some ld commands had to
be passed.
* L4Re libraries and objects will be located by an environment variable.
* gcc libraries and objects will be located using a gcc call.
GCC is mandatory for this target, that might need documentation somewhere.
As soon as something mandatory cannot be found, the compiler will panic.
This is intended, because the functions involved don't allow the usage of
a Result type. libgcc_eh is now passed using `-l` and crtbeginT.o and
crtend.o are now located using `gcc -print-filename`.
Co-authored-by: TobiasSchaffner <tobiasschaffner@outlook.com>
Make sure crates not opting in to staged_api don't use staged_api
This also fixes the problem that with `-Zforce-unstable-if-unmarked` set, crates could not use `#[deprecated]`.
If you prefer, I can instead submit another version which just fixes this problem, but still allows the staged API attributes for all crates when `-Zforce-unstable-if-unmarked` is set. I have prepared that at <https://github.com/RalfJung/rust/tree/staged2>. As yet another alternative, @alexcrichton suggested to turn this error into a lint, but that seems to be much more work, so is it worth it?
Cc @alexcrichton #43975
(This crept in during the shift from a transform to a query; I didn't
notice because my muscle memory was still always passing `-Z
mir-borrowck`, while my test cases *also* had the
`#[rustc_mir_borrowck]` attribute attached to them.)
Add PartialEq/Eq impls to proc_macro::{Spacing, Delimiter}
I don't see a reason why those two types shouldn't be tested for equality. But I hardly know anything about proc macros, so I'm probably wrong :)
Point out missing if conditional
On a case where an else conditional is missing, point this out
instead of the token immediately after the (incorrect) else block:
```
error: missing condition for `if` statemementt push fork -f
--> $DIR/issue-13483.rs:16:5
|
13 | } else if {
| ^ expected if condition here
```
instead of
```
error: expected `{`, found `else`
--> ../../src/test/ui/issue-13483.rs:14:7
|
14 | } else {
| ^^^^
```
Fix#13483.
