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.
Add pager support for `rustc --explain EXXXX`
Hello!
Fixes#32665.
Thanks!
**EDIT:** _I've limited access to a Windows machine so this is taking longer than I've anticipated_. 🐢
cc @alexcrichton @nikomatsakis @Mark-Simulacrum @retep998 @ollie27 @afiune
README: note how to enable debugging for rustc
I got stuck on this for a bit, looking for a debug option in `./x.py build --help`.
Diff without newline changes:
Before:
> Various other options are also supported, and are documented in the config file.
After:
> Various other options, such as enabling debug information, are also supported, and are documented in the config file.
Various minor cleanups to rustbuild
This is work I did before the migration to the new rustbuild. I'd prefer to land this first, before my other PR, to make the diff a little clearer.
r? @alexcrichton
Document unintuitive argument order for Vec::dedup_by relation
When trying to use `dedup_by` to merge some auxiliary information from removed elements into kept elements, I was surprised to observe that `vec.dedup_by(same_bucket)` calls `same_bucket(a, b)` where `b` appears before `a` in the vector, and discards `a` when true is returned. This argument order is probably a bug, but since it has already been stabilized, I guess we should document it as a feature and move on.
(`Vec::dedup` also uses `==` with this unexpected argument order, but I figure that’s not important since `==` is expected to be symmetric with no side effects.)
Update docs for Debug* structs. #29355
This adds docs for the Debug* structs as well as examples from the
Formatter::debug_* methods, so that a user knows how to construct them.
I added these examples as the builders module is not public and hence
the debug_*_new() functions are not available to a user.
r? @steveklabnik
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`.
Delete deprecated & unstable range-specific `step_by`
Using the new one is annoying while this one exists, since the inherent method hides the one on iterator.
Tracking issue: #27741
Replacement: #41439
Deprecation: #42310 for 1.19
Fixes#41477
When trying to use dedup_by to merge some auxiliary information from
removed elements into kept elements, I was surprised to observe that
vec.dedup_by(same_bucket) calls same_bucket(a, b) where b appears
before a in the vector, and discards a when true is returned. This
argument order is probably a bug, but since it has already been
stabilized, I guess we should document it as a feature and move on.
(Vec::dedup also uses == with this unexpected argument order, but I
figure that’s not important since == is expected to be symmetric with
no side effects.)
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
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`.
This adds docs for the Debug* structs as well as examples from the
Formatter::debug_* methods, so that a user knows how to construct them.
I added these examples as the builders module is not public and hence
the debug_*_new() functions are not available to a user.
r? @steveklabnik
Review comments.
Mainly adding in the links for all of the structs and functions.
Remove rust tag on code blocks.
