Cargo pulls in libc from crates.io for a number of dependencies, but
0.2.27 is too old to work properly with Solaris. In particular, it
needs the change to make Solaris' PTHREAD_PROCESS_PRIVATE a 16-bit
integer.
rustc::middle::dataflow - visit the CFG in RPO
We used to propagate bits in node-id order, which sometimes caused an
excessive number of iterations, especially when macros were present. As
everyone knows, visiting the CFG in RPO bounds the number of iterators
by 1 plus the depth of the most deeply nested loop (times the height of
the lattice, which is 1).
I have no idea how this affects borrowck perf in the non-worst-case, so it's probably a good idea to not roll this up so we can see the effects.
Fixes#43704.
r? @eddyb
We used to propagate bits in node-id order, which sometimes caused an
excessive number of iterations, especially when macros were present. As
everyone knows, visiting the CFG in RPO bounds the number of iterators
by 1 plus the depth of the most deeply nested loop (times the height of
the lattice, which is 1).
Fixes#43704.
de-orphan extended information
Bizarrely, librustc_passes, librustc_plugin, librustc_mir, and libsyntax [weren't getting their error explanations registered](https://github.com/rust-lang/rust/issues/35284) (leaving _several_ error codes absent from [the index](https://doc.rust-lang.org/nightly/error-index.html) and `--explain`). This surfaced a few latent doctest failures that were fixed where readily possible and ignored (with a recorded excuse) if not.
Also, we don't issue E0563 anymore.
r? @GuillaumeGomez
The sole appearance of this code was deleted in 6383de15; the existing practice
in these cases seems to be to comment out its mention in
`register_diagnostics!`.
After repatriating error explanations to the global registry, some lurking
doctest failures surfaced and needed to be chased down. Sadly, a few doctests
needed to be ignored due to a not-yet-understood regression in the doctest
`compile_fail` functionality (filed #43707).
Also reorder and space the list to make it clearer for futures updates
and to come closer to the original list.
Thanks @est31 for the instructions.
Fixes#43629.
r? @est31
Optimize initialization of arrays using repeat expressions
This PR was inspired by [this thread](https://www.reddit.com/r/rust/comments/6o8ok9/understanding_rust_performances_a_newbie_question/) on Reddit.
It tries to bring array initialization in the same ballpark as `Vec::from_elem()` for unoptimized builds.
For optimized builds this should relieve LLVM of having to figure out the construct we generate is in fact a `memset()`.
To that end this emits `llvm.memset()` when:
* the array is of integer type and all elements are zero (`Vec::from_elem()` also explicitly optimizes for this case)
* the array elements are byte sized
If the array is zero-sized initialization is omitted entirely.
APFloat: Rewrite It In Rust and use it for deterministic floating-point CTFE.
As part of the CTFE initiative, we're forced to find a solution for floating-point operations.
By design, IEEE-754 does not explicitly define everything in a deterministic manner, and there is some variability between platforms, at the very least (e.g. NaN payloads).
If types are to evaluate constant expressions involving type (or in the future, const) generics, that evaluation needs to be *fully deterministic*, even across `rustc` host platforms.
That is, if `[T; T::X]` was used in a cross-compiled library, and the evaluation of `T::X` executed a floating-point operation, that operation has to be reproducible on *any other host*, only knowing `T` and the definition of the `X` associated const (as either AST or HIR).
Failure to uphold those rules allows an associated type (e.g. `<Foo as Iterator>::Item`) to be seen as two (or more) different types, depending on the current host, and such type safety violations typically allow writing of a `transmute` in safe code, given enough generics.
The options considered by @rust-lang/compiler were:
1. Ban floating-point operations in generic const-evaluation contexts
2. Emulate floating-point operations in an uniformly deterministic fashion
The former option may seem appealing at first, but floating-point operations *are allowed today*, so they can't be banned wholesale, a distinction has to be made between the code that already works, and future generic contexts. *Moreover*, every computation that succeeded *has to be cached*, otherwise the generic case can be reproduced without any generics. IMO there are too many ways it can go wrong, and a single violation can be enough for an unsoundness hole.
Not to mention we may end up really wanting floating-point operations *anyway*, in CTFE.
I went with the latter option, and seeing how LLVM *already* has a library for this exact purpose (as it needs to perform optimizations independently of host floating-point capabilities), i.e. `APFloat`, that was what I ended up basing this PR on.
But having been burned by the low reusability of bindings that link to LLVM, and because I would *rather* the floating-point operations to be wrong than not deterministic or not memory-safe (`APFloat` does far more pointer juggling than I'm comfortable with), I decided to RIIR.
This way, we have a guarantee of *no* `unsafe` code, a bit more control over the where native floating-point might accidentally be involved, and non-LLVM backends can share it.
I've also ported all the testcases over, *before* any functionality, to catch any mistakes.
Currently the PR replaces all CTFE operations to go through `apfloat::ieee::{Single,Double}`, keeping only the bits of the `f32` / `f64` memory representation in between operations.
Converting from a string also double-checks that `core::num` and `apfloat` agree on the interpretation of a floating-point number literal, in case either of them has any bugs left around.
r? @nikomatsakis
f? @nagisa @est31
<hr/>
Huge thanks to @edef1c for first demoing usable `APFloat` bindings and to @chandlerc for fielding my questions on IRC about `APFloat` peculiarities (also upstreaming some bugfixes).
