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 commit moves the free functions in the `rc`, `arc`, and `boxed` modules to
associated functions on their respective types, following the recent trend
towards this pattern. The previous free functions are all left in-place with
`#[deprecated]` pointers towards the new locations.
This commit also deprecates `arc::get_mut` and `Arc::make_unique` with no
replacement as they are racy in the face of weak pointers.
The `thread::scoped` function will never be stabilized as-is and the API will
likely change significantly if it does, so this function is deprecated for
removal.
This commit stabilizes the `str::{matches, rmatches}` functions and iterators,
but renames the unstable feature for the `str::{matches,rmatches}_indices`
function to `str_match_indices` due to the comment present on the functions
about the iterator's return value.
This function follows the well-established "constructor" pattern and the
initialization constant will likely be deprecated in favor of it once `const_fn`
is stabilized.
This commit stabilizes the remaining `wrapping_*` functions on the primitive
integer types as they follow the same conventions as other wrapping methods are
were likely just initially unstable to be conservative.
Unsafe patterns such as `slice::from_raw_parts` and `CStr::from_ptr` have shown
that dealing with lifetimes, while useful, is often a hindrance. Consequently
these functions are rarely called today and are being deprecated.
Neither of these iterators has seen enough usage to justify their position in
the standard library, so these unstable iterators are being slated for deletion.
This trait has not proven itself over time as being core and fundamentally
useful to iterators, so it's being deprecated to allow time to iterate on it out
of tree.
This commit shards the broad `core` feature of the libcore library into finer
grained features. This split groups together similar APIs and enables tracking
each API separately, giving a better sense of where each feature is within the
stabilization process.
A few minor APIs were deprecated along the way:
* Iterator::reverse_in_place
* marker::NoCopy
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.
Previously, it said "import `Foo` conflicts with existing submodule" even
when it was a type alias, enum, or trait. The message now says the conflict
is with "type in this module" in the case of the first two, and "trait in
this module" for the last one.
Fixes#24081.
