| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Consolidate all the panicking functions in `slice/index.rs` to use a single
`slice_index_fail` function, similar to how it is done in `str/traits.rs`.
|
|
Fix typo in docstring
The return type is correct in the source code but incorrect in the docstring.
|
|
UnsafePinned::raw_get: sync signature with get
This was forgotten in https://github.com/rust-lang/rust/pull/142162.
Tracking issue: https://github.com/rust-lang/rust/issues/125735.
|
|
stabilize `const_array_each_ref`
cc rust-lang/rust#133289, needs FCP.
|
|
|
|
|
|
|
|
The return type is correct in the source code but incorrect in the docstring
|
|
|
|
add a fallback implementation for the `prefetch_*` intrinsics
related ACP: https://github.com/rust-lang/libs-team/issues/638
The fallback is to just ignore the arguments. That is a valid implementation because this intrinsic is just a hint.
I also added the `miri::intrinsic_fallback_is_spec` annotation, so that miri now supports these operations. A prefetch intrinsic call is valid on any pointer. (specifically LLVM guarantees this https://llvm.org/docs/LangRef.html#llvm-prefetch-intrinsic)
Next, I made the `LOCALITY` argument a const generic. That argument must be const (otherwise LLVM crashes), but that was not reflected in the type.
Finally, with these changes, the intrinsic can be safe and `const` (a prefetch at const evaluation time is just a no-op).
cc `@Amanieu`
r? `@RalfJung`
|
|
Implement feature `int_lowest_highest_one` for integer and NonZero types
Tracking issue: rust-lang/rust#145203
Implement the accepted ACP rust-lang/rust#145203 for methods that find the index of the least significant (lowest) and most significant (highest) set bit in an integer for signed, unsigned, and NonZero types.
Also add unit tests for all these types.
|
|
Fix parameter order for `_by()` variants of `min` / `max`/ `minmax` in `std::cmp`
We saw a regression introduced in version `1.86` that seems to be coming from switching the order of `v1` and `v2` when calling `comparison` functions in `min_by` / `max_by` / `minmax_by` (cf. this PR: https://github.com/rust-lang/rust/pull/136307)
When the `compare` function is not symmetric in the arguments, this leads to false results. Apparently, the test cases do not cover this scenario currently. While asymmetric comparison may be an edge case, but current behavior is unexpected nevertheless.
|
|
|
|
The fallback is to just ignore the arguments. That is a valid implementation because this intrinsic is just a hint.
I also added `miri::intrinsic_fallback_is_spec` annotation, so that miri now supports these operations. A prefetch intrinsic call is valid on any pointer.
|
|
Hide docs for `core::unicode`
This module is perma-unstable and shouldn't show up in the public docs. If people want to see the docs for it, they can still run `RUSTDOCFLAGS=--document-hidden-items ./x doc library/core`.
|
|
dec2flt: Provide more valid inputs examples
I was just looking at the specifics of how the parsing is handled here and I wasn't sure if the examples were incomplete or the grammar below was misleading.
The grammar was correct so I figured I'd add these examples to clarify.
|
|
Correct some grammar in integer documentation
Update "between" to "among" (more than two items), connect the "which" dependent clause to the independent part, and remove the redundant "here".
|
|
fmt of non-decimal radix untangled
Have the implementation match its decimal counterpart.
* Digit table instead of conversion functions
* Correct buffer size per radix
* Elimination of dead code for negative
* No trait abstraction for integers
#### Original Performance
```
fmt::write_10ints_bin 393.03ns/iter +/- 1.41
fmt::write_10ints_hex 316.84ns/iter +/- 1.49
fmt::write_10ints_oct 327.16ns/iter +/- 0.46
```
#### Patched Performance
```
fmt::write_10ints_bin 392.31ns/iter +/- 3.05
fmt::write_10ints_hex 302.41ns/iter +/- 5.48
fmt::write_10ints_oct 322.01ns/iter +/- 3.82
```
r? tgross35
|
|
|
|
|
|
|
|
Remove the `From` derive macro from prelude
The new `#[derive(From)]` functionality (implemented in https://github.com/rust-lang/rust/pull/144922) caused name resolution ambiguity issues (https://github.com/rust-lang/rust/issues/145524). The reproducer looks e.g. like this:
```rust
mod foo {
pub use derive_more::From;
}
use foo::*;
#[derive(From)] // ERROR: `From` is ambiguous
struct S(u32);
```
It's pretty unfortunate that it works like this, but I guess that there's not much to be done here, and we'll have to wait for the next edition to put the `From` macro into the prelude. That will probably require https://github.com/rust-lang/rust/pull/139493 to land.
I created a new module in core (and re-exported it in std) called `from`, where I re-exported the `From` macro. I *think* that since this is a new module, it should not have the same backwards incompatibility issue.
Happy to hear suggestions about the naming - maybe it would make sense as `core::macros::from::From`? But we already had a precedent in the `core::assert_matches` module, so I just followed suit.
Fixes: https://github.com/rust-lang/rust/issues/145524
r? ``@petrochenkov``
|
|
Trivial improve doc for transpose
When I saw old doc, I felt a little confused.
Seems it would be clearer this way.
|
|
Stabilize `ip_from`
Tracking issue: rust-lang/rust#131360
Stabilizes and const-stabilizes the following APIs:
```rust
// core::net
impl Ipv4Addr {
pub const fn from_octets(octets: [u8; 4]) -> Ipv4Addr;
}
impl Ipv6Addr {
pub const fn from_octets(octets: [u8; 16]) -> Ipv6Addr;
pub const fn from_segments(segments: [u16; 8]) -> Ipv6Addr;
}
```
Closes rust-lang/rust#131360
```@rustbot``` label +needs-fcp
|
|
To avoid backwards compatibility problems.
|
|
Implement the accepted ACP for methods that find the index of the least
significant (lowest) and most significant (highest) set bit in an
integer for signed, unsigned, and NonZero types.
Also add unit tests for all these types.
|
|
Print regions in `type_name`.
Currently they are skipped, which is a bit weird, and it sometimes causes malformed output like `Foo<>` and `dyn Bar<, A = u32>`.
Most regions are erased by the time `type_name` does its work. So all regions are now printed as `'_` in non-optional places. Not perfect, but better than the status quo.
`c_name` is updated to trim lifetimes from MIR pass names, so that the `PASS_NAMES` sanity check still works. It is also renamed as `simplify_pass_type_name` and made non-const, because it doesn't need to be const and the non-const implementation is much shorter.
The commit also renames `should_print_region` as `should_print_optional_region`, which makes it clearer that it only applies to some regions.
Fixes rust-lang/rust#145168.
r? `@lcnr`
|
|
const-eval: full support for pointer fragments
This fixes https://github.com/rust-lang/const-eval/issues/72 and makes `swap_nonoverlapping` fully work in const-eval by enhancing per-byte provenance tracking with tracking of *which* of the bytes of the pointer this one is. Later, if we see all the same bytes in the exact same order, we can treat it like a whole pointer again without ever risking a leak of the data bytes (that encode the offset into the allocation). This lifts the limitation that was discussed quite a bit in https://github.com/rust-lang/rust/pull/137280.
For a concrete piece of code that used to fail and now works properly consider this example doing a byte-for-byte memcpy in const without using intrinsics:
```rust
use std::{mem::{self, MaybeUninit}, ptr};
type Byte = MaybeUninit<u8>;
const unsafe fn memcpy(dst: *mut Byte, src: *const Byte, n: usize) {
let mut i = 0;
while i < n {
*dst.add(i) = *src.add(i);
i += 1;
}
}
const _MEMCPY: () = unsafe {
let ptr = &42;
let mut ptr2 = ptr::null::<i32>();
// Copy from ptr to ptr2.
memcpy(&mut ptr2 as *mut _ as *mut _, &ptr as *const _ as *const _, mem::size_of::<&i32>());
assert!(*ptr2 == 42);
};
```
What makes this code tricky is that pointers are "opaque blobs" in const-eval, we cannot just let people look at the individual bytes since *we don't know what those bytes look like* -- that depends on the absolute address the pointed-to object will be placed at. The code above "breaks apart" a pointer into individual bytes, and then puts them back together in the same order elsewhere. This PR implements the logic to properly track how those individual bytes relate to the original pointer, and to recognize when they are in the right order again.
We still reject constants where the final value contains a not-fully-put-together pointer: I have no idea how one could construct an LLVM global where one byte is defined as "the 3rd byte of a pointer to that other global over there" -- and even if LLVM supports this somehow, we can leave implementing that to a future PR. It seems unlikely to me anyone would even want this, but who knows.^^
This also changes the behavior of Miri, by tracking the order of bytes with provenance and only considering a pointer to have valid provenance if all bytes are in the original order again. This is related to https://github.com/rust-lang/unsafe-code-guidelines/issues/558. It means one cannot implement XOR linked lists with strict provenance any more, which is however only of theoretical interest. Practically I am curious if anyone will show up with any code that Miri now complains about - that would be interesting data. Cc `@rust-lang/opsem`
|
|
Save a few instructions in `encode_utf8_raw_unchecked` by performing
manual CSE.
|
|
|
|
Revert "Partially outline code inside the panic! macro".
This reverts https://github.com/rust-lang/rust/pull/115670
Without any tests/benchmarks that show some improvement, it's hard to know whether the change had any positive effect. (And if it did, whether that effect is still achieved today.)
|
|
According to
https://www.unicode.org/policies/stability_policy.html#Property_Value,
the set of codepoints in `Cc` will never change. So we can hard-code
the patterns to match against instead of using a table.
|
|
Stabilize `const_exposed_provenance` feature
This closes [tracking issue](https://github.com/rust-lang/rust/issues/144538) and stabilises `fn with_exposed_provenance` and `fn with_exposed_provenance_mut` in const
|
|
r=jhpratt
Stabilize `core::iter::chain`
Closes rust-lang/rust#125964
|
|
Implement `#[derive(From)]`
Implements the `#[derive(From)]` feature ([tracking issue](https://github.com/rust-lang/rust/issues/144889), [RFC](https://github.com/rust-lang/rfcs/pull/3809)).
It allows deriving the `From` impl on structs and tuple structs with exactly one field. Some implementation notes:
- I wasn't exactly sure which spans to use in the derive generating code, so I just used `span` everywhere. I don't know if it's the Right Thing To Do. In particular the errors when `#[derive(From)]` is used on a struct with an unsized field are weirdly duplicated.
- I had to solve an import stability problem, where if I just added the unstable `macro From` to `core::convert`, previously working code like `use std::convert::From` would suddenly require an unstable feature gate, because rustc would think that you're trying to import the unstable macro. `@petrochenkov` suggested that I add the macro the the core prelude instead. This has worked well, although it only works in edition 2021+. Not sure if I botched the prelude somehow and it should live elsewhere (?).
- I had to add `Ty::AstTy`, because the `from` function receives an argument with the type of the single field, and the existing variants of the `Ty` enum couldn't represent an arbitrary type.
|
|
Stabilize as_array_of_cells
This PR stabilizes
```rust
impl<T, const N: usize> Cell<[T; N]> {
pub const fn as_array_of_cells(&self) -> &[Cell<T>; N];
}
```
Stabilization report: https://github.com/rust-lang/rust/issues/88248#issuecomment-3082986863
Closes: https://github.com/rust-lang/rust/issues/88248
|
|
|
|
|
|
|
|
|
|
r=petrochenkov
Resolve the prelude import in `build_reduced_graph`
This pr tries to resolve the prelude import at the `build_reduced_graph` stage.
Part of batched import resolution in rust-lang/rust#145108 (cherry picked commit) and maybe needed for rust-lang/rust#139493.
r? petrochenkov
|
|
r=Mark-Simulacrum
Fix description of unsigned `checked_exact_div`
Like its signed counterpart, this function does not panic. Also, fix the examples to document how it returns Some/None.
|
|
Implement autodiff using intrinsics
This PR aims to move autodiff logic to `autodiff` intrinsic. Allowing us to delete a great part of our frontend code and overall, simplify the compilation pipeline of autodiff functions.
|
|
Add Ref/RefMut try_map method
Tracking issue: rust-lang/rust#143801
A more generalized version of [`filter_map`](https://doc.rust-lang.org/stable/core/cell/struct.Ref.html#method.filter_map), which allows to return some data on failure.
## Safety
As far as I can tell, `E` cannot contain any `'b` data, so it is impossible to duplicate the `&'b [mut]` reference into the `RefCell`'s data.
Other than this `E`, everything is analogous to the already stable `filter_map`.
## `Try` / `Residual`
I have considered generalizing this to use the `Try` & `Residual` just like rust-lang/rust#79711 does for `array::try_map`, but it does not seem to be possible: we want to essentially `.map_err(|e| (orig, e))` but this does not seem to be supported with `Try`. (Plus I am not even sure if it is possible to express the fact that `&U` in `Try::Output` would have to have the same lifetime as the `&T` input of `F`.)
## ACP
~As far as I can tell, this [is not mandatory](https://std-dev-guide.rust-lang.org/development/feature-lifecycle.html#suitability-for-the-standard-library), and the implementation is small enough to probably be smaller than the doc I would have to write.~
~https://github.com/rust-lang/libs-team/issues/341~
https://github.com/rust-lang/libs-team/issues/586
|
|
Include the sizes of the `to_lowercase` and `to_uppercase` tables in the
total size calculations.
|
|
To make changes in table size obvious from git diffs
|
|
cfg_select: Support unbraced expressions
Tracking issue for `cfg_select`: rust-lang/rust#115585
When operating on expressions, `cfg_select!` can now handle expressions
without braces. (It still requires braces for other things, such as
items.)
Expand the test coverage and documentation accordingly.
---
I'm not sure whether deciding to extend `cfg_select!` in this way is T-lang or T-libs-api. I've labeled for both, with the request that both teams don't block on each other. :)
|
|
|
|
|
|
Stabilize `sse4a` and `tbm` target features
This PR stabilizes the feature flag `sse4a_target_feature` and `tbm_target_feature` (tracking issue rust-lang/rust#44839).
# Public API
The 2 `x86` target features `sse4a` and `tbm`
Also, these were added in LLVM2.6 and LLVM3.4-rc1, respectively, and as the minimum LLVM required for rustc is LLVM19, we are safe in that front too!
As all of the required tasks have been done (adding the target features to rustc, implementing their runtime detection in std_detect and implementing the associated intrinsics in core_arch), these target features can be stabilized now. The intrinsics were stabilized *long* ago, in 1.27.0
Reference PR:
- https://github.com/rust-lang/reference/pull/1949
cc `@rust-lang/lang`
`@rustbot` label I-lang-nominated
r? lang
|
