bufreader::Buffer::backshift: don't move the uninit bytes
previous code was perfectly sound because of MaybeUninit, but it did waste cycles on copying memory that is known to be uninitialized.
Rust build fails on OpenBSD after using file_lock feature
PR 130999 added the file_lock feature, but doesn't included OpenBSD in the supported targets (Tier 3 platform), leading to a compilation error ("try_lock() not supported").
Cc `@cberner`
Related to rust-lang/rust#130999
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``
[RTE-513] Ignore sleep_until test on SGX
rust-lang/rust#141829 added a test for `sleep_until`: it checks whether its specification holds:
> Puts the current thread to sleep until the specified deadline has passed.
but in SGX there's no secure time source. There's only the ability to request the `insecure_time` from outside of the enclave through a [usercall](https://github.com/fortanix/rust-sgx/blob/master/intel-sgx/fortanix-sgx-abi/src/lib.rs#L590-L592) and the ability to [wait](https://github.com/rust-lang/rust/blob/master/library/std/src/sys/pal/sgx/abi/usercalls/mod.rs#L173-L179) for a certain event or timeout. But both are under the control of an attacker; users should not depend on the accuracy nor correctness of this time. We try to even enforce this by adding a +/-10% time interval to wait usercalls.
The current `thread::sleep_until` implementation uses this `wait` usercall. When a negative randomization interval is added to the timeout passed in `wait`, the test fails. As users should not rely on the correctness of any time inside the enclave, it should be considered an incorrect test on SGX. This PR ignores this test.
`impl PartialEq<{str,String}> for {Path,PathBuf}`
This is a revival of #105877
Comparison of paths and strings is expected to be possible and needed e.g. in tests. This change adds the impls os `PartialEq` between strings and paths, both owned and unsized, in both directions.
ACP: https://github.com/rust-lang/libs-team/issues/151
library: Migrate from `cfg_if` to `cfg_select`
Migrate the standard library from using the external `cfg_if` crate to using the now-built-in `cfg_select` macro.
This does not yet eliminate the dependency from `library/std/Cargo.toml`, because while the standard library itself no longer uses `cfg_if`, it also incorporates the `backtrace` crate, which does.
Migration assisted by the following vim command (after selecting the full `cfg_if!` invocation):
```
'<,'>s/\(cfg_if::\)\?cfg_if/cfg_select/ | '<,'>s/^\( *\)} else {/\1}\r\1_ => {/c | '<,'>s/^\( *\)} else if #\[cfg(\(.*\))\] /\1}\r\1\2 => /e | '<,'>s/if #\[cfg(\(.*\))\] {/\1 => {/e
```
This is imperfect, but substantially accelerated the process. This prompts for confirmation on the `} else {` since that can also appear inside one of the arms. This also requires manual intervention to handle any multi-line conditions.
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`
PR 130999 added the file_lock feature, but doesn't included OpenBSD in the supported targets (Tier 3 platform), leading to a compilation error ("try_lock() not supported").
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`
Migrate the standard library from using the external `cfg_if` crate to
using the now-built-in `cfg_select` macro.
This does not yet eliminate the dependency from
`library/std/Cargo.toml`, because while the standard library itself no
longer uses `cfg_if`, it also incorporates the `backtrace` crate, which
does.
Migration assisted by the following vim command (after selecting the
full `cfg_if!` invocation):
```
'<,'>s/\(cfg_if::\)\?cfg_if/cfg_select/ | '<,'>s/^\( *\)} else {/\1}\r\1_ => {/c | '<,'>s/^\( *\)} else if #\[cfg(\(.*\))\] /\1}\r\1\2 => /e | '<,'>s/if #\[cfg(\(.*\))\] {/\1 => {/e
```
This is imperfect, but substantially accelerated the process. This
prompts for confirmation on the `} else {` since that can also appear
inside one of the arms. This also requires manual intervention to handle
any multi-line conditions.
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.
std: thread: Return error if setting thread stack size fails
Currently, when setting the thread stack size fails, it would be rounded up to the nearest multiple of the page size and the code asserts that the next call to `pthread_attr_setstacksize` succeeds.
This may be true for glibc, but it isn't true for musl, which not only enforces a minimum stack size, but also a maximum stack size of `usize::MAX / 4 - PTHREAD_STACK_MIN` [1], triggering the assert rather than erroring gracefully.
There isn't any way to handle this properly other than bailing out and letting the user know it didn't succeed.
[1]: https://git.musl-libc.org/cgit/musl/tree/src/thread/pthread_attr_setstacksize.c#n5
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.
