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".
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``
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.
Fixesrust-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
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.
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
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.
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.
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`.
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.)
