| Age | Commit message (Collapse) | Author | Lines |
|---|
|
r=cuviper
fix: fix codeblocks in `PathBuf` example
This PR adds missing codeblocks around an example included in the `PathBuf` documentation.
|
|
fix: hurd build, stat64.st_fsid was renamed to st_dev
On hurd, `stat64.st_fsid` was renamed to `st_dev` in https://github.com/rust-lang/libc/pull/3785, so if you have a new libc with this patch included, and you build std from source, you get this error:
```sh
error[E0609]: no field `st_fsid` on type `&stat64`
--> /home/runner/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/os/hurd/fs.rs:301:36
|
301 | self.as_inner().as_inner().st_fsid as u64
| ^^^^^^^ unknown field
|
help: a field with a similar name exists
|
301 | self.as_inner().as_inner().st_uid as u64
| ~~~~~~
```
Full CI log: https://github.com/nix-rust/nix/actions/runs/12033180710/job/33546728266?pr=2544
|
|
std: refactor `pthread`-based synchronization
The non-trivial code for `pthread_condvar` is duplicated across the thread parking and the `Mutex`/`Condvar` implementations. This PR moves that code into `sys::pal`, which now exposes an `unsafe` wrapper type for `pthread_mutex_t` and `pthread_condvar_t`.
|
|
|
|
|
|
The function is supposed to return first argument for IMM8 == 8.
|
|
Simiarly to other functions for `mm` and `mm256` register widths, the
first argument should be a pointer to the pointer type. See e.g.
`_mm256_store_si256` function.
|
|
|
|
The first rule of the `features` macro looks like this:
```
macro_rules! features {
(
@TARGET: $target:ident;
@CFG: $cfg:meta;
@MACRO_NAME: $macro_name:ident;
@MACRO_ATTRS: $(#[$macro_attrs:meta])*
$(@BIND_FEATURE_NAME: $bind_feature:tt; $feature_impl:tt; $(#[$deprecate_attr:meta];)?)*
$(@NO_RUNTIME_DETECTION: $nort_feature:tt; )*
$(@FEATURE: #[$stability_attr:meta] $feature:ident: $feature_lit:tt;
$(without cfg check: $feature_cfg_check:literal;)?
$(implied by target_features: [$($target_feature_lit:tt),*];)?
$(#[$feature_comment:meta])*)*
) => {
```
Notice all the `tt` specifiers. They are used because they are forwarded
to another macro. Only `ident`, `lifetime`, and `tt` specifiers can be
forwarded this way.
But there is an exception: `$feature_lit:tt`, which was added recently.
In theory it should cause an error like this:
```
error: no rules expected `literal` metavariable
--> /home/njn/dev/rust3/library/stdarch/crates/std_detect/src/detect/macros.rs:54:91
|
51 | / macro_rules! $macro_name {
52 | | $(
53 | | ($feature_lit) => {
54 | | $crate::detect_feature!($feature, $feature_lit $(, without cfg check: $feature_cfg_check)? ...
| | ^^^^^^^^^^^^^^^^^^ no rules expected this token in macro call
... |
88 | | };
89 | | }
| |_________- in this expansion of `is_x86_feature_detected!`
|
::: std/tests/run-time-detect.rs:145:27
|
145 | println!("tsc: {:?}", is_x86_feature_detected!("tsc"));
| ------------------------------- in this macro invocation
|
note: while trying to match keyword `true`
--> /home/njn/dev/rust3/library/stdarch/crates/std_detect/src/detect/macros.rs:12:55
|
12 | ($feature:tt, $feature_lit:tt, without cfg check: true) => {
| ^^^^
= note: captured metavariables except for `:tt`, `:ident` and `:lifetime` cannot be compared to other tokens
= note: see <https://doc.rust-lang.org/nightly/reference/macros-by-example.html#forwarding-a-matched-fragment> for more information
```
(The URL at the end of the error has more details about this forwarding
limitation.)
In practice it doesn't cause this error. I'm not sure why, but the
existing macro implementation in rustc is far from perfect, so it's
believable that it does the wrong thing here.
Why does this matter? Because https://github.com/rust-lang/rust/pull/124141
is modifying the macro implementation, and when that PR is applied the
error *does* occur. (It's one of several cases I have found where the
existing compiler accepts code it shouldn't, but #124141 causes that
code to be rejected.)
Fortunately the fix is simple: replace the `literal` specifier with `tt`.
|
|
Rollup of 6 pull requests
Successful merges:
- #131698 (use stores of the correct size to set discriminants)
- #133571 (Mark visionOS as supporting `std`)
- #133655 (Eliminate print_expr_maybe_paren function from pretty printers)
- #133667 (Remove unused code)
- #133670 (bump hashbrown version)
- #133673 (replace hard coded error id with `ErrorKind::DirectoryNotEmpty`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
This will be used in Clippy to detect useless conversions done through
`ControlFlow::map_break()` and `ControlFlow::map_continue()`.
|
|
bump hashbrown version
This pulls in https://github.com/rust-lang/hashbrown/pull/586, in preparation for https://github.com/rust-lang/rust/issues/102575.
Cc ``@Amanieu``
|
|
Rollup of 6 pull requests
Successful merges:
- #131551 (Support input/output in vector registers of PowerPC inline assembly)
- #132515 (Fix and undeprecate home_dir())
- #132721 (CI: split x86_64-mingw job)
- #133106 (changes old intrinsic declaration to new declaration)
- #133496 (thread::available_parallelism for wasm32-wasip1-threads)
- #133548 (Add `BTreeSet` entry APIs to match `HashSet`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Something about the MIR lowering for `||` ended up breaking this, but it's fixed by changing the code to use `|` instead.
I also added an assembly test to ensure it *keeps* being `adc`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add `BTreeSet` entry APIs to match `HashSet`
The following methods are added, along with the corresponding `Entry` implementation.
```rust
impl<T, A: Allocator + Clone> BTreeSet<T, A> {
pub fn get_or_insert(&mut self, value: T) -> &T
where
T: Ord,
{...}
pub fn get_or_insert_with<Q: ?Sized, F>(&mut self, value: &Q, f: F) -> &T
where
T: Borrow<Q> + Ord,
Q: Ord,
F: FnOnce(&Q) -> T,
{...}
pub fn entry(&mut self, value: T) -> Entry<'_, T, A>
where
T: Ord,
{...}
}
```
Tracking issue #133549
Closes https://github.com/rust-lang/rfcs/issues/1490
|
|
thread::available_parallelism for wasm32-wasip1-threads
The target has limited POSIX support and provides the `libc::sysconf` function which allows querying the number of available CPUs.
|
|
changes old intrinsic declaration to new declaration
This pr is for issue #132735
It changes old `extern "intrinsic"` code block with new declaration.
There are other blocks that use old declaration but as the changes needed in single block is quite large I do them in parts
|
|
Fix and undeprecate home_dir()
`home_dir()` has been deprecated for 6 years due to using `HOME` env var on Windows.
It's been a long time, and having a perpetually buggy and deprecated function in the standard library is not useful. I propose fixing and undeprecating it.
6 years seems more than long enough to warn users against relying on this function. The change in behavior is minor, and it's more of a bug fix than breakage. The old behavior is unlikely to be useful, and even if anybody actually needed to specifically use the non-standard `HOME` on Windows, they can trivially mitigate this change by reading the env var themselves.
----
Use of `USERPROFILE` is in line with the `home` crate: https://github.com/rust-lang/cargo/blob/37bc5f0232a0bb72dedd2c14149614fd8cdae649/crates/home/src/windows.rs#L12
The `home` crate uses `SHGetKnownFolderPath` instead of `GetUserProfileDirectoryW`. AFAIK it doesn't make any difference in practice, because `SHGetKnownFolderPath` merely adds support for more kinds of folders, including virtual (non-filesystem) folders identified by a GUID, but the specific case of [`FOLDERID_Profile`](https://learn.microsoft.com/en-us/windows/win32/shell/knownfolderid#FOLDERID_Profile) is documented as a FIXED folder (a regular filesystem path). Just in case, I've added a note to documentation that the use of `GetUserProfileDirectoryW` can change.
I've used `CURRENT_RUSTC_VERSION` in a doccomment. `replace-version-placeholder` tool seems to perform a simple string replacement, so hopefully it'll get updated.
|
|
custom MIR: add doc comment for debuginfo
This is a revival of https://github.com/rust-lang/rust/pull/117015
|
|
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
|
|
|
|
and add a test for the constant case
|
|
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.
|
|
Fix typos in pin.rs
|
|
|
|
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.
|
|
That is, differentiate between out-of-bounds and overlapping indices, and remove the generic parameter `N`.
I also exported `GetManyMutError` from `alloc` (and `std`), which was apparently forgotten.
Changing the error to carry additional details means LLVM no longer generates separate short-circuiting branches for the checks, instead it generates one branch at the end. I therefore changed the code to use early returns to make LLVM generate jumps. Benchmark results between the approaches are somewhat mixed, but I chose this approach because it is significantly faster with ranges and also faster with `unwrap()`.
|
|
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.
|
|
|
|
|
|
|
|
|
