| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Stabilize `extended_varargs_abi_support`
I think that is everything? If there is any documentation regarding `extern` and/or varargs to correct, let me know, some quick greps suggest that there might be none.
Tracking issue: https://github.com/rust-lang/rust/issues/100189
|
|
Bump boostrap compiler to new beta
Currently failing due to something about the const stability checks and `panic!`. I'm not sure why though since I wasn't able to see any PRs merged in the past few days that would result in a `cfg(bootstrap)` that shouldn't be removed. cc `@RalfJung` #131349
|
|
The link was introduced in 0ec321f7b541fcbfbf20286beb497e6d9d3352b2.
For the old link see https://web.archive.org/web/20170409223244/https://monoinfinito.wordpress.com/series/exception-handling-in-c/.
The blog has migrated from WordPress to Blogger in 2021 and to GitHub pages in 2024.
|
|
Use consistent wording in docs, use is zero instead of is 0
In documentation, wording of _"`rhs` is zero"_ and _"`rhs` is 0"_ is intermixed. This is especially visible [here](https://doc.rust-lang.org/std/primitive.usize.html#method.div_ceil).
This changes all occurrences to _"`rhs` is zero"_ for better readability.
|
|
|
|
Enable -Zshare-generics for inline(never) functions
This avoids inlining cross-crate generic items when possible that are
already marked inline(never), implying that the author is not intending
for the function to be inlined by callers. As such, having a local copy
may make it easier for LLVM to optimize but mostly just adds to binary
bloat and codegen time. In practice our benchmarks indicate this is
indeed a win for larger compilations, where the extra cost in dynamic
linking to these symbols is diminished compared to the advantages in
fewer copies that need optimizing in each binary.
It might also make sense it expand this with other heuristics (e.g.,
`#[cold]`) in the future, but this seems like a good starting point.
FWIW, I expect that doing cleanup in where we make the decision
what should/shouldn't be shared is also a good idea. Way too
much code needed to be tweaked to check this. But I'm hoping
to leave that for a follow-up PR rather than blocking this on it.
|
|
This reduces code sizes and better respects programmer intent when
marking inline(never). Previously such a marking was essentially ignored
for generic functions, as we'd still inline them in remote crates.
|
|
|
|
Rollup of 12 pull requests
Successful merges:
- #129409 (Expand std::os::unix::fs::chown() doc with a warning)
- #133320 (Add release notes for Rust 1.83.0)
- #133368 (Delay a bug when encountering an impl with unconstrained generics in `codegen_select`)
- #133428 (Actually use placeholder regions for trait method late bound regions in `collect_return_position_impl_trait_in_trait_tys`)
- #133512 (Add `as_array` and `as_mut_array` conversion methods to slices.)
- #133519 (Check `xform_ret_ty` for WF in the new solver to improve method winnowing)
- #133520 (Structurally resolve before applying projection in borrowck)
- #133534 (extend group-forbid-always-trumps-cli test)
- #133537 ([rustdoc] Fix new clippy lints)
- #133543 ([AIX] create shim for lgammaf_r)
- #133547 (rustc_span: Replace a `HashMap<_, ()>` with `HashSet`)
- #133550 (print generated doc paths)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
[AIX] create shim for lgammaf_r
On AIX, we don't have 32bit floating point for re-entrant `lgammaf_r` but we do have the 64bit floating point re-entrant `lgamma_r` so we can use the 64bit version instead and truncate back to a 32bit float.
This solves the linker missing symbol for `.lgammaf_r` when testing and using these parts of the `std`.
|
|
Expand std::os::unix::fs::chown() doc with a warning
Include warning about losing setuid/gid when chowning, per POSIX.
It is about the underlying system call but it is rather useful to mention it in the help in case someone accidentally forgets (don't look at me :)).
|
|
Add missing code examples on `LocalKey`
r? ``@Amanieu``
|
|
|
|
|
|
|
|
|
|
|
|
std: expose `const_io_error!` as `const_error!`
ACP: https://github.com/rust-lang/libs-team/issues/205
Tracking issue: https://github.com/rust-lang/rust/issues/133448
Probably best reviewed commit-by-commit, the first one does the API change, the second does the mass-rename.
|
|
Rollup of 12 pull requests
Successful merges:
- #133042 (btree: add `{Entry,VacantEntry}::insert_entry`)
- #133070 (Lexer tweaks)
- #133136 (Support ranges in `<[T]>::get_many_mut()`)
- #133140 (Inline ExprPrecedence::order into Expr::precedence)
- #133155 (Yet more `rustc_mir_dataflow` cleanups)
- #133282 (Shorten the `MaybeUninit` `Debug` implementation)
- #133326 (Remove the `DefinitelyInitializedPlaces` analysis.)
- #133362 (No need to re-sort existential preds in relate impl)
- #133367 (Simplify array length mismatch error reporting (to not try to turn consts into target usizes))
- #133394 (Bail on more errors in dyn ty lowering)
- #133410 (target check_consistency: ensure target feature string makes some basic sense)
- #133435 (miri: disable test_downgrade_observe test on macOS)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
miri: disable test_downgrade_observe test on macOS
Due to https://github.com/rust-lang/rust/issues/121950, this test can fail on Miri. The test is also quite slow on Miri (taking more than 30s) due to the high iteration count (a total of 2000), so let's reduce that a little.
Fixes https://github.com/rust-lang/rust/issues/133421
|
|
std::thread: avoid leading whitespace in some panic messages
This:
```
panic!(
"use of std::thread::current() is not possible after the thread's
local data has been destroyed"
)
```
will print a newline followed by a bunch of spaces, since the entire string literal is interpreted literally.
I think the intention was to print the message without the newline and the spaces, so let's add some `\` to make that happen.
r? ``@joboet``
|
|
Added a doc test for std::path::strip_prefix
I was about 90% sure `Path::new("/test/haha/foo.txt").strip_prefix("/te")` would return an Err, but I couldn't find an example to confirm this behaviour.
This should be an easy merge :)
|
|
|
|
The target has limited POSIX support and provides the sysconf
function which allows querying the number of available
CPUs.
|
|
|
|
The target has support for pthreads and allows
registration of TLS destructors.
|
|
|
|
ACP: rust-lang/libs-team#205
Tracking issue: #133448
|
|
|
|
Mention that std::fs::remove_dir_all fails on files
This is explicitly mentioned for std::fs::remove_file.
It is more likely for a slightly lazy programmer to believe that removing a file would work and that they do not have to distinguish between directories (with contents) and files themself, because of the function's recursive nature and how it distinguishes between files and directories when removing them.
Follow-up for #133183.
|
|
std: allow after-main use of synchronization primitives
By creating an unnamed thread handle when the actual one has already been destroyed, synchronization primitives using thread parking can be used even outside the Rust runtime.
This also fixes an inefficiency in the queue-based `RwLock`: if `thread::current` was not initialized yet, it will create a new handle on every parking attempt without initializing `thread::current`. The private `current_or_unnamed` function introduced here fixes this.
|
|
|
|
Stabilize `const_float_methods`
Tracking issue: https://github.com/rust-lang/rust/issues/130843
Relnotes: #133383
Stabilized const API:
```rust
// in `core`
impl f32/f64 {
pub const fn recip(self) -> Self;
pub const fn to_degrees(self) -> Self;
pub const fn to_radians(self) -> Self;
pub const fn max(self, other: Self) -> Self;
pub const fn min(self, other: Self) -> Self;
pub const fn clamp(self, min: Self, max: Self) -> Self;
pub const fn abs(self) -> Self;
pub const fn signum(self) -> Self;
pub const fn copysign(self, sign: Self) -> Self;
}
```
Closes https://github.com/rust-lang/rust/issues/130843
r? libs-api
cc `@RalfJung` -- I think the way const-stability attributes work have change a bit since the last time a wrote a const-stabilization PR, please make sure I got them right.
|
|
Add `AsyncFn*` to the prelude in all editions
The general vibe is that we will most likely stabilize the `feature(async_closure)` *without* the `async Fn()` trait bound modifier.
Without `async Fn()` bound syntax, this necessitates users to spell the bound like `AsyncFn()`. Since `core::ops::AsyncFn` is not in the prelude, users will need to import these any time they actually want to use the trait. This seems annoying, so let's add these traits to the prelude unstably.
We're trying to work on the general vision of `async` trait bound modifier in general in: https://github.com/rust-lang/rfcs/pull/3710, however that RFC still needs more time for consensus to converge, and we've decided that the value that users get from calling the bound `async Fn()` is *not really* worth blocking landing async closures in general.
|
|
|
|
use `confstr(_CS_DARWIN_USER_TEMP_DIR, ...)` as a `TMPDIR` fallback on Darwin
Rebased version of https://github.com/rust-lang/rust/pull/100824, FCP has completed there. Motivation from https://github.com/rust-lang/rust/pull/100824#issuecomment-1262264127:
> This is a behavioral change in an edge case on Darwin platforms (macOS, iOS, ...).
>
> Specifically, this changes it so that iff `TMPDIR` is unset in the environment, then we use `confstr(_CS_DARWIN_USER_TEMP_DIR, ...)` to query the user temporary directory (previously we just returned `"/tmp"`). If this fails (probably possible in a sandboxed program), only then do we fallback to `"/tmp"` (as before).
>
> The motivations here are two-fold:
>
> 1. This is better for security, and is in line with the [platform security recommendations](https://developer.apple.com/library/archive/documentation/Security/Conceptual/SecureCodingGuide/Articles/RaceConditions.html#//apple_ref/doc/uid/TP40002585-SW10), as it is unavailable to other users (although it is the same value as seen by all other processes run by the same user).
> 2. This is a more consistent fallback for when `getenv("TMPDIR")` is unavailable, as `$TMPDIR` is usually initialized to the `DARWIN_USER_TEMP_DIR`.
>
> It seems quite unlikely that anybody will break because of this, and I think it falls under the carve-out we have for platform specific behavior: https://doc.rust-lang.org/nightly/std/io/index.html#platform-specific-behavior.
Closes https://github.com/rust-lang/rust/issues/99608.
Closes https://github.com/rust-lang/rust/pull/100824.
``@rustbot`` label O-apple T-libs-api
r? Dylan-DPC
|
|
implement OsString::truncate
part of #133262
|
|
|
|
Fix typo in `std::thread::Scope::spawn` documentation.
Just a simple fix for a typo that caught my attention.
|
|
library: update comment around close()
r? `@the8472`
|
|
Use arc4random of libc for RTEMS target
Switch to the `arc4random` from libc. It is available since libc 0.2.162
|
|
re-export `is_loongarch_feature_detected`
r? ``@Amanieu``
|
|
|
|
|
|
|
|
Is available since libc 0.2.162
|
|
This is explicitly mentioned for std::fs::remove_file's documentation,
but not in the aforementioned function.
It is more likely for a slightly lazy programmer to believe that
removing a file would work and that they do not have to distinguish
between directories (with contents) and files themself, because of the
function's recursive nature and how it distinguishes between files and
directories when removing them.
|
|
|
