-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Rollup of 7 pull requests #141292
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 7 pull requests #141292
Conversation
Exclude issues with an associated PR from the "What should I work on" GH query
Fix typos in "Libraries and Metadata"
Better, because then one knows how to run the examples.
Remove unused references and simplify one
Make run instructions first
…s disabled - typo fixed
Rustc pull update
They are all short and have a single call site.
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".
…que type values" This reverts commit b08e9c2.
…r=lcnr 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 rust-lang#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 https://github.com/rust-lang/rust/blob/b9856b6e400709392dd14599265b6fd52fc19f3e/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.
…errors 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 rust-lang#140823
…-inconsistency-warning, r=oli-obk Warning added when dependency crate has async drop types, and the feature is disabled In continue of rust-lang#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 ```
rustc-dev-guide subtree update r? `@ghost`
…e, r=compiler-errors `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: rust-lang#129967
…er-errors `lower_to_hir` cleanups Some minor cleanups I made when reading this code. r? `@Nadrieril`
Add tick to `RePlaceholder` debug output Present when debug printing canonical queries r? lcnr
@bors r+ rollup=never p=5 |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: 6cab15c1ae In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing 6cab15c (parent) -> 444a627 (this PR) Test differencesShow 10 test diffsStage 1
Stage 2
Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard 444a62712a29e14d3b6147b51fd24e623496bf58 --output-dir test-dashboard And then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
Successful merges:
gather_locals
: only visit guard pattern guards when checking the guard #141275 (gather_locals
: only visit guard pattern guards when checking the guard)lower_to_hir
cleanups #141279 (lower_to_hir
cleanups)RePlaceholder
debug output #141285 (Add tick toRePlaceholder
debug output)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup