Switch to rust-lang-nursery/compiler-builtins
This commit migrates the in-tree `libcompiler_builtins` to the upstream version
at https://github.com/rust-lang-nursery/compiler-builtins. The upstream version
has a number of intrinsics written in Rust and serves as an in-progress rewrite
of compiler-rt into Rust. Additionally it also contains all the existing
intrinsics defined in `libcompiler_builtins` for 128-bit integers.
It's been the intention since the beginning to make this transition but
previously it just lacked the manpower to get done. As this PR likely shows it
wasn't a trivial integration! Some highlight changes are:
* The PR rust-lang-nursery/compiler-builtins#166 contains a number of fixes
across platforms and also some refactorings to make the intrinsics easier to
read. The additional testing added there also fixed a number of integration
issues when pulling the repository into this tree.
* LTO with the compiler-builtins crate was fixed to link in the entire crate
after the LTO process as these intrinsics are excluded from LTO.
* Treatment of hidden symbols was updated as previously the
`#![compiler_builtins]` crate would mark all symbol *imports* as hidden
whereas it was only intended to mark *exports* as hidden.
rustc: Implement the #[global_allocator] attribute
This PR is an implementation of [RFC 1974] which specifies a new method of
defining a global allocator for a program. This obsoletes the old
`#![allocator]` attribute and also removes support for it.
[RFC 1974]: https://github.com/rust-lang/rfcs/pull/1974
The new `#[global_allocator]` attribute solves many issues encountered with the
`#![allocator]` attribute such as composition and restrictions on the crate
graph itself. The compiler now has much more control over the ABI of the
allocator and how it's implemented, allowing much more freedom in terms of how
this feature is implemented.
cc #27389
This PR is an implementation of [RFC 1974] which specifies a new method of
defining a global allocator for a program. This obsoletes the old
`#![allocator]` attribute and also removes support for it.
[RFC 1974]: https://github.com/rust-lang/rfcs/pull/197
The new `#[global_allocator]` attribute solves many issues encountered with the
`#![allocator]` attribute such as composition and restrictions on the crate
graph itself. The compiler now has much more control over the ABI of the
allocator and how it's implemented, allowing much more freedom in terms of how
this feature is implemented.
cc #27389
This commit migrates the in-tree `libcompiler_builtins` to the upstream version
at https://github.com/rust-lang-nursery/compiler-builtins. The upstream version
has a number of intrinsics written in Rust and serves as an in-progress rewrite
of compiler-rt into Rust. Additionally it also contains all the existing
intrinsics defined in `libcompiler_builtins` for 128-bit integers.
It's been the intention since the beginning to make this transition but
previously it just lacked the manpower to get done. As this PR likely shows it
wasn't a trivial integration! Some highlight changes are:
* The PR rust-lang-nursery/compiler-builtins#166 contains a number of fixes
across platforms and also some refactorings to make the intrinsics easier to
read. The additional testing added there also fixed a number of integration
issues when pulling the repository into this tree.
* LTO with the compiler-builtins crate was fixed to link in the entire crate
after the LTO process as these intrinsics are excluded from LTO.
* Treatment of hidden symbols was updated as previously the
`#![compiler_builtins]` crate would mark all symbol *imports* as hidden
whereas it was only intended to mark *exports* as hidden.
Make sNaN removal code tolerate different sNaN encodings
IEEE 754-1985 specifies the encoding of NaN floating point numbers,
but while it mentions that NaNs can be subdivided into signaling
and quiet ones, it doesn't fix the encoding of signaling NaNs in binary
formats. This led to different implementations (CPUs) having different
encodings. IEEE 754-2008 finally specified the encoding of signaling NaNs
but some architectures are compatible with it, while others aren't.
Certain MIPS and PA-RISC CPUs have different encodings for signaling
NaNs.
In order to have the float <-> binary cast feature of the std library be
portable to them, we don't mask any quiet NaNs like we did before (only
being compliant to IEEE 754-2008 and nothing else), but instead we
simply pass a known good NaN instead.
Note that in the code removed there was a bug; the 64 bit mask for quiet
NaNs should have been `0x0008000000000000` instead of the specified
`0x0001000000000000`.
IEEE 754-1985 specifies the encoding of NaN floating point numbers,
but while it mentions that NaNs can be subdivided into signaling
and quiet ones, it doesn't fix the encoding of signaling NaNs in binary
formats. This led to different implementations (CPUs) having different
encodings. IEEE 754-2008 finally specified the encoding of signaling NaNs
but some architectures are compatible with it, while others aren't.
Certain MIPS and PA-RISC CPUs have different encodings for signaling
NaNs.
In order to have the float <-> binary cast feature of the std library be
portable to them, we don't mask any quiet NaNs like we did before (only
being compliant to IEEE 754-2008 and nothing else), but instead we
simply pass a known good NaN instead.
Note that in the code removed there was a bug; the 64 bit mask for quiet
NaNs should have been `0x0008000000000000` instead of the specified
`0x0001000000000000`.
Document possible `io::ErrorKind`s of `fs::open`
Try to make clear that this isn't an API guarantee for now, as we likely
want to refine these errors in the future, e.g. `ENOSPC` "No space left
on device".
CC #40322
Document that `/` works as separator on Windows
Hi Whenever I see code like `Path::new("./src/bin/main.rs")` or `path.ends_with("foo/bar")`, I wonder if it will work on Windows as I expect. Unfortunately, reading the current docs does not help to answer this question, because all examples are Unix-specific.
However, I believe that using `/` is fine, because both Windows itself [and Rust stdlib](47faf1d519/src/libstd/sys/windows/path.rs (L26)) do treat it as a file separator, and because it is [actually used](abf01e1edd/tests/git.rs (L579)) in Cargo. So looks like we can just document it?
r? @steveklabnik
cc @retep998 I don't actually program for windows that much, so I might be totally wrong, and perhaps we should advise to always use (allocating) `.join` method to construct paths of more than one component?
Fix NaN handling in is_sign_negative/positive
This would be my proposed fix for the #42425 provided we decide it is indeed a problem.
Note this would technically be a breaking change to a stable API. We might want to consider deprecating these methods and adding new ones.
Try to make clear that this isn't an API guarantee for now, as we likely
want to refine these errors in the future, e.g. `ENOSPC` "No space left
on device".
CC #40322
Reword OsStr docs to clarify that utf8 may contain nulls
The use of the word "but" in the OsStr docs implies (at least to me) that valid UTF-8 does not contain null bytes.
Using "which" instead makes it clear that valid UTF-8 may contain null bytes.
Relaxed Debug constraints on {HashMap,BTreeMap}::{Keys,Values}.
I has hit by this yesterday too. 😄
And I've realised that Debug for BTreeMap::{Keys,Values} wasn't formatting just keys and values respectively, but the whole map. 🤔Fixed#41924
r? @jonhoo
rustc: Enable #[thread_local] for Windows
I think LLVM has had support for quite some time now for this, we just never got
around to testing it out and binding it. We've had some trouble landing this in
the past I believe, but it's time to try again!
This commit flags the `#[thread_local]` attribute as being available for Windows
targets and adds an implementation of `register_dtor` in the `thread::local`
module to ensure we can destroy these keys. The same functionality is
implemented in clang via a function called `__tlregdtor` (presumably provided in
some Windows runtime somewhere), but this function unfortunately does not take a
data pointer (just a thunk) which means we can't easily call it. For now
destructors are just run in the same way the Linux fallback is implemented,
which is just keeping track via a single OS-based TLS key.
I think LLVM has had support for quite some time now for this, we just never got
around to testing it out and binding it. We've had some trouble landing this in
the past I believe, but it's time to try again!
This commit flags the `#[thread_local]` attribute as being available for Windows
targets and adds an implementation of `register_dtor` in the `thread::local`
module to ensure we can destroy these keys. The same functionality is
implemented in clang via a function called `__tlregdtor` (presumably provided in
some Windows runtime somewhere), but this function unfortunately does not take a
data pointer (just a thunk) which means we can't easily call it. For now
destructors are just run in the same way the Linux fallback is implemented,
which is just keeping track via a single OS-based TLS key.
Replaced by adding extra imports, adding hidden code (`# ...`), modifying
examples to be runnable (sorry Homura), specifying non-Rust code, and
converting to should_panic, no_run, or compile_fail.
Remaining "```ignore"s received an explanation why they are being ignored.
