Rollup of 5 pull requests
Successful merges:
- #131416 (Mark `slice::copy_from_slice` unstably const)
- #131784 (Stabilize unsigned and float variants of `num_midpoint` feature)
- #133446 (coverage: Use a query to identify which counter/expression IDs are used)
- #133711 (add isatty doc alias for `is_terminal`)
- #133712 (rust_analyzer_settings: force use of 'nightly' toolchain)
r? `@ghost`
`@rustbot` modify labels: rollup
rust_analyzer_settings: force use of 'nightly' toolchain
The cranelift folder contains a rust-toolchain file. That means when RA opens `compiler/rustc_codegen_cranelift/Cargo.toml`, it will try to use that toolchain or fail. (Maybe that toolchain gets auto-installed for others? On my system, it just fails, but I also run vscodium in a sandbox.)
However, it shouldn't be necessary to use more than one toolchain for the rustc workspace. So we can set the `RUSTUP_TOOLCHAIN` variable on the server side to force the same toolchain to be used everywhere.
Suggested by `@ChayimFriedman2` in https://github.com/rust-lang/rust-analyzer/issues/18585.
add isatty doc alias for `is_terminal`
(first Rust contribution!)
This adds `isatty` as a doc alias for [`std::io::IsTerminal::is_terminal`](https://doc.rust-lang.org/stable/std/io/trait.IsTerminal.html#tymethod.is_terminal).
I think this change does meet the [doc alias policy](https://std-dev-guide.rust-lang.org/policy/doc-alias.html). This would be especially useful because searching "rust isatty" gets you the `isatty` crate which is deprecated in favor of `atty`. `atty` is unmaintained and you might get to `is-terminal`, which will finally tell you that the function you're looking for has been in `std` all along.
The Windows implementation of `is_terminal()` doesn't use `isatty`, but that hasn't been a problem for the analogous cases of `create_dir()`'s alias `mkdir` or `remove_dir()`/`rmdir`.
coverage: Use a query to identify which counter/expression IDs are used
Given that we already have a query to identify the highest-numbered counter ID in a MIR body, we can extend that query to also build bitsets of used counter/expression IDs. That lets us avoid some messy coverage bookkeeping during the main MIR traversal for codegen.
This does mean that we fail to treat some IDs as used in certain MIR-inlining scenarios, but I think that's fine, because it means that the results will be consistent across all instantiations of a function.
---
There's some more cleanup I want to do in the function coverage collector, since it isn't really collecting anything any more, but I'll leave that for future work.
Stabilize unsigned and float variants of `num_midpoint` feature
This PR proposes that we stabilize the unsigned variants of the [`num_midpoint`](https://github.com/rust-lang/rust/issues/110840#issue-1684506201) feature as well as the floats variants, since they are not subject to any unresolved questions, which is equivalent to doing `(a + b) / 2` (and `(a + b) >> 1`) in a sufficiently large number.
The stabilized API surface would be:
```rust
/// Calculates the middle point of `self` and `rhs`.
///
/// `midpoint(a, b)` is `(a + b) / 2` as if it were performed in a sufficiently-large unsigned integral type.
/// This implies that the result is always rounded towards negative infinity and that no overflow will ever occur.
impl u{8,16,32,64,128,size} {
pub const fn midpoint(self, rhs: Self) -> Self;
}
impl NonZeroU{8,16,32,64,size} {
pub const fn midpoint(self, rhs: Self) -> Self;
}
impl f{32,64} {
pub const fn midpoint(self, rhs: Self) -> Self;
}
```
The signed variants `u{8,16,32,64,128,size}` would remain gated, until a decision is made about the rounding mode, in other words that the [unresolved questions](https://github.com/rust-lang/rust/issues/110840#issue-1684506201) are resolved.
cc `@rust-lang/libs-api`
cc `@scottmcm`
r? libs-api
Mark `slice::copy_from_slice` unstably const
Tracking issue #131415
I used `const_eval_select` for runtime and const panic functions because const formatting isn't available yet.
Stop cloning `Context` so much
This is a first step for https://github.com/rust-lang/rust/issues/82381.
It's already big enough so I'll continue in a follow-up once this PR is merged. Next step will be to get rid of `SharedContext` by inlining it directly into `Context`.
cc `@camelid`
r? `@notriddle`
Rollup of 7 pull requests
Successful merges:
- #132974 (Properly pass linker arguments that contain commas)
- #133403 (Make `adjust_fulfillment_errors` work with `HostEffectPredicate` and `const_conditions`)
- #133482 (Only error raw lifetime followed by `\'` in edition 2021+)
- #133595 (Do not emit `missing_doc_code_examples` rustdoc lint on module and a few other items)
- #133669 (Move some functions out of const_swap feature gate)
- #133674 (Fix chaining `carrying_add`s)
- #133691 (Check let source before suggesting annotation)
r? `@ghost`
`@rustbot` modify labels: rollup
Do not emit `missing_doc_code_examples` rustdoc lint on module and a few other items
It doesn't make sense to expect modules to have code examples. Same goes for:
* Trait aliases
* Foreign items
* Associated types and constants
Should make the use of this lint a bit nicer.
r? ``@notriddle``
Only error raw lifetime followed by `\'` in edition 2021+
Fixes#133479
cc #132341
I think this fixes a purely theoretical regression since it only affects edition 2015 (who is using that?) and only in the very rare case of a raw lifetime followed immediately by a lifetime like `'r#a'r`.
Make `adjust_fulfillment_errors` work with `HostEffectPredicate` and `const_conditions`
Greatly improves the spans for reporting unsatisfied `~const` bounds :)
r? project-const-traits or maybe ``@lcnr`` (if you want to deal with a diagnostics PR lmao)
Properly pass linker arguments that contain commas
When linking with the system C compiler, we sometimes want to forward certain arguments unchanged to the linker. This can be done with `-Wl,arg1,arg2` or `-Xlinker arg1 -Xlinker arg2`. `-Wl` is used when possible, since it is more compact, but it does not support commas in the argument itself - in those cases, we need to use `-Xlinker`, and that is what this PR implements.
This also fixes using sanitizers on macOS with `-Clinker-flavor=ld`, as those were previously manually using `-Wl`/`-Xlinker` (probably since the support wasn't present in the `link_args` function).
Note that there has been [a previous PR for this](https://github.com/rust-lang/rust/pull/38798), but it only implemented this in certain cases when passing `-rpath`.
r? compiler
Rollup of 8 pull requests
Successful merges:
- #128184 (std: refactor `pthread`-based synchronization)
- #132047 (Robustify and genericize return-type-notation resolution in `resolve_bound_vars`)
- #133515 (fix: hurd build, stat64.st_fsid was renamed to st_dev)
- #133602 (fix: fix codeblocks in `PathBuf` example)
- #133622 (update link to "C++ Exceptions under the hood" blog)
- #133660 (Do not create trait object type if missing associated types)
- #133686 (Add diagnostic item for `std::ops::ControlFlow`)
- #133689 (Fixed typos by changing `happend` to `happened`)
r? `@ghost`
`@rustbot` modify labels: rollup
Add diagnostic item for `std::ops::ControlFlow`
This will be used in Clippy to detect useless conversions done through `ControlFlow::map_break()` and `ControlFlow::map_continue()`.
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
Robustify and genericize return-type-notation resolution in `resolve_bound_vars`
#129629 implemented return-type-notation (RTN) in its path form, like `where T::method(..): Bound`. As part of lowering, we must record the late-bound vars for the where clause introduced by the method (namely, its early- and late-bound lifetime arguments, since `where T::method(..)` turns into a higher-ranked where clause over all of the lifetimes according to [RFC 3654](https://rust-lang.github.io/rfcs/3654-return-type-notation.html#converting-to-higher-ranked-trait-bounds)).
However, this logic was only looking at the where clauses of the parent item that the `T::method(..)` bound was written on, and not any parent items. This PR generalizes that logic to look at the parent item (i.e. the outer impl or trait) instead and fixes a (debug only) assertion as an effect.
This logic is also more general and likely easier to adapt to more interesting (though likely very far off) cases like non-lifetime binder `for<T: Trait> T::method(..): Send` bounds.
Tracking:
- https://github.com/rust-lang/rust/issues/109417
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`.
Respect verify-llvm-ir option in the backend
We are currently unconditionally verifying the LLVM IR in the backend (twice), ignoring the value of the verify-llvm-ir option. This has substantial compile-time impact for debug builds.
Make `compare_impl_item` into a query
Turns `compare_impl_item` into a query (generalizing the existing query for `compare_impl_const`), and uses that in `Instance::resolve` to fail resolution when an implementation is incompatible with the trait it comes from.
Fixes#119701Fixes#121127Fixes#121411Fixes#129075Fixes#129127Fixes#129214Fixes#131294
