Get rid of unnecessary `BufDisplay` abstraction
r? `@GuillaumeGomez` , since you reviewed the introduction of `BufDisplay` in #136784 . Not sure when it became unnecessary, but it did :)
(feel free to reassign if you wish)
`core_float_math`: Move functions to `math` module
When these functions were added in https://github.com/rust-lang/rust/pull/138087 It made a relatively common pattern for emulating these functions using an extension trait (which internally uses `libm`) much more fragile. If `core::f32` happened to be imported by the user (to access a constant, say), then that import in the module namespace would take precedence over the `f32` in the type namespace for resolving these functions, running headfirst into the stability attribute.
We ran into this in [Color](https://github.com/linebender/color) and chose to release the remedial 0.3.1 and 0.2.4, to allow downstream crates to build on `docs.rs`.
As these methods are perma-unstable, moving them into a new module should not have any long-term concerns, and ensures that this "breakage" doesn't adversely impact anyone else.
I believe that I've made the module unstable correctly. I presume that this does not require a test to make sure stable code can't depend on the module existing?
I've left the stability attribute on each function - happy to tweak this if a different pattern is more correct.
Tracking issue for `core_float_math`: https://github.com/rust-lang/rust/issues/137578.
This PR is as requested in https://github.com/rust-lang/rust/pull/138087.
r? `@tgross35`
Recommended reviewing with whitespace hidden.
(This is my first PR to `std/core`/this repository, as far as I can remember)
Add TRACING_ENABLED to Machine and add enter_trace_span!()
This PR adds the necessary infrastructure to make it possible to do tracing calls from within `rustc_const_eval` when running Miri, while making sure they don't impact the performance of normal compiler execution. This is done by adding a `const` boolean to `Machine`, false by default, but that will be set to true in Miri only. The tracing macro `enter_trace_span!()` checks if it is true before doing anything, and since the value of a `const` is known at compile time, if it it false it the whole tracing call should be optimized out.
I will soon open further PRs to add tracing macro calls similar to this one, so that afterwards it will be possible to learn more about Miri's time spent in the various interpretation steps:
```rs
let _guard = enter_trace_span!(M, "eval_statement", "{:?}", stmt);
```
r? `@RalfJung`
This adds a `chroot` method to the `CommandExt` extension trait for the
`Command` builder, to set a directory to chroot into. This will chroot
the child process into that directory right before calling chdir for the
`Command`'s working directory.
To avoid allowing a process to have a working directory outside of the
chroot, if the `Command` does not yet have a working directory set,
`chroot` will set its working directory to "/".
Rollup of 7 pull requests
Successful merges:
- #139419 (Error on recursive opaque ty in HIR typeck)
- #141236 (Resolved issue with mismatched types triggering ICE in certain scenarios)
- #141253 (Warning added when dependency crate has async drop types, and the feature is disabled)
- #141269 (rustc-dev-guide subtree update)
- #141275 (`gather_locals`: only visit guard pattern guards when checking the guard)
- #141279 (`lower_to_hir` cleanups)
- #141285 (Add tick to `RePlaceholder` debug output)
r? `@ghost`
`@rustbot` modify labels: rollup
When these functions were added in
https://github.com/rust-lang/rust/pull/138087
It made a relatively common pattern for emulating
these functions using an extension trait (which
internally uses `libm`) much more fragile.
If `core::f32` happened to be imported by the user
(to access a constant, say), then that import in
the module namespace would take precedence over
`f32` in the type namespace for resolving these
functions, running headfirst into the stability
attribute.
We ran into this in Color -
https://github.com/linebender/color - and chose to
release the remedial 0.3.1 and 0.2.4, to allow
downstream crates to build on `docs.rs`.
As these methods are perma-unstable, moving them
into a new module should not have any long-term
concerns, and ensures that this breakage doesn't
adversely impact anyone else.
`gather_locals`: only visit guard pattern guards when checking the guard
When checking a pattern with guards in it, `GatherLocalsVisitor` will visit both the pattern (when type-checking the let, arm, or param containing it) and local declarations in the guard expression (when checking the guard itself). This keeps it from visiting the guard when visiting the pattern, since otherwise it would gather locals from the guard twice, which would lead to a delayed bug: "evaluated expression more than once".
Tracking issue for guard patterns: #129967
Warning added when dependency crate has async drop types, and the feature is disabled
In continue of https://github.com/rust-lang/rust/pull/141031.
When dependency crate has non-empty `adt_async_destructor` table in metadata, and `async_drop` feature is disabled for local crate, warning will be emitted.
Test `dependency-dropped` has two revisions - with and without feature enabled. With feature enabled, async drop for dropee is executed ("Async drop" printed). Without the feature enabled, sync drop is executed ("Sync drop" printed) and warning is emitted.
Warning example:
```
warning: found async drop types in dependecy `async_drop_dep`, but async_drop feature is disabled for `dependency_dropped`
--> $DIR/dependency-dropped.rs:7:1
|
LL | #![cfg_attr(with_feature, feature(async_drop))]
| ^
|
= help: if async drop type will be dropped in a crate without `feature(async_drop)`, sync Drop will be used
```
Resolved issue with mismatched types triggering ICE in certain scenarios
## Background
The function `annotate_mut_binding_to_immutable_binding` called in `emit_coerce_suggestions` performs a type comparison between the `expected` and `found` types from `ExpectedFound` in the `TypeError`. This can fail if the `found` type contains a region variable that's been rolled back.
## What is being changed?
This updates `annotate_mut_binding_to_immutable_binding` to use `expr_ty` and `expected` from the parent function instead of the types from the `TypeError`. This sidesteps the issue of using `found` from `TypeError` which may leak lingering inference region variables.
This does change the diagnostic behavior to _only_ support cases where the expected outermost type is `&T`, but that seems to be the intended functionality.
Also fixed the example in the `annotate_mut_binding_to_immutable_binding` rustdocs.
r? rust-lang/types
Fixes#140823
Error on recursive opaque ty in HIR typeck
"Non-trivially recursive" opaques are opaques whose hidden types are inferred to be equal to something other than themselves. For example, if we have a TAIT like `type TAIT = impl Sized`, if we infer the hidden type to be `TAIT := (TAIT,)`, that would be a non-trivial recursive definition. We don't want to support opaques that are non-trivially recursive, since they will (almost!! -- see caveat below) always result in borrowck errors, and are generally a pain to deal with.
On the contrary, trivially recursive opaques may occur today because the old solver overagerly uses `replace_opaque_types_with_inference_vars`. This infer var can then later be constrained to be equal to the opaque itself. These cases will not necessarily result in borrow-checker errors, since other uses of the opaque may properly constrain the opaque. If there are no other uses we may instead fall back to `()` today.
The only weird case that we have to unfortunately deal with was discovered in https://github.com/rust-lang/rust/issues/139406:
```rust
#![allow(unconditional_recursion)]
fn what1<T>(x: T) -> impl Sized {
what1(x)
}
fn what2<T>(x: T) -> impl Sized {
what2(what2(x))
}
fn print_return_type<T, U>(_: impl Fn(T) -> U) {
println!("{}", std::any::type_name::<U>())
}
fn main() {
print_return_type(what1::<i32>); // ()
print_return_type(what2::<i32>); // i32
}
```
> HIR typeck eagerly replaces the return type with an infer var, ending up with `RPIT<T> = RPIT<RPIT<T>>` in the storage. While we return this in the `TypeckResults`, it's never actually used anywhere.
>
> MIR building then results in the following statement
> ```rust
> let _0: impl RPIT<T> /* the return place */ = build<RPIT<T>>(_some_local);
> ```
> Unlike HIR typeck MIR typeck now directly equates `RPIT<T>` with `RPIT<RPIT<T>>`. This does not try to define `RPIT` but instead relates its generic arguments b9856b6e40/compiler/rustc_infer/src/infer/relate/type_relating.rs (L185-L190)
>
> This means we relate `T` with `RPIT<T>`, which results in a defining use `RPIT<T> = T`
I think it's pretty obvious that this is not desirable behavior, and according to the crater run there were no regressions, so let's break this so that we don't have any inference hazards in the new solver.
In the future `what2` may end up compiling again by also falling back to `()`. However, that is not yet guaranteed and the transition to this state is made significantly harder by not temporarily breaking it on the way. It is also concerning to change the inferred hidden type like this without any notification to the user, even if likely not an issue in this concrete case.
update llvm-tools logic for `dist` and `install` steps
First commit aligns `build_steps::compile` and `build_steps::dist` logics for copying llvm-tools, and the second commit adds the correct `should_run` condition for `LlvmTools` step as the previous one was clearly incorrect.
Fixes#140913
Fixesrust-lang/rust-clippy#14750 by reducing the lint span for
needless_return.
changelog: [`needless_return`]: Lint span no longer wraps to previous
line
