| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This prevents a relocation in the text section. Text relocations are
incompatible with hardened kernels.
https://github.com/rust-lang/rust/issues/5714
|
|
|
|
The font can make this hard to read, and we don't even strictly need
the annotation, so let's just remove it
Fixes #26287
|
|
Using the wrong landing pad has obvious bad effects, like dropping a value
twice.
Testcase written by Alex Crichton.
Fixes #25089.
|
|
This naming needs to consider the raw vs ptr naming of
Box/CStr/CString/slice/etc.
|
|
These functions mirror the other Entry APIs of other maps, and were mistakenly
just not stabilized the first time around.
|
|
* Add `#[doc(hidden)]`
* Rename away from `Error::description`
|
|
Also add `#[doc(hidden)]` to a few internal functions.
|
|
|
|
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.
|
|
This has been replaced with `FnBox`
|
|
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 deprecates the `sync::Future` type to be developed outside in
crates.io instead.
|
|
These two functions should be replaceable with the `process::exit` function.
|
|
Questions about the utility of this type has caused it to move to crates.io in
the `bufstream` crate, so this type can be deprecated.
|
|
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 commit stabilizes these two iterator primitives as they have gone through
the RFC process and had some time to bake now.
|
|
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.
|
|
These accessor/constructor methods for a `PoisonError` are quite standard for a
wrapper type and enable manipulation of the underlying type.
|
|
This function is more naturally expressed as slice::from_raw_buf plus a call to
to_vec.
|
|
These methods have been unstable for quite some time, and it's not clear that
these should remain in the standard library.
|
|
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.
|
|
These constants have been unstable for some time now already
|
|
These were just exposed to be used elsewhere at some point, but neither is
currently being used so just make them private again.
|
|
This trait has seen very little usage and while safe, may not belong in the
standard library.
|
|
This function has seen very little use and it seems better to explore this
functionality through iterator adaptors instead of specialized functions.
|
|
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 also deprecates the `as_string` and `as_slice` free functions in the
`string` and `vec` modules.
|
|
|
|
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
|
|
Rebase of #21468.
Fix #25960.
|
|
|
|
|
|
Also, it feels more suitable to use hex to represent unicode
|
|
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`.
|
|
|
|
Fixes #22864
|
|
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.
|
|
PR for #26128.
Improves codegen in deriving by utilizing the discriminant_value intrinsic.
I have a more detailed comment on the changes in a comment on the issue [here](https://github.com/rust-lang/rust/issues/26128#issuecomment-111509863)
### Old
```
running 7 tests
test large_c_like ... bench: 2,694,129 ns/iter (+/- 5,170)
test large_c_like_ord ... bench: 2,723,521 ns/iter (+/- 9,098)
test test1_partial_eq ... bench: 2,439,317 ns/iter (+/- 2,135)
test test1_partial_ord ... bench: 2,499,114 ns/iter (+/- 55,766)
test test2_partial_eq ... bench: 3,562,815 ns/iter (+/- 45,590)
test test2_partial_ord ... bench: 3,398,306 ns/iter (+/- 22,180)
test test_match_success ... bench: 1,509,267 ns/iter (+/- 1,982)
```
### New
```
running 7 tests
test large_c_like ... bench: 286,509 ns/iter (+/- 474)
test large_c_like_ord ... bench: 286,666 ns/iter (+/- 8,756)
test test1_partial_eq ... bench: 286,584 ns/iter (+/- 2,789)
test test1_partial_ord ... bench: 286,470 ns/iter (+/- 516)
test test2_partial_eq ... bench: 2,228,997 ns/iter (+/- 34,191)
test test2_partial_ord ... bench: 1,731,699 ns/iter (+/- 21,756)
test test_match_success ... bench: 1,509,630 ns/iter (+[- 3,765)
```
[Benchmark](https://gist.github.com/Marwes/7c0b3468d0cae972a2b4)
|
|
|
|
|
|
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
|
|
|
