-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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 10 pull requests #120335
Rollup of 10 pull requests #120335
Conversation
When an associated type `Self::Assoc` is part of a `where` clause, we end up unable to evaluate the requirement and emit a E0275. We now point at the associated type if specified in the `impl`. If so, we also suggest using that type instead of `Self::Assoc`. Otherwise, we explain that these are not allowed. ``` error[E0275]: overflow evaluating the requirement `<(T,) as Grault>::A == _` --> $DIR/impl-wf-cycle-1.rs:15:1 | LL | / impl<T: Grault> Grault for (T,) LL | | LL | | where LL | | Self::A: Baz, LL | | Self::B: Fiz, | |_________________^ LL | { LL | type A = (); | ------ associated type `<(T,) as Grault>::A` is specified here | note: required for `(T,)` to implement `Grault` --> $DIR/impl-wf-cycle-1.rs:15:17 | LL | impl<T: Grault> Grault for (T,) | ^^^^^^ ^^^^ ... LL | Self::A: Baz, | --- unsatisfied trait bound introduced here = note: 1 redundant requirement hidden = note: required for `(T,)` to implement `Grault` help: associated type for the current `impl` cannot be restricted in `where` clauses, remove this bound | LL - Self::A: Baz, LL + , | ``` ``` error[E0275]: overflow evaluating the requirement `<T as B>::Type == <T as B>::Type` --> $DIR/impl-wf-cycle-3.rs:7:1 | LL | / impl<T> B for T LL | | where LL | | T: A<Self::Type>, | |_____________________^ LL | { LL | type Type = bool; | --------- associated type `<T as B>::Type` is specified here | note: required for `T` to implement `B` --> $DIR/impl-wf-cycle-3.rs:7:9 | LL | impl<T> B for T | ^ ^ LL | where LL | T: A<Self::Type>, | ------------- unsatisfied trait bound introduced here help: replace the associated type with the type specified in this `impl` | LL | T: A<bool>, | ~~~~ ``` ``` error[E0275]: overflow evaluating the requirement `<T as Filter>::ToMatch == <T as Filter>::ToMatch` --> $DIR/impl-wf-cycle-4.rs:5:1 | LL | / impl<T> Filter for T LL | | where LL | | T: Fn(Self::ToMatch), | |_________________________^ | note: required for `T` to implement `Filter` --> $DIR/impl-wf-cycle-4.rs:5:9 | LL | impl<T> Filter for T | ^^^^^^ ^ LL | where LL | T: Fn(Self::ToMatch), | ----------------- unsatisfied trait bound introduced here note: associated types for the current `impl` cannot be restricted in `where` clauses --> $DIR/impl-wf-cycle-4.rs:7:11 | LL | T: Fn(Self::ToMatch), | ^^^^^^^^^^^^^ ``` Fix rust-lang#116925
These were added with good intentions, but a recent change in LLVM 18 emits a warning while examining .rmeta sections in .rlib files. Since this flag is a nice-to-have and users can update their LLVM linker independently of rustc's LLVM version, we can just omit the flag.
Consolidating this code into flatter functions reduces the amount of pointer-chasing required to read and modify it.
Since we always clone and allocate the types somewhere else ourselves, no need to ask for `Cx` to do the allocation.
When encountering a type mismatch error involving `dyn Trait`, mention the existence of boxed trait objects if the other type involved implements `Trait`. Partially addresses rust-lang#102629.
…=oli-obk Add `AsyncFn` family of traits I'm proposing to add a new family of `async`hronous `Fn`-like traits to the standard library for experimentation purposes. ## Why do we need new traits? On the user side, it is useful to be able to express `AsyncFn` trait bounds natively via the parenthesized sugar syntax, i.e. `x: impl AsyncFn(&str) -> String` when experimenting with async-closure code. This also does not preclude `AsyncFn` becoming something else like a trait alias if a more fundamental desugaring (which can take many[^1] different[^2] forms) comes around. I think we should be able to play around with `AsyncFn` well before that, though. I'm also not proposing stabilization of these trait names any time soon (we may even want to instead express them via new syntax, like `async Fn() -> ..`), but I also don't think we need to introduce an obtuse bikeshedding name, since `AsyncFn` just makes sense. ## The lending problem: why not add a more fundamental primitive of `LendingFn`/`LendingFnMut`? Firstly, for `async` closures to be as flexible as possible, they must be allowed to return futures which borrow from the async closure's captures. This can be done by introducing `LendingFn`/`LendingFnMut` traits, or (equivalently) by adding a new generic associated type to `FnMut` which allows the return type to capture lifetimes from the `&mut self` argument of the trait. This was proposed in one of [Niko's blog posts](https://smallcultfollowing.com/babysteps/blog/2023/05/09/giving-lending-and-async-closures/). Upon further experimentation, for the purposes of closure type- and borrow-checking, I've come to the conclusion that it's significantly harder to teach the compiler how to handle *general* lending closures which may borrow from their captures. This is, because unlike `Fn`/`FnMut`, the `LendingFn`/`LendingFnMut` traits don't form a simple "inheritance" hierarchy whose top trait is `FnOnce`. ```mermaid flowchart LR Fn FnMut FnOnce LendingFn LendingFnMut Fn -- isa --> FnMut FnMut -- isa --> FnOnce LendingFn -- isa --> LendingFnMut Fn -- isa --> LendingFn FnMut -- isa --> LendingFnMut ``` For example: ``` fn main() { let s = String::from("hello, world"); let f = move || &s; let x = f(); // This borrows `f` for some lifetime `'1` and returns `&'1 String`. ``` That trait hierarchy means that in general for "lending" closures, like `f` above, there's not really a meaningful return type for `<typeof(f) as FnOnce>::Output` -- it can't return `&'static str`, for example. ### Special-casing this problem: By splitting out these traits manually, and making sure that each trait has its own associated future type, we side-step the issue of having to answer the questions of a general `LendingFn`/`LendingFnMut` implementation, since the compiler knows how to generate built-in implementations for first-class constructs like async closures, including the required future types for the (by-move) `AsyncFnOnce` and (by-ref) `AsyncFnMut`/`AsyncFn` trait implementations. [^1]: For example, with trait transformers, we may eventually be able to write: `trait AsyncFn = async Fn;` [^2]: For example, via the introduction of a more fundamental "`LendingFn`" trait, plus a [special desugaring with augmented trait aliases](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Lending.20closures.20and.20Fn*.28.29.20-.3E.20impl.20Trait/near/408471480).
Provide more context on recursive `impl` evaluation overflow When an associated type `Self::Assoc` is part of a `where` clause, we end up unable to evaluate the requirement and emit a E0275. We now point at the associated type if specified in the `impl`. If so, we also suggest using that type instead of `Self::Assoc`. Otherwise, we explain that these are not allowed. ``` error[E0275]: overflow evaluating the requirement `<(T,) as Grault>::A == _` --> $DIR/impl-wf-cycle-1.rs:15:1 | LL | / impl<T: Grault> Grault for (T,) LL | | LL | | where LL | | Self::A: Baz, LL | | Self::B: Fiz, | |_________________^ LL | { LL | type A = (); | ------ associated type `<(T,) as Grault>::A` is specified here | note: required for `(T,)` to implement `Grault` --> $DIR/impl-wf-cycle-1.rs:15:17 | LL | impl<T: Grault> Grault for (T,) | ^^^^^^ ^^^^ ... LL | Self::A: Baz, | --- unsatisfied trait bound introduced here = note: 1 redundant requirement hidden = note: required for `(T,)` to implement `Grault` help: associated type for the current `impl` cannot be restricted in `where` clauses, remove this bound | LL - Self::A: Baz, | ``` ``` error[E0275]: overflow evaluating the requirement `<T as B>::Type == <T as B>::Type` --> $DIR/impl-wf-cycle-3.rs:7:1 | LL | / impl<T> B for T LL | | where LL | | T: A<Self::Type>, | |_____________________^ LL | { LL | type Type = bool; | --------- associated type `<T as B>::Type` is specified here | note: required for `T` to implement `B` --> $DIR/impl-wf-cycle-3.rs:7:9 | LL | impl<T> B for T | ^ ^ LL | where LL | T: A<Self::Type>, | ------------- unsatisfied trait bound introduced here help: replace the associated type with the type specified in this `impl` | LL | T: A<bool>, | ~~~~ ``` ``` error[E0275]: overflow evaluating the requirement `<T as Filter>::ToMatch == <T as Filter>::ToMatch` --> $DIR/impl-wf-cycle-4.rs:5:1 | LL | / impl<T> Filter for T LL | | where LL | | T: Fn(Self::ToMatch), | |_________________________^ | note: required for `T` to implement `Filter` --> $DIR/impl-wf-cycle-4.rs:5:9 | LL | impl<T> Filter for T | ^^^^^^ ^ LL | where LL | T: Fn(Self::ToMatch), | ----------------- unsatisfied trait bound introduced here note: associated types for the current `impl` cannot be restricted in `where` clauses --> $DIR/impl-wf-cycle-4.rs:7:11 | LL | T: Fn(Self::ToMatch), | ^^^^^^^^^^^^^ ``` Fix rust-lang#116925
…asper Remove `track_errors` entirely follow up to rust-lang#119869 r? `@matthewjasper` There are some diagnostic changes adding new diagnostics or not emitting some anymore. We can improve upon that in follow-up work imo.
…chaelwoerister Assert that a single scope is passed to `for_scope` Addresses rust-lang#118518 (comment) r? ``@michaelwoerister``
…sm, r=oli-obk Remove --fatal-warnings on wasm targets These were added with good intentions, but a recent change in LLVM 18 emits a warning while examining .rmeta sections in .rlib files. Since this flag is a nice-to-have and users can update their LLVM linker independently of rustc's LLVM version, we can just omit the flag. See [this comment on wasm targets' uses of `--fatal-warnings`](llvm/llvm-project#78658 (comment)).
coverage: Dismantle `Instrumentor` and flatten span refinement This is a combination of two refactorings that are unrelated, but would otherwise have a merge conflict. No functional changes, other than a small tweak to debug logging as part of rearranging some functions. Ignoring whitespace is highly recommended, since most of the modified lines have just been reindented. --- The first change is to dismantle `Instrumentor` into ordinary functions. This is one of those cases where encapsulating several values into a struct ultimately hurts more than it helps. With everything stored as local variables in one main function, and passed explicitly into helper functions, it's easier to see what is used where, and make changes as necessary. --- The second change is to flatten the functions for extracting/refining coverage spans. Consolidating this code into flatter functions reduces the amount of pointer-chasing required to read and modify it.
…iser On E0308 involving `dyn Trait`, mention trait objects When encountering a type mismatch error involving `dyn Trait`, mention the existence of boxed trait objects if the other type involved implements `Trait`. Fix rust-lang#102629.
…r=compiler-errors pattern_analysis: Let `ctor_sub_tys` return any Iterator they want I noticed that we always `.cloned()` and allocate the output of `TypeCx::ctor_sub_tys` now, so there was no need to force it to return a slice. `ExactSizeIterator` is not super important but saves some manual counting. r? `@compiler-errors`
…iler-errors pattern_analysis: Reuse most of the `DeconstructedPat` `Debug` impl The `DeconstructedPat: Debug` is best-effort because we'd need `tcx` to get things like field names etc. Since rust-analyzer has a similar constraint, this PR moves most the impl to be shared between the two. While I was at it I also fixed a nit in the `IntRange: Debug` impl. r? `@compiler-errors`
…rors rustc_data_structures: use either instead of itertools `itertools::Either` is a re-export from `either`, so we might as well use the source. This flattens the compiler build tree a little, but I don't really expect it to make much difference overall.
@bors r+ rollup=never p=10 |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: d93feccb35 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (5bd5d21): comparison URL. Overall result: ❌✅ regressions and improvements - ACTION NEEDEDNext Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Bootstrap: 662.638s -> 664.45s (0.27%) |
Looks like @rust-timer build 271a91e (Testing #119389). |
This comment has been minimized.
This comment has been minimized.
This comment was marked as outdated.
This comment was marked as outdated.
@rust-timer build b59ed7b |
This comment has been minimized.
This comment has been minimized.
This comment was marked as outdated.
This comment was marked as outdated.
@rust-timer build 662b32b |
This comment has been minimized.
This comment has been minimized.
This comment was marked as outdated.
This comment was marked as outdated.
@rust-timer build 63f0a7a |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (63f0a7a): comparison URL. Overall result: ❌✅ regressions and improvements - ACTION NEEDEDInstruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Bootstrap: 662.638s -> 662.122s (-0.08%) |
Looks like #119305 is the source of the |
Successful merges:
AsyncFn
family of traits #119305 (AddAsyncFn
family of traits)impl
evaluation overflow #119389 (Provide more context on recursiveimpl
evaluation overflow)track_errors
entirely #119895 (Removetrack_errors
entirely)for_scope
#120230 (Assert that a single scope is passed tofor_scope
)Instrumentor
and flatten span refinement #120292 (coverage: DismantleInstrumentor
and flatten span refinement)dyn Trait
, mention trait objects #120315 (On E0308 involvingdyn Trait
, mention trait objects)ctor_sub_tys
return any Iterator they want #120317 (pattern_analysis: Letctor_sub_tys
return any Iterator they want)DeconstructedPat
Debug
impl #120318 (pattern_analysis: Reuse most of theDeconstructedPat
Debug
impl)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup