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
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 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".
make std::intrinsics functions actually be intrinsics
Most of the functions in `std::intrinsics` are actually intrinsics, but some are not: for historical reasons, `std::intrinsics::{copy,copy_nonoverlapping,write_bytes}` are accessible on stable, and the versions in `std::ptr` are just re-exports. These functions are not intrinsics, but wrappers around the intrinsic, because they add extra debug assertions.
This PR makes the functions in `std::intrinsics` actually be intrinsics.
- The advantage is that we can now use it in tests that need to directly call the intrinsic, thus removing a footgun for compiler development. We also remove the extended user-facing doc comments of these functions out of a file that should be largely internal documentation.
- The downside is that if users are using those functions directly, they will not get the debug assertions any more. Note however that those users are already ignoring a deprecation warning, so I think this is fine. Furthermore, if someone imports the `intrinsic` name of this function and turns that into a function pointer, that will no longer work, since only the wrapper functions can be turned into a function pointer. I would be rather surprised if anyone did this, though... and again, they must have already ignored a deprecation warning. Still, seems worth a crater run, if there's general agreement that we want to go ahead with this change.
(`intrinsics::drop_in_place` also remains not-an-intrinsic, which bugs me, but oh well, not much we can do about it; we can't remove it from the module as the path is accidentally-stable.)
Cc `@rust-lang/libs-api` `@saethlin`
