Bump backtrace to 0.3.74~ish
Commit: https://github.com/rust-lang/backtrace-rs/commit/230570f
This should help with backtraces on Android, QNX NTO 7.0, and Windows.
It addresses a case of backtrace incurring undefined behavior on Android.
Re-enable android tests/benches in alloc/core
This is basically a revert of https://github.com/rust-lang/rust/pull/73729. These tests better work on android now; it's been 4 years and we don't use dlmalloc on that target anymore.
And I've validated that they should pass now with a try-build :)
This commit fixes an assert in the WASI-specific implementation of
thread sleep to ensure that sleeping for a very large period of time
blocks instead of panicking. This can come up when testing programs that
sleep "forever", for example.
debug-fmt-detail option
I'd like to propose a new option that makes `#[derive(Debug)]` generate no-op implementations that don't print anything, and makes `{:?}` in format strings a no-op.
There are a couple of motivations for this:
1. A more thorough stripping of debug symbols. Binaries stripped of debug symbols still retain some of them through `Debug` implementations. It's hard to avoid that without compiler's help, because debug formatting can be used in many places, including dependencies, and their loggers, asserts, panics, etc.
* In my testing it gives about 2% binary size reduction on top of all other binary-minimizing best practices (including `panic_immediate_abort`). There are targets like Web WASM or embedded where users pay attention to binary sizes.
* Users distributing closed-source binaries may not want to "leak" any symbol names as a matter of principle.
2. Adds ability to test whether code depends on specifics of the `Debug` format implementation in unwise ways (e.g. trying to get data unavailable via public interface, or using it as a serialization format). Because current Rust's debug implementation doesn't change, there's a risk of it becoming a fragile de-facto API that [won't be possible to change in the future](https://www.hyrumslaw.com/). An option that "breaks" it can act as a [grease](https://www.rfc-editor.org/rfc/rfc8701.html).
This implementation is a `-Z fmt-debug=opt` flag that takes:
* `full` — the default, current state.
* `none` — makes derived `Debug` and `{:?}` no-ops. Explicit `impl Debug for T` implementations are left unharmed, but `{:?}` format won't use them, so they may get dead-code eliminated if they aren't invoked directly.
* `shallow` — makes derived `Debug` print only the type's name, without recursing into fields. Fieldless enums print their variant names. `{:?}` works.
The `shallow` option is a compromise between minimizing the `Debug` code, and compatibility. There are popular proc-macro crates that use `Debug::fmt` as a way to convert enum values into their Rust source code.
There's a corresponding `cfg` flag: `#[cfg(fmt_debug = "none")]` that can be used in user code to react to this setting to minimize custom `Debug` implementations or remove unnecessary formatting helper functions.
* Use a lookup table for 8-bit integers and the Karatsuba square root
algorithm for larger integers.
* Include optimization hints that give the compiler the exact numeric
range of results.
* Choose test inputs more thoroughly and systematically.
* Check that `isqrt` and `checked_isqrt` have equivalent results for
signed types, either equivalent numerically or equivalent as a panic
and a `None`.
* Check that `isqrt` has numerically-equivalent results for unsigned
types and their `NonZero` counterparts.
* Reuse `ilog10` benchmarks, plus benchmarks that use a uniform
distribution.
copysign with sign being a NaN can have non-portable results
Follow-up to https://github.com/rust-lang/rust/pull/129559.
Cc ```@tgross35``` ```@beetrees```
There's no portable variant we can recommend instead here, is there? Something with a semantics like "if `sign` is a NaN, then return `self` unaltered, otherwise return `self` with the sign changed to that of `sign`"?
Add fmt::Debug to sync::Weak<T, A>
Currently, `sync::Weak<T>` implements `Debug`, but `sync::Weak<T, A>` does not. This appears to be an oversight, as `rc::Weak<T, A>` implements `Debug`. (Note: `sync::Weak` is the weak for `Arc`, and `rc::Weak` is the weak for `Rc`.)
This PR adds the Debug trait for `sync::Weak<T, A>`. The issue was initially brought up here: https://github.com/rust-lang/wg-allocators/issues/131
Clean up cfg-gating of ProcessPrng extern
This removes a bit of duplication and is consistent with how `api-ms-win-core-synch-l1-2-0` externs are imported.
rustc_target: Add various aarch64 features
Add various aarch64 features already supported by LLVM and Linux.
Additionally include some comment fixes to ensure consistency of feature names with the Arm ARM.
Compiler support for features added to stdarch by https://github.com/rust-lang/stdarch/pull/1614.
Tracking issue for unstable aarch64 features is https://github.com/rust-lang/rust/issues/127764.
List of added features:
- FEAT_CSSC
- FEAT_ECV
- FEAT_FAMINMAX
- FEAT_FLAGM2
- FEAT_FP8
- FEAT_FP8DOT2
- FEAT_FP8DOT4
- FEAT_FP8FMA
- FEAT_HBC
- FEAT_LSE128
- FEAT_LSE2
- FEAT_LUT
- FEAT_MOPS
- FEAT_LRCPC3
- FEAT_SVE_B16B16
- FEAT_SVE2p1
- FEAT_WFxT
- FEAT_SME
- FEAT_SME_F16F16
- FEAT_SME_F64F64
- FEAT_SME_F8F16
- FEAT_SME_F8F32
- FEAT_SME_FA64
- FEAT_SME_I16I64
- FEAT_SME_LUTv2
- FEAT_SME2
- FEAT_SME2p1
- FEAT_SSVE_FP8DOT2
- FEAT_SSVE_FP8DOT4
- FEAT_SSVE_FP8FMA
FEAT_FPMR is added in the first commit and then removed in a separate one to highlight it being removed from upstream LLVM 19. The intention is for it to be detectable at runtime through stdarch but not have a corresponding Rust compile-time feature.
Rollup of 11 pull requests
Successful merges:
- #129421 (add repr to the allowlist for naked functions)
- #129480 (docs: correct panic conditions for rem_euclid and similar functions)
- #129551 (ub_checks intrinsics: fall back to cfg(ub_checks))
- #129608 (const-eval: do not make UbChecks behavior depend on current crate's flags)
- #129613 (interpret: do not make const-eval query result depend on tcx.sess)
- #129641 (rustdoc: fix missing resource suffix on `crates.js`)
- #129657 (Rename `BikeshedIntrinsicFrom` to `TransmuteFrom`)
- #129666 (interpret: add missing alignment check in raw_eq)
- #129667 (Rustc driver cleanup)
- #129668 (Fix Pin::set bounds regression)
- #129686 (coverage: Rename `CodeRegion` to `SourceRegion`)
r? `@ghost`
`@rustbot` modify labels: rollup
Rename `BikeshedIntrinsicFrom` to `TransmuteFrom`
As our implementation of MCP411 nears completion and we begin to solicit testing, it's no longer reasonable to expect testers to type or remember `BikeshedIntrinsicFrom`. The name degrades the ease-of-reading of documentation, and the overall experience of using compiler safe transmute.
Tentatively, we'll instead adopt `TransmuteFrom`.
This name seems to be the one most likely to be stabilized, after discussion on Zulip [1]. We may want to revisit the ordering of `Src` and `Dst` before stabilization, at which point we'd likely consider `TransmuteInto` or `Transmute`.
[1] https://rust-lang.zulipchat.com/#narrow/stream/216762-project-safe-transmute/topic/What.20should.20.60BikeshedIntrinsicFrom.60.20be.20named.3F
Tracking Issue: https://github.com/rust-lang/rust/issues/99571
r? `@compiler-errors`
ub_checks intrinsics: fall back to cfg(ub_checks)
Not sure why the fallback body uses `debug_assertions`, probably a leftover from when `cfg!(ub_checks)` did not exist yet?
r? `@saethlin`
Tweak some attributes to improve panic_immediate_abort
This is similar to https://github.com/rust-lang/rust/pull/117332; I did the same approach as before where I build a really big project with `-Zbuild-std -Zbuild-std-features=panic_immediate_abort` and grep its symbols for things that look panic-related.
A partial stabilization that only affects:
- AllocType<T>::new_uninit
- AllocType<T>::assume_init
- AllocType<[T]>::new_uninit_slice
- AllocType<[T]>::assume_init
where "AllocType" is Box, Rc, or Arc
Fix typos in floating-point primitive type docs
Fixes a few typos. Also reflows the text of a couple of paragraphs in the source code to the standard line width to make the source easier to read (will have no effect on the rendered documentation).
exit: explain our expectations for the exit handlers registered in a Rust program
This documents the position of ``@Amanieu`` and others in https://github.com/rust-lang/rust/issues/126600: a library with an atexit handler that destroys state that other threads could still be working on is buggy. We do not consider it acceptable for a library to say "you must call the following cleanup function before exiting from `main` or calling `exit`". I don't know if this is established ``@rust-lang/libs-api`` consensus so I presume this will have to go through FCP.
Given that Rust supports concurrency, I don't think there is any way to write a sound Rust wrapper around a library that has such a required cleanup function: even if we made `exit` unsafe, and the Rust wrapper used the scope-with-callback approach to ensure it can run cleanup code before returning from the wrapper (like `thread::scope`), one could still call this wrapper in a second thread and then return from `main` while the wrapper runs. Making this sound would require `std` to provide a way to "block" returning from `main`, so that while the wrapper runs returning from `main` waits until the wrapper is done... that just doesn't seem feasible.
The `exit` docs do not seem like the best place to document this, but I also couldn't think of a better one.
As our implementation of MCP411 nears completion and we begin to
solicit testing, it's no longer reasonable to expect testers to
type or remember `BikeshedIntrinsicFrom`. The name degrades the
ease-of-reading of documentation, and the overall experience of
using compiler safe transmute.
Tentatively, we'll instead adopt `TransmuteFrom`.
This name seems to be the one most likely to be stabilized, after
discussion on Zulip [1]. We may want to revisit the ordering of
`Src` and `Dst` before stabilization, at which point we'd likely
consider `TransmuteInto` or `Transmute`.
[1] https://rust-lang.zulipchat.com/#narrow/stream/216762-project-safe-transmute/topic/What.20should.20.60BikeshedIntrinsicFrom.60.20be.20named.3F
Add SME aarch64 features already supported by LLVM and Linux.
This commit adds compiler support for the following features:
- FEAT_SME
- FEAT_SME_F16F16
- FEAT_SME_F64F64
- FEAT_SME_F8F16
- FEAT_SME_F8F32
- FEAT_SME_FA64
- FEAT_SME_I16I64
- FEAT_SME_LUTv2
- FEAT_SME2
- FEAT_SME2p1
- FEAT_SSVE_FP8DOT2
- FEAT_SSVE_FP8DOT4
- FEAT_SSVE_FP8FMA
Add various aarch64 features already supported by LLVM and Linux.
The features are marked as unstable using a newly added symbol, i.e.
aarch64_unstable_target_feature.
Additionally include some comment fixes to ensure consistency of
feature names with the Arm ARM and support for architecture version
target features up to v9.5a.
This commit adds compiler support for the following features:
- FEAT_CSSC
- FEAT_ECV
- FEAT_FAMINMAX
- FEAT_FLAGM2
- FEAT_FP8
- FEAT_FP8DOT2
- FEAT_FP8DOT4
- FEAT_FP8FMA
- FEAT_FPMR
- FEAT_HBC
- FEAT_LSE128
- FEAT_LSE2
- FEAT_LUT
- FEAT_MOPS
- FEAT_LRCPC3
- FEAT_SVE_B16B16
- FEAT_SVE2p1
- FEAT_WFxT
This behaviour was introduced during the upgrade to LLVM 11. Now that the list
of source files has been cleaned up, we can reasonably expect _all_ of the
listed source files to be present.
simd_shuffle intrinsic: allow argument to be passed as vector
See https://github.com/rust-lang/rust/issues/128738 for context.
I'd like to get rid of [this hack](6c0b89dfac/compiler/rustc_codegen_ssa/src/mir/block.rs (L922-L935)). https://github.com/rust-lang/rust/pull/128537 almost lets us do that since constant SIMD vectors will then be passed as immediate arguments. However, simd_shuffle for some reason actually takes an *array* as argument, not a vector, so the hack is still required to ensure that the array becomes an immediate (which then later stages of codegen convert into a vector, as that's what LLVM needs).
This PR prepares simd_shuffle to also support a vector as the `idx` argument. Once this lands, stdarch can hopefully be updated to pass `idx` as a vector, and then support for arrays can be removed, which finally lets us get rid of that hack.
Document & implement the transmutation modeled by `BikeshedIntrinsicFrom`
Documents that `BikeshedIntrinsicFrom` models transmute-via-union, which is slightly more expressive than the transmute-via-cast implemented by `transmute_copy`. Additionally, we provide an implementation of transmute-via-union as a method on the `BikeshedIntrinsicFrom` trait with additional documentation on the boundary between trait invariants and caller obligations.
Whether or not transmute-via-union is the right kind of transmute to model remains up for discussion [1]. Regardless, it seems wise to document the present behavior.
[1] https://rust-lang.zulipchat.com/#narrow/stream/216762-project-safe-transmute/topic/What.20'kind'.20of.20transmute.20to.20model.3F/near/426331967
Tracking Issue: https://github.com/rust-lang/rust/issues/99571
r? `@compiler-errors`
cc `@scottmcm,` `@Lokathor`
Remove cfg(test) from library/core
The diff here is very small with the ignore whitespace option.
`core` doesn't/can't have unit tests. All of its tests are just modules under `tests/`, so it has no use for `cfg(test)`, because the entire contents of `library/core/src` are only ever compiled with that cfg off, and the entire contents of `library/core/tests` are only ever compiled with that cfg on.
You can tell this is what's happening because we had `#[cfg(test)]` on a module declaration that has no source file.
I also deleted the extra `mod tests {` layer of nesting; there's no need to mention again in the module path that this is a module of tests. This exposes a name collision between the `u128` module of tests and `core::u128`. Fixed that by using `<u128>::MAX` like is done in the `check!` macro, which is what avoids this name ambiguity for the other types.
link to Future::poll from the Poll docs
The most important thing about Poll is that Future::poll returns it, but previously the docs didn't emphasize this.
Add implementations for `unbounded_shl`/`unbounded_shr`
Tracking Issue: https://github.com/rust-lang/rust/issues/129375
This implements `unbounded_shl` and `unbounded_shr` under the feature gate `unbounded_shifts`
Rollup of 9 pull requests
Successful merges:
- #129288 (Use subtyping for `UnsafeFnPointer` coercion, too)
- #129405 (Fixing span manipulation and indentation of the suggestion introduced by #126187)
- #129518 (gitignore: ignore ICE reports regardless of directory)
- #129519 (Remove redundant flags from `lower_ty_common` that can be inferred from the HIR)
- #129525 (rustdoc: clean up tuple <-> primitive conversion docs)
- #129526 (Use `FxHasher` on new solver unconditionally)
- #129544 (Removes dead code from the compiler)
- #129553 (add back test for stable-const-can-only-call-stable-const)
- #129590 (Avoid taking reference of &TyKind)
r? `@ghost`
`@rustbot` modify labels: rollup
rustdoc: clean up tuple <-> primitive conversion docs
This adds a minor missing feature to `fake_variadic`, so that it can render `impl From<(T,)> for [T; 1]` correctly.
library: Move unstable API of new_uninit to new features
- `new_zeroed` variants move to `new_zeroed_alloc`
- the `write` fn moves to `box_uninit_write`
The remainder will be stabilized in upcoming patches, as it was decided to only stabilize `uninit*` and `assume_init`.
Build `library/profiler_builtins` from `ci-llvm` if appropriate
Running all of `tests/coverage` requires the LLVM profiler runtime, which requires setting `build.profiler = true`.
Historically, doing that has required checking out the entire `src/llvm-project` submodule. For compiler contributors who otherwise don't need that submodule (thanks to `download-ci-vm`), that's quite inconvenient.
However, thanks to #129116, the downloaded CI LLVM tarball now contains a copy of LLVM's `compiler-rt` directory, which includes all the files needed to build the profiler runtime. So with a little bit of extra logic in bootstrap, we can have `library/profiler_builtins` look for the `compiler-rt` files in `ci-llvm` instead of the `src/llvm-project` submodule.
Put Pin::as_deref_mut in impl Pin<Ptr> / rearrange Pin methods
Tracking issue: #86918
Based on the suggestion in https://github.com/rust-lang/rust/issues/86918#issuecomment-2189367582
> Some advantages:
>
> * Synergy with the existing `as_ref` and `as_mut` signatures (stable since Rust 1.33)
>
> * Lifetime elision reduces noise in the signature
>
> * Turbofish less verbose: `Pin::<&mut T>::as_deref_mut` vs `Pin::<&mut Pin<&mut T>>::as_deref_mut`
The comment seemed to imply that `Pin::as_ref` and `Pin::as_mut` already share an impl block, which they don't. So, I rearranged it so that they do, and we can see which looks better in the docs.
<details><summary><b>Docs screenshots</b></summary>
Current nightly:
`Pin::as_deref_mut` moved into the same block as `as_mut`:
`Pin::as_ref`, `as_mut`, and `as_deref_mut` all in the same block:
</details>
I think I like the last one the most; obviously I'm biased since I'm the one who rearranged it, but it doesn't make sense to me to have `as_ref` methods split up by an `into_inner` method.
r? dtolnay
Add a special case for `CStr`/`CString` in the `improper_ctypes` lint
Revives #120176. Just needed to bless a test and fix an argument, but seemed reasonable to me otherwise.
Instead of saying to "consider adding a `#[repr(C)]` or `#[repr(transparent)]` attribute to this struct", we now tell users to "Use `*const ffi::c_char` instead, and pass the value from `CStr::as_ptr()`" when the type involved is a `CStr` or a `CString`.
The suggestion is not made for `&mut CString` or `*mut CString`.
r? ``````@cjgillot`````` (since you were the reviewer of the original PR #120176, but feel free to reroll)
remove invalid `TyCompat` relation for effects
if the current impl uses `Maybe` (`impl const`), the parent impl must use `Maybe` (`impl const`) as well.
I'd like to rename `TyCompat` to `Sub` which is probably clearer. But it would conflict with my other PR.
r? ``@rust-lang/project-const-traits``
- `new_zeroed` variants move to `new_zeroed_alloc`
- the `write` fn moves to `box_uninit_write`
The remainder will be stabilized in upcoming patches, as
it was decided to only stabilize `uninit*` and `assume_init`.
Documents that `BikeshedIntrinsicFrom` models transmute-via-union,
which is slightly more expressive than the transmute-via-cast
implemented by `transmute_copy`. Additionally, we provide an
implementation of transmute-via-union as a method on the
`BikeshedIntrinsicFrom` trait with additional documentation on
the boundary between trait invariants and caller obligations.
Whether or not transmute-via-union is the right kind of transmute
to model remains up for discussion [1]. Regardless, it seems wise
to document the present behavior.
[1] https://rust-lang.zulipchat.com/#narrow/stream/216762-project-safe-transmute/topic/What.20'kind'.20of.20transmute.20to.20model.3F/near/426331967
Rollup of 9 pull requests
Successful merges:
- #128511 (Document WebAssembly target feature expectations)
- #129243 (do not build `cargo-miri` by default on stable channel)
- #129263 (Add a missing compatibility note in the 1.80.0 release notes)
- #129276 (Stabilize feature `char_indices_offset`)
- #129350 (adapt integer comparison tests for LLVM 20 IR changes)
- #129408 (Fix handling of macro arguments within the `dropping_copy_types` lint)
- #129426 (rustdoc-search: use tighter json for names and parents)
- #129437 (Fix typo in a help diagnostic)
- #129457 (kobzol vacation)
r? `@ghost`
`@rustbot` modify labels: rollup
Stabilize feature `char_indices_offset`
Stabilized API:
```rust
impl CharIndices<'_> {
pub fn offset(&self) -> usize;
}
```
Tracking issue: https://github.com/rust-lang/rust/issues/83871
Closes https://github.com/rust-lang/rust/issues/83871
I also attempted to improved the documentation to make it more clear that it returns the offset of the character that will be returned by the next call to `next()`.
Update `compiler_builtins` to `0.1.120`
Includes https://github.com/rust-lang/compiler-builtins/pull/672 which fixes regression issue with Apple and Windows compilers.
try-job: aarch64-apple
try-job: x86_64-apple-1
try-job: x86_64-msvc
The current `build.rs` will automatically skip source files that don't exist.
An unfortunate side-effect is that if _no_ files could be found (e.g. because
the directory was wrong), the build fails with a mysterious linker error.
We can reduce the awkwardness of this by explicitly checking that at least one
source file was found.
Rollup of 8 pull requests
Successful merges:
- #128432 (WASI: forbid `unsafe_op_in_unsafe_fn` for `std::{os, sys}`)
- #129373 (Add missing module flags for CFI and KCFI sanitizers)
- #129374 (Use `assert_unsafe_precondition!` in `AsciiChar::digit_unchecked`)
- #129376 (Change `assert_unsafe_precondition` docs to refer to `check_language_ub`)
- #129382 (Add `const_cell_into_inner` to `OnceCell`)
- #129387 (Advise against removing the remaining Python scripts from `tests/run-make`)
- #129388 (Do not rely on names to find lifetimes.)
- #129395 (Pretty-print own args of existential projections (dyn-Trait w/ GAT constraints))
r? `@ghost`
`@rustbot` modify labels: rollup
Add `const_cell_into_inner` to `OnceCell`
`Cell` and `RefCell` have their `into_inner` methods const unstable. `OnceCell` has the same logic, so add it under the same gate.
Tracking issue: https://github.com/rust-lang/rust/issues/78729
`Cell` and `RefCell` have their `into_inner` methods const unstable.
`OnceCell` has the same logic, so add it under the same gate.
Tracking issue: https://github.com/rust-lang/rust/issues/78729
Fix `thread::sleep` Duration-handling for ESP-IDF
Addresses the ESP-IDF specific aspect of https://github.com/rust-lang/rust/issues/129212
#### A short summary of the problems addressed by this PR:
================================================
1. **Problem 1** - the current implementation of `std:🧵:sleep` does not properly round up the passed `Duration`
As per the documentation of `std:🧵:sleep`, the implementation should sleep _at least_ for the provided duration, but not less. Since the minimum supported resolution of the `usleep` syscall which is used with ESP-IDF is one microsecond, this means that we need to round-up any sub-microsecond nanos to one microsecond. Moreover, in the edge case where the user had passed a duration of < 1000 nanos (i.e. less than one microsecond), the current implementation will _not_ sleep _at all_.
This is addressed by this PR.
2. **Problem 2** - the implementation of `usleep` on the ESP-IDF can overflow if the passed number of microseconds is >= `u32::MAX - 1_000_000`
This is also addressed by this PR.
Extra details for Problem 2:
`u32::MAX - 1_000_000` is chosen to accommodate for the longest possible systick on the ESP IDF which is 1000ms.
The systick duration is selected when compiling the ESP IDF FreeRTOS task scheduler itself, so we can't know it from within `STD`. The default systick duration is 10ms, and might be lowered down to 1ms. (Making it longer I have never seen, but in theory it can go up to a 1000ms max, even if obviously a one second systick is unrealistic - but we are paranoid in the PR.)
While the overflow is reported upstream in the ESP IDF repo[^1], I still believe we should workaround it in the Rust wrappers as well, because it might take time until it is fixed, and they might not fix it for all released ESP IDF versions.
For big durations, rather than calling `usleep` repeatedly on the ESP-IDF in chunks of `u32::MAX - 1_000_000`us, it might make sense to call instead with 1_000_000us (one second) as this is the max period that seems to be agreed upon as a safe max period in the `usleep` POSIX spec. On the other hand, that might introduce less precision (as we need to call more times `usleep` in a loop) and, we would be fighting a theoretical problem only, as I have big doubts the ESP IDF will stop supporting durations higher than 1_000_000us - ever - because of backwards compatibility with code which already calls `usleep` on the ESP IDF with bigger durations.
[^1]: https://github.com/espressif/esp-idf/issues/14390
Implement `debug_more_non_exhaustive`
This implements the ACP at https://github.com/rust-lang/libs-team/issues/248, adding `.finish_non_exhaustive()` for `DebugTuple`, `DebugSet`, `DebugList`, and `DebugMap`.
Also used this as an opportunity to make some documentation and tests more readable by using raw strings instead of escaped quotes.
Tracking issue: https://github.com/rust-lang/rust/issues/127942
Avoid extra `cast()`s after `CStr::as_ptr()`
These used to be `&str` literals that did need a pointer cast, but that
became a no-op after switching to `c""` literals in #118566.
Add a precondition check for Layout::from_size_align_unchecked
Ran into this while looking into https://github.com/rust-lang/miri/issues/3679. This is of course not the cause of the ICE, but the reproducer doesn't encounter a precondition check and it ought to.
