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.
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!
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
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.
