test: Fix a bug in bench result formatting
It would skip the middle part if it was 0, displaying a number a 1000
times too small. The MB/s number next to it gave it away.
Fixed it looks like this:
```
test h ... bench: 1,000,129 ns/iter (+/- 4,730)
```
Unlike coercing from reference to unsafe pointer, coercing between two
unsafe pointers doesn't need an AutoDerefRef, because there is no region
that regionck would need to know about.
In unoptimized libcore, this reduces the number of "auto_deref" allocas
from 174 to 4.
When we successfully resolve a trait reference with no type/lifetime parameters, like `i32: Foo` or `Box<u32>: Sized`, this is in fact globally true. This patch adds a simple global to the tcx to cache such cases. The main advantage of this is really about caching things like `Box<Vec<Foo>>: Sized`. It also points to the need to revamp our caching infrastructure -- the current caches make selection cost cheaper, but we still wind up paying a high cost in the confirmation process, and in particular unrolling out dependent obligations. Moreover, we should probably do caching more uniformly and with a key that takes the where-clauses into account. But that's for later.
For me, this shows up as a reasonably nice win (20%) on Servo's script crate (when built in dev mode). This is not as big as my initial measurements suggested, I think because I was building my rustc with more debugging enabled at the time. I've not yet done follow-up profiling and so forth to see where the new hot spots are. Bootstrap times seem to be largely unaffected.
cc @pcwalton
This is technically a [breaking-change] in that functions with unsatisfiable where-clauses may now yield errors where before they may have been accepted. Even before, these functions could never have been *called* by actual code. In the future, such functions will probably become illegal altogether, but in this commit they are still accepted, so long as they do not rely on the unsatisfiable where-clauses. As before, the functions still cannot be called in any case.
This addresses an item in #22709. SizeHint in libcore/iter.rs also implements Iterator, but it's implementation is not accessible and is only used to send size hints to extend (it appears to be a performance improvement to avoid unnecessary memory reallocations). The is the only implementation of Iterator within libcore/iter.rs that is not/cannot be tested in this PR.
This commit updates the LLVM submodule in use to the current HEAD of the LLVM
repository. This is primarily being done to start picking up unwinding support
for MSVC, which is currently unimplemented in the revision of LLVM we are using.
Along the way a few changes had to be made:
* As usual, lots of C++ debuginfo bindings in LLVM changed, so there were some
significant changes to our RustWrapper.cpp
* As usual, some pass management changed in LLVM, so clang was re-scrutinized to
ensure that we're doing the same thing as clang.
* Some optimization options are now passed directly into the
`PassManagerBuilder` instead of through CLI switches to LLVM.
* The `NoFramePointerElim` option was removed from LLVM, favoring instead the
`no-frame-pointer-elim` function attribute instead.
* The `LoopVectorize` option of the LLVM optimization passes has been disabled
as it causes a divide-by-zero exception to happen in LLVM for zero-sized
types. This is reported as https://llvm.org/bugs/show_bug.cgi?id=23763
Additionally, LLVM has picked up some new optimizations which required fixing an
existing soundness hole in the IR we generate. It appears that the current LLVM
we use does not expose this hole. When an enum is moved, the previous slot in
memory is overwritten with a bit pattern corresponding to "dropped". When the
drop glue for this slot is run, however, the switch on the discriminant can
often start executing the `unreachable` block of the switch due to the
discriminant now being outside the normal range. This was patched over locally
for now by having the `unreachable` block just change to a `ret void`.
This commit updates the LLVM submodule in use to the current HEAD of the LLVM
repository. This is primarily being done to start picking up unwinding support
for MSVC, which is currently unimplemented in the revision of LLVM we are using.
Along the way a few changes had to be made:
* As usual, lots of C++ debuginfo bindings in LLVM changed, so there were some
significant changes to our RustWrapper.cpp
* As usual, some pass management changed in LLVM, so clang was re-scrutinized to
ensure that we're doing the same thing as clang.
* Some optimization options are now passed directly into the
`PassManagerBuilder` instead of through CLI switches to LLVM.
* The `NoFramePointerElim` option was removed from LLVM, favoring instead the
`no-frame-pointer-elim` function attribute instead.
Additionally, LLVM has picked up some new optimizations which required fixing an
existing soundness hole in the IR we generate. It appears that the current LLVM
we use does not expose this hole. When an enum is moved, the previous slot in
memory is overwritten with a bit pattern corresponding to "dropped". When the
drop glue for this slot is run, however, the switch on the discriminant can
often start executing the `unreachable` block of the switch due to the
discriminant now being outside the normal range. This was patched over locally
for now by having the `unreachable` block just change to a `ret void`.
Instead of a fast branch with a sized iterator falling back to a potentially poorly optimized iterate-and-push loop, a single efficient loop can serve all cases.
In my benchmark runs, I see some good gains, but also some regressions, possibly due to different inlining choices by the compiler. YMMV.
Currently the compiler has no knowledge of `#[thread_local]` which forces users
to take on two burdens of unsafety:
* The lifetime of the borrow of a `#[thread_local]` static is **not** `'static`
* Types in `static`s are required to be `Sync`
The thread-local modules mostly curb these facets of unsafety by only allowing
very limited scopes of borrows as well as allowing all types to be stored in a
thread-local key (regardless of whether they are `Sync`) through an `unsafe
impl`.
Unfortunately these measures have the consequence of being able to take the
address of the key itself and send it to another thread, allowing the same key
to be accessed from two different threads. This is clearly unsafe, and this
commit fixes this problem with the same trick used by `LocalKey`, which is to
have an indirect function call to find the address of the *current thread's*
thread local. This way the address of thread local keys can safely be sent among
threads as their lifetime truly is `'static`.
This commit will reduce the performance of cross-crate scoped thread locals as
it now requires an indirect function call, but this can likely be overcome in a
future commit.
Closes#25894
The "unit value" is a value of the "unit type," not the "unit value type." Regardless of correctness, this straight syntax is easier to grok.
Part of #16676
Sorry if something's off here, it's my first pull request to rust!
Unlike coercing from reference to unsafe pointer, coercing between two
unsafe pointers doesn't need an AutoDerefRef, because there is no region
that regionck would need to know about.
In unoptimized libcore, this reduces the number of "auto_deref" allocas
from 174 to 4.
It would skip the middle part if it was 0, displaying a number a 1000
times too small. The MB/s number next to it gave it away.
Fixed it looks like this:
```
test h ... bench: 1,000,129 ns/iter (+/- 4,730)
```
Because these structures are created by a macro, the doc comments
don't quite work: the leading /// isn't stripped. Instead, just
use #[doc] so that they render correctly.
Use result of the computation to prevent the compiler from optimising
too much. Change `_x` to `x` and therefore remove the paragraph about
the underscore.
Fixes#25855.
r? @steveklabnik
again, do it once and then just remember the expanded form. At the same
time, filter globally nameable predicates out of the environment, since
they can cause cache errors (and they are not necessary in any case).
that are known to have been satisfied *somewhere*. This means that if
one fn finds that `SomeType: Foo`, then every other fn can just consider
that to hold.
Unfortunately, there are some complications:
1. If `SomeType: Foo` includes dependent conditions, those conditions
may trigger an error. This error will be repored in the first fn
where `SomeType: Foo` is evaluated, but not in the other fns, which
can lead to uneven error reporting (which is sometimes confusing).
2. This kind of caching can be unsound in the presence of
unsatisfiable where clauses. For example, suppose that the first fn
has a where-clause like `i32: Bar<u32>`, which in fact does not
hold. This will "fool" trait resolution into thinking that `i32:
Bar<u32>` holds. This is ok currently, because it means that the
first fn can never be calle (since its where clauses cannot be
satisfied), but if the first fn's successful resolution is cached, it
can allow other fns to compile that should not. This problem is fixed
in the next commit.
In https://github.com/rust-lang/rust/pull/23289, I did not include the type information for searching for orphan methods (methods that are defined in a module and implemented in another - doing this causes rustdoc sometimes to first find the impl before the actual type).
This PR fixes this. By merging this, searches for `char -> bool` will also find `is_alphabetic`, for example (which otherwise was only found for `charext -> bool`).
cc @alexcrichton
Use result of the computation to prevent the compiler from optimising
too much. Change `_x` to `x` and therefore remove the paragraph about
the underscore.
Fixes#25855.
Because these structures are created by a macro, the doc comments
don't quite work: the leading /// isn't stripped. Instead, just
use #[doc] so that they render correctly.
musl may not be available on the target user's machine, and even if it is, we may not be able to find it because of how static libraries are searched for.
Instead, use the liblibc archive created at rust compile time which already contains libc.a.
---
To be honest, my brain is bending a bit at this point and I wonder if I'm doing something a bit stupid.
Problem: building the libc crate with target musl. It says "could not find native static library `c`, perhaps an -L flag is missing?".
Some pondering: the key problem is the way static archives are searched for (note that a musl build attempts to statically link to libc) - they aren't. There are three locations which are checked (including `$PREFIX/lib/rustlib/x86_64-unknown-linux-musl/lib`), but this does not include `$PREFIX/lib`...and it probably shouldn't - rustc is mimicking the way native lib generation works by forcing you to provide the path yourself. You can make it work `cargo rustc` with `-L native=/path/to/musl/lib`, but even if this went in a build script for the libc crate, it wouldn't work if musl isn't installed by the end user.
I've sprinkled `not(test)` around but I've no idea if I've done it right.
This patch allows `cargo build --target x86_64-unknown-linux-musl` to work on a crate with a dependency on libc, where the musl-enabled rust was compiled before this patch. I've not yet kicked off the long process to build a musl-enabled rust with this patch, so it might be broken there.
Sorry for the rambling.
r? @alexcrichton
musl may not be available on the target user's machine, and even if
it is, we may not be able to find it because of how static libraries
are searched for.
Instead, use the transitively included liblibc which includes libc.a.
