| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Use OnceCell in cell module documentation
The spanning tree example in the std cell module implementation was created before `OnceCell` was added to Rust so it uses `RefCell`. However, in this case using `OnceCell` seems more appropriate and produces simpler code. As a bonus, this also means that all three cell types are presented in the examples of std cell module.
|
|
Simplify Default for tuples
Doesn't need a separate block for each element
|
|
Add support for making lib features internal
We have the notion of an "internal" lang feature: a feature that is never intended to be stabilized, and using which can cause ICEs and other issues without that being considered a bug.
This extends that idea to lib features as well. It is an alternative to https://github.com/rust-lang/rust/pull/115623: instead of using an attribute to declare lib features internal, we simply do this based on the name. Everything ending in `_internals` or `_internal` is considered internal.
Then we rename `core_intrinsics` to `core_intrinsics_internal`, which fixes https://github.com/rust-lang/rust/issues/115597.
|
|
Make the following API stable:
// in core::any
pub fn type_name_of_val<T: ?Sized>(_val: &T) -> &'static str
Const stability is not added because this relies on `type_name` which is also
not const. That has a blocking issue.
Fixes #66359
|
|
make sure panic_nounwind_fmt can still be fully inlined (e.g. for panic_immediate_abort)
Follow-up to https://github.com/rust-lang/rust/pull/110303.
|
|
Now using a window of 3 instead 2 because it removes any
confusion about exactly how consecutive windows overlap
|
|
Add an assume that the index is inbounds to slice::get_unchecked
Fixes #116878
|
|
|
|
|
|
|
|
move exposed-provenance APIs into separate feature gate
We have already stated explicitly for all the 'exposed' functions that
> Using this method means that code is *not* following strict provenance rules.
However, they were part of the same feature gate and still described as part of the strict provenance experiment. Unfortunately, their semantics are much less clear and certainly nowhere near stabilization, so in preparation for an attempt to stabilize the strict provenance APIs, I suggest we split the things related to "exposed" into their own feature gate. I also used this opportunity to better explain how Exposed Provenance fits into the larger plan here: this is *one possible candidate* for `as` semantics, but we don't know if it is actually viable, so we can't really promise that it is equivalent to `as`. If it works out we probably want to make `as` equivalent to the 'exposed' APIs; if it doesn't, we will remove them again and try to find some other semantics for `as`.
|
|
warn against using intrinsics that leave the scope of our memory model
|
|
r=workingjubilee
Portable SIMD subtree update
Syncs nightly to the latest changes from rust-lang/portable-simd
r? `@rust-lang/libs`
|
|
|
|
|
|
|
|
relationship of Exposed Provenance and Strict Provenance
|
|
The functionality of these methods from `split_array` has been absorbed by the
`slice_first_last_chunk` feature. This only affects the methods on slices,
not those with the same name that are implemented on array types.
Also adjusts testing to reflect this change.
|
|
|
|
Use `usize::repeat_u8` instead of implementing `repeat_byte` in `memchr.rs`
It's simpler that way and the tricks don't actually make a difference: https://godbolt.org/z/zrvYY1dGx
|
|
also add is_empty to const raw slices
We have this on mutable raw slices but not const raw slices, which makes little sense.
Cc https://github.com/rust-lang/rust/issues/71146
|
|
remove the memcpy-on-equal-ptrs assumption
One of the libc we support, musl, [defines `memcpy` with `restrict` pointers](https://git.musl-libc.org/cgit/musl/tree/src/string/memcpy.c#n5). This in fact matches the definition in the C standard. Calling that `memcpy` with overlapping pointers is clearly UB, who knows what the compiler did when optimizing this `memcpy` -- it certainly assumed source and destination to be disjoint.
Lucky enough, it does not seem like we actually need this assumption that `memcpy(p, p, n)` is always allowed. clang and GCC need it since they use `memcpy` to compile C assignments, but [we use memmove for similar code](https://godbolt.org/z/bcW85WYcM). There are no known cases where LLVM introduces calls to memcpy on equal pointers itself. (And if there were, that would be a soundness bug in rustc due to the musl issue mentioned above.)
This does mean we must make sure to never call the LLVM `memcpy` builtin on equal ranges even though the LangRef says that is allowed. Currently that is the case so we just need to make sure it remains the case. :) Cc `@rust-lang/opsem` `@rust-lang/wg-llvm`
|
|
add track_caller for arith ops
Fixes #114814
`#[track_caller]` is works, r? `@scottmcm`
|
|
|
|
Expand in-place iteration specialization to Flatten, FlatMap and ArrayChunks
This enables the following cases to collect in-place:
```rust
let v = vec![[0u8; 4]; 1024]
let v: Vec<_> = v.into_iter().flatten().collect();
let v: Vec<Option<NonZeroUsize>> = vec![NonZeroUsize::new(0); 1024];
let v: Vec<_> = v.into_iter().flatten().collect();
let v = vec![u8; 4096];
let v: Vec<_> = v.into_iter().array_chunks::<4>().collect();
```
Especially the nicheful-option-flattening should be useful in real code.
|
|
Fix comments for unsigned non-zero `checked_add`, `saturating_add`
While looking at #118313, I happened to notice that two of the expanded comments appear to be slightly inaccurate.
For these two methods, `other` is an ordinary unsigned integer, so it can be zero.
Since the sum of non-zero and zero is always non-zero, the safety argument holds even when `other` is zero.
|
|
Update mod comment
The comment of `ASCII_CASE_MASK` on line 477 is `If 6th bit is set ascii is lower case.` but the original comment of `*self ^ ((self.is_ascii_lowercase() as u8) * ASCII_CASE_MASK)` was `Toggle the fifth bit if this is a lowercase letter`
|
|
optimize str::iter::Chars::advance_by
```
OLD:
str::iter::chars_advance_by_0001 0.00ns/iter +/- 0.00ns
str::iter::chars_advance_by_0010 13.00ns/iter +/- 1.00ns
str::iter::chars_advance_by_1000 1.20µs/iter +/- 15.00ns
NEW:
str::iter::chars_advance_by_0001 0.00ns/iter +/- 0.00ns
str::iter::chars_advance_by_0010 6.00ns/iter +/- 0.00ns
str::iter::chars_advance_by_1000 75.00ns/iter +/- 1.00ns
```
|
|
For these two methods, `other` is an ordinary unsigned integer, so it can be zero.
Since the sum of non-zero and zero is always non-zero, the safety argument
holds even when `other` is zero.
|
|
this avoids part of the char decoding work by not looking at utf8 continuation bytes
|
|
|
|
panic_immediate_abort)
|
|
|
|
r=notriddle
rustdoc: Remove space from fake-variadic fn ptr impls
before: `for fn (T₁, T₂, …, Tₙ) -> Ret`
after: `for fn(T₁, T₂, …, Tₙ) -> Ret`
I don't think we usually have spaces there, so it looks weird.
cc `@notriddle` since you added the space in https://github.com/rust-lang/rust/pull/98180 (or rather, added the feature with a space included).
|
|
|
|
r=thomcc
Improve some comments for non-zero ops
This makes them a bit more explicit/correct.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
before: `for fn (T₁, T₂, …, Tₙ) -> Ret`
after: `for fn(T₁, T₂, …, Tₙ) -> Ret`
|
|
|
|
|
|
|
|
|
|
|
|
Add `debug_assert_nounwind` and convert `assert_unsafe_precondition`
`assert_unsafe_precondition` checks non-CTFE-evaluable conditions in runtime and performs no-op in compile time, while many of its current usage can be checked during const eval.
|
|
|
