| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
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`
|
|
|
|
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.)
|
|
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
|
|
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
|
|
|
|
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 #145168.
|
|
Implement `ptr_cast_array`
ACP: https://github.com/rust-lang/libs-team/issues/602
Tracking Issue: https://github.com/rust-lang/rust/issues/144514
|
|
- remove some stabilized target features from `gate.rs`
|
|
|
|
Add `cast_init` and `cast_uninit` methods for pointers
ACP: rust-lang/libs-team#627
Tracking issue: rust-lang/rust#145036
This includes an incredibly low-effort search to find uses that could be switched to using these methods. I only searched for `cast::<\w>` and `cast::<MaybeUninit` because there would otherwise be way too much to look through, and I also didn't modify anything inside submodules/subtrees.
|
|
Adjust documentation of `dangling`
I believe the current doc of `dangling` is slightly off as it indicates:
`Note that the pointer value may potentially represent a valid pointer to a T`
The returned pointer has no provenance, so it may not be a valid pointer (except in the case of ZSTs, but I don't think this is what the documentation is trying to warn about).
See: https://rust-lang.zulipchat.com/#narrow/channel/136281-t-opsem/topic/Dangling.20pointers.3A.20definition
The value returned by dangling may never be used to dereference a value that isn't a ZST, even if address equality is detected with that of a valid pointer.
This is a minor fix, but this doc still got me confused for a second
|
|
Add ASCII-related methods from `u8` and `MIN`/`MAX` to `core::ascii::Char`
* Add ASCII-related methods from `u8` to `core::ascii::Char`.
* Add `core::ascii::Char::MIN` and `core::ascii::Char::MAX`.
|
|
|
|
Signed-off-by: Sacha Ayoun <sachaayoun@gmail.com>
|
|
Without any tests/benchmarks that show some improvement, it's hard to
know whether the change had any positive effect at all. (And if it did,
whether that effect is still achieved today.)
|
|
|
|
|
|
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.
|
|
document assumptions about `Clone` and `Eq` traits
Most standard library collections break if `Clone` has a non-standard implementation which violates `x.clone() == x`. [Here](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=b7fc6dfa8410cbb673eb8d38393d81de) the resulting broken behaviour of different collections is shown. I originally created an issue at https://github.com/rust-lang/hashbrown/issues/629, but the conclusion there was that `x.clone()` resulting in an object that compares equal to the original one is probably a very universal assumption. However, this assumption is (to my knowledge) not documented anywhere.
I propose to make this assumption explicit in the `Clone` trait documentation. The property that seems the most reasonable to me is the following: When implementing both `Clone` and `PartialEq`, then
```text
x == x -> x.clone() == x
```
is expected to hold. This way, when also implementing `Eq`, it automatically follows that `x.clone() == x` has to hold, which should be enough for the collections to not break. At the same time, the property also works for the "normal" elements of a type with `PartialEq`. For the wording, I tried to follow the [`Hash` and `Eq`](https://doc.rust-lang.org/std/hash/trait.Hash.html#hash-and-eq) documentation.
As I am fairly new to Rust, it might well be that this property cannot be generally expected – it seems reasonable to me, but any counter-examples or critique, both content- and wording-wise, would be very welcome. If the property turns out to be too general, I would suggest to at least document the assumption of `x.clone() == x` for the collections somehow.
An additional thought of mine:
If it is indeed generally expected that `x == x -> x.clone() == x`, then, for the sake of completeness, one could also define that `x != x -> y != y for y = x.clone()` should hold, i.e., that an object that did not compare equal to itself before cloning, should also not compare equal to itself afterwards.
|
