Prototype Fixing false E0581/E0582 errors in the next solver

[enginespot]

I’m addressing a class of E0581/E0582 errors under -Znext-solver=globally: rustc rejects a callable signature even though its input types and existing constraints determine its output. This affects both Fn bounds and function pointer types.

I’ll start with a callback that returns the same associated type it receives, then show how equalities and nested declarations support more involved signatures and actual calls. The later examples explain which restrictions still apply. Code snippets reuse earlier definitions; examples described as errors should be compiled separately.

Using the same associated type for input and output

The following apply passes value to a callback and returns the result. Both sides use T::View, but the previous check rejected the callable bound.

trait Family {
    type View<'a>;
}

fn apply<'a, T: Family, F>(f: F, value: T::View<'a>) -> T::View<'a>
where
    F: for<'b> Fn(T::View<'b>) -> T::View<'b>,
{
    f(value)
}

Why this was rejected

View<'a> does not necessarily use 'a. These two implementations illustrate the distinction:

struct Borrowed;

impl Family for Borrowed {
    type View<'a> = &'a u32;
}

struct Erased;

impl Family for Erased {
    type View<'a> = ();
}

Substituting each implementation into the callback bound gives:

T = Borrowed: for<'a> Fn(&'a u32) -> &'a u32
T = Erased:   Fn(()) -> ()

For Borrowed, the input is a reference whose type retains 'a. For Erased, the input is always (), regardless of how 'a is instantiated. A generic input written as T::View<'a> therefore does not establish that 'a can be recovered from that type.

In both cases, the complete input type still determines the output type. For Borrowed, both are &'a u32; for Erased, both are (). In the latter case, the output no longer depends on 'a either, so there is no need to recover it.

What the change allows

I changed the check to recognize complete input types reused in the output. In apply, both sides are T::View<'b>, so determining the output does not require recovering 'b from the projection. The generic definition now passes the check, and both calls below are accepted:

fn use_apply() {
    let value = 42;

    let borrowed = apply::<Borrowed, _>(|x| x, &value);
    assert_eq!(*borrowed, 42);

    let erased = apply::<Erased, _>(|x| x, ());
    assert_eq!(erased, ());
}

The call to f(value) inside apply is checked using the same type relationship. These examples exercise that call with both a reference and ().

Using an equality between different associated types

The input and output may use different projections. In this example, the callback takes T::View and returns U::View, while a separate where clause requires the two types to be equal for every 'b:

fn apply_equivalent<'a, T, U, F>(f: F, value: T::View<'a>) -> U::View<'a>
where
    U: Family,
    for<'b> T: Family<View<'b> = U::View<'b>>,
    F: for<'b> Fn(T::View<'b>) -> U::View<'b>,
{
    f(value)
}

I use the independent T: Family<View<'b> = U::View<'b>> bound to establish the equality when checking the callable bound. The Fn(...) -> ... binding being checked cannot serve as proof of its own validity.

When normalizing the input and output, both occurrences of 'b remain bound by the same quantifier. Any additional requirements introduced by normalization must also hold.

For a concrete call, another type can define View as the same reference type:

struct AlsoBorrowed;

impl Family for AlsoBorrowed {
    type View<'a> = &'a u32;
}

fn use_equivalent() {
    let value = 42;
    let result = apply_equivalent::<Borrowed, AlsoBorrowed, _>(|x| x, &value);
    assert_eq!(*result, 42);
}

Inside the generic function, the equality comes from the View<'b> = U::View<'b> bound. At this call site, both projections are &u32. Replacing AlsoBorrowed with Erased would give &u32 on one side and () on the other, so the equality would fail and the call would still be rejected.

Wrapping the result

The output can also contain the reused type inside a wrapper such as Option:

fn wrap_equivalent<'a, T, U, F>(mut f: F, value: T::View<'a>) -> Option<U::View<'a>>
where
    U: Family,
    for<'b> T: Family<View<'b> = U::View<'b>>,
    F: for<'b> FnMut(T::View<'b>) -> Option<U::View<'b>>,
{
    f(value)
}

fn use_wrapped() {
    let value = 42;
    let result = wrap_equivalent::<Borrowed, AlsoBorrowed, _>(|x| Some(x), &value);
    assert_eq!(result, Some(&value));
}

The equality determines U::View<'b>, which also determines Option<U::View<'b>>. The check can recognize a reused type within the output; it does not require the entire output to be identical to the entire input. Any additional references in the output still need their lifetimes checked separately.

Following equalities through associated type declarations

A function’s where clause may provide an equality indirectly through a declaration. Here, the relevant equality appears in the declaration of Carrier::Assoc:

trait Identity {
    type Output: Family;
}

trait Carrier {
    type Assoc: Identity<Output = Self::Assoc>;
}

fn identity<'a, C: Carrier<Assoc = T>, T: Family>(
    value: T::View<'a>,
) -> <<T as Identity>::Output as Family>::View<'a> {
    value
}

Substituting the declared relationships reduces the return type to the input type:

The function requires: C::Assoc = T
Carrier requires:      C::Assoc: Identity<Output = C::Assoc>
Substituting T:         T: Identity<Output = T>

Return type:           <<T as Identity>::Output as Family>::View<'a>
Substituting Output:   <T as Family>::View<'a>
The input type:        T::View<'a>

The previous implementation did not fully use this relationship. I extended the solver to follow associated item and supertrait declarations for the current goal. Here, that establishes <T as Identity>::Output = T, allowing the body to return value directly.

The search follows the relationship needed for that goal. If a declaration carries additional where clauses, their requirements must also be checked; extracting an equality does not discard its premises.

Using the function through pointers and callbacks

The same identity function can be used through a function pointer. This requires checking both the pointer type itself and the coercion of the function item to that type:

fn call_pointer<'a, C: Carrier<Assoc = T>, T: Family>(
    value: T::View<'a>,
) -> T::View<'a> {
    let f: for<'b> fn(T::View<'b>) -> T::View<'b> = identity::<C, T>;
    f(value)
}

The type of f requires it to be callable for every 'b. I therefore check that identity satisfies its declaration’s requirements for every such lifetime before allowing the coercion. The resulting pointer can then be called with f(value).

The declared equality can also establish the return type when calling through Box<dyn Fn>:

fn call_object<'a, C: Carrier<Assoc = T>, T: Family>(
    f: Box<dyn for<'b> Fn(T::View<'b>) -> <<T as Identity>::Output as Family>::View<'b>>,
    value: T::View<'a>,
) -> T::View<'a> {
    f(value)
}

Adding the following implementations for Borrowed makes both forms available for concrete calls:

impl Identity for Borrowed {
    type Output = Self;
}

impl Carrier for Borrowed {
    type Assoc = Self;
}

fn use_identity() {
    let value = 42;
    let from_pointer = call_pointer::<Borrowed, Borrowed>(&value);
    let from_object = call_object::<Borrowed, Borrowed>(
        Box::new(identity::<Borrowed, Borrowed>),
        &value,
    );
    assert_eq!(*from_pointer, 42);
    assert_eq!(*from_object, 42);
}

Using lifetime bounds already provided by declarations

Avoiding redundant bounds

An associated type declaration can provide lifetime relationships as well as type equalities:

trait Has<'r> {
    type Assoc: 'r;
}

fn shorten<'a, 'r, C>(value: &'a ()) -> &'r ()
where
    C: Has<'r, Assoc = &'a ()>,
{
    value
}

The function does not explicitly require 'a: 'r, but that relationship follows from the declaration:

Has requires:        C::Assoc: 'r
The function states: C::Assoc = &'a ()
After substitution:  &'a (): 'r
Therefore:           'a outlives 'r, so &'a () can be used as &'r ()

I use this declared relationship in the relevant checks, allowing shorten to omit a redundant 'a: 'r bound. The solver can also use such a relationship when it needs to prove T: 'r before normalizing an associated type.

One complete proof is enough

A lifetime requirement can have more than one possible proof. In this example, the bound on D provides a sufficient one:

fn from_either<'a, 'b: 'r, 'r, C, D, T>(value: T) -> Box<dyn std::fmt::Debug + 'r>
where
    T: std::fmt::Debug,
    C: Has<'a, Assoc = T>,
    D: Has<'b, Assoc = T>,
{
    Box::new(value)
}

The two possible derivations are:

Through C: T: 'a, but no relationship between 'a and 'r is known.
Through D: T: 'b and 'b: 'r, which establish T: 'r.

The return type requires T: 'r. The proof through D establishes that, so there is no need to require 'a: 'r as well.

Both premises of that proof, T: 'b and 'b: 'r, must hold together. Taking T: 'a from the first path and 'b: 'r from the second would not prove T: 'r.

I preserve these alternatives only when the candidate proofs agree on their type and const results. A candidate producing u32 cannot be merged with one producing bool merely because both have satisfiable lifetime conditions.

The remaining conditions are carried through to borrow checking. Requirements that a closure passes to its enclosing context are preserved as well; determining the return type does not discharge those requirements.

Cases that remain rejected

Unrelated projections or independent lifetimes

Using the same lifetime argument does not establish a relationship between two projections. This bound provides no equality between T::View<'a> and U::View<'a>, so it still produces E0582:

fn unrelated_output<T: Family, U: Family, F>()
where
    F: for<'a> Fn(T::View<'a>) -> U::View<'a>,
{
}

Even with an equality, substitution must preserve the corresponding lifetime. The independent 'a and 'b below still cause E0582:

fn wrong_lifetime<T, U, F>()
where
    U: Family,
    for<'a> T: Family<View<'a> = U::View<'a>>,
    F: for<'a, 'b> Fn(T::View<'a>) -> U::View<'b>,
{
}

The equality establishes T::View<'a> = U::View<'a>. It does not establish T::View<'a> = U::View<'b>. Variables in nested for<...> binders likewise retain their own scopes; matching names do not make them interchangeable.

An additional reference in the output

Reusing the input type does not justify an additional output reference whose lifetime has no independent basis:

fn extra_reference<T: Family, F>()
where
    F: for<'a> Fn(T::View<'a>) -> (T::View<'a>, &'a ()),
{
}

Substituting Erased makes the distinction explicit:

The earlier valid callback: Fn(()) -> ()
This callback:              for<'a> Fn(()) -> ((), &'a ())

The input is still just (), but the output now includes a reference that depends on 'a. The generic bound does not establish that lifetime dependency, so it still produces E0582.

Unsatisfied requirements on an associated type

The following associated type normalizes to (), but its declaration restricts its lifetime argument to 'static:

trait StaticOnly {
    type View<'a> where 'a: 'static;
}

impl StaticOnly for () {
    type View<'a> = () where 'a: 'static;
}

fn missing_requirement<F>()
where
    F: for<'a> Fn() -> <() as StaticOnly>::View<'a>,
{
}

The for<'a> bound must hold for every 'a, while StaticOnly::View<'a> requires 'a: 'static. I retain that requirement during normalization, so missing_requirement remains rejected. Replacing the output with () cannot erase the condition under which the associated type is valid.

A function that only supports restricted lifetimes

A function may return its input type and still impose a lifetime restriction. Here, restricted explicitly requires 'a: 'static:

fn restricted<'a: 'static, T: Family>(value: T::View<'a>) -> T::View<'a> {
    value
}

fn bad_pointer<T: Family>() {
    let _: for<'a> fn(T::View<'a>) -> T::View<'a> = restricted::<T>;
}

The coercion in bad_pointer still produces a type mismatch. The pointer must be callable for every 'a, but the function has a narrower requirement. Matching input and output types does not remove that restriction.

A circular equality is not an independent normalization proof

Suppose the only available equalities are:

A::Output = B::Output
B::Output = A::Output

These state that the two projections are equal. Reversing the first equality does not add evidence. The solver cannot treat a return to the original goal as proof that it has determined the normalization result.

I preserve recursive reasoning supported by established premises, and the solver does not need to expand declarations unrelated to the current goal. Some mutually recursive projections with no determinable normalization result can still reach the recursion limit. The two equations above illustrate the relationship; they do not imply that every program containing such equalities will overflow.

Changes to the compiler

I changed several checks to support the examples above:

• Output dependency checks recognize complete input types and their structural components. Once the where clauses are available, they use independent equalities to normalize the input and output while checking the required lifetime conditions.
• The next solver follows associated item and supertrait declarations to prove the trait, type equality, or outlives goal at hand. It retains the premises attached to each declaration.
• Function item matching and function pointer coercions use a consistent callable signature. A lifetime is generalized into for<'a> only when the relevant declaration requirements hold for every 'a.
• Inference, MIR, and borrow checking carry and validate the lifetime conditions left by solving. Alternative conditions and requirements passed out of closures must survive these transitions.

A behavior change with assumptions-on-binders

The accepted examples above use -Znext-solver=globally; they do not require -Zassumptions-on-binders. When that additional mode is enabled, the change also checks lifetime requirements that remain after leaving a quantified scope.

Two cases in tests/ui/assumptions_on_binders/test-infra-works.rs can be described as follows:

Known in the outer context: T: Trait
Required inside the scope:  T::Assoc: 'a for every 'a
After leaving the scope:   the requirement must still be proved

T: Trait alone cannot prove the remaining requirement. Both cases were previously accepted, and existing FIXME comments already identified that acceptance as incorrect. I changed the test from check-pass to check-fail because preserving and checking those lifetime requirements now rejects the two cases.

Scope and related issues

This output dependency analysis applies to the next solver when enabled globally. It uses complete types and established equalities while preserving projection opacity and checking any additional output lifetimes.

Issue	Relationship to this change
#107572	The main motivation: using the same GAT projection for a callback’s input and output causes E0582. The examples above cover this pattern.
#86702	The original example uses two different projections without an equality connecting them. That example still produces E0581/E0582, so I do not consider the issue resolved by this change.
#121437	The original example uses T::Native<'a>: Not<Output = T::Native<'a>>. Reusing a complete input type also applies to this associated output constraint. The original minimal example now passes type checking with the next solver enabled globally.

[rustbot]

This PR changes MIR

cc @oli-obk, @RalfJung, @JakobDegen, @vakaras

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr

[rustbot]

Thanks for the pull request, and welcome! The Rust Project has assigned @khyperia (or someone else) to review your changes, you should hear from them (or someone else) within the next two weeks.

Please see the contribution instructions and our LLM policy for more information.

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler, types
• compiler, types expanded to 76 candidates
• Random selection from 18 candidates

[jackh726]

This needs significant discussion with the types team; Zulip is the right place for that.

I'll leave this open for now, but am going to mark this as experimental. It is not going to be reviewed without discussion.

[rustbot]

This PR changes rustc_public

cc @oli-obk, @celinval, @ouz-a, @makai410

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

changes to the core type system

cc @lcnr

clippy is developed in its own repository. If possible, consider making this change to rust-lang/rust-clippy instead.

cc @rust-lang/clippy

changes to the core type system

cc @lcnr

[enginespot]

@jackh726 Thanks for the guidance. I’ve started a discussion in #t-types Zulip.
I proposed the core idea and used AI tools extensively in this work. I hope to learn from the team and help
move this issue toward a solution.

[rustbot]

changes to inspect_obligations.rs

cc @lcnr

HIR ty lowering was modified

cc @fmease

Some changes occurred to the core trait solver

cc @rust-lang/initiative-trait-system-refactor

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[rust-log-analyzer]

The job test-pr-check-1 failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

#15 5.692 Building wheels for collected packages: reuse
#15 5.693   Building wheel for reuse (pyproject.toml): started
#15 5.909   Building wheel for reuse (pyproject.toml): finished with status 'done'
#15 5.910   Created wheel for reuse: filename=reuse-4.0.3-cp310-cp310-manylinux_2_35_x86_64.whl size=132857 sha256=6a78a69541e3df9c7c106367722bab90241125ee6b7cdb81c5e40637268f85a9
#15 5.911   Stored in directory: /tmp/pip-ephem-wheel-cache-wrxmqka0/wheels/3d/8d/0a/e0fc6aba4494b28a967ab5eaf951c121d9c677958714e34532
#15 5.913 Successfully built reuse
#15 5.913 Installing collected packages: boolean-py, binaryornot, tomlkit, reuse, python-debian, markupsafe, license-expression, jinja2, chardet, attrs
#15 6.308 Successfully installed attrs-23.2.0 binaryornot-0.4.4 boolean-py-4.0 chardet-5.2.0 jinja2-3.1.4 license-expression-30.3.0 markupsafe-2.1.5 python-debian-0.1.49 reuse-4.0.3 tomlkit-0.13.0
#15 6.308 WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv
#15 DONE 6.4s
---
[RUSTC-TIMING] xflags_macros test:false 1.589
    Checking xflags v0.3.2
[RUSTC-TIMING] xflags test:false 0.150
    Checking windows-future v0.3.2
error[E0275]: overflow evaluating whether `windows_core::ComObject<<ReadyOperation_Impl<T> as windows_core::IUnknownImpl>::Impl>` is well-formed
   --> /cargo/registry/src/index.crates.io-1949cf8c6b5b557f/windows-future-0.3.2/src/async_ready.rs:49:1
    |
 49 |   #[implement(IAsyncOperation<T>, IAsyncInfo)]
    |   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ in this attribute macro expansion
    |
   ::: /cargo/registry/src/index.crates.io-1949cf8c6b5b557f/windows-implement-0.60.2/src/lib.rs:40:1
    |
 40 | / pub fn implement(
 41 | |     attributes: proc_macro::TokenStream,
 42 | |     type_tokens: proc_macro::TokenStream,
 43 | | ) -> proc_macro::TokenStream {
    | |____________________________- in this expansion of `#[implement]`
    |
note: the requirement `windows_core::ComObject<<ReadyOperation_Impl<T> as windows_core::IUnknownImpl>::Impl> well-formed` appears on the `impl`'s method `to_object` but not on the corresponding trait's method
   --> /cargo/registry/src/index.crates.io-1949cf8c6b5b557f/windows-core-0.62.2/src/unknown.rs:147:8
    |
 78 | pub trait IUnknownImpl {
    |           ------------ in this trait
...
147 |     fn to_object(&self) -> ComObject<Self::Impl>
    |        ^^^^^^^^^ this trait's method doesn't have the requirement `windows_core::ComObject<<ReadyOperation_Impl<T> as windows_core::IUnknownImpl>::Impl> well-formed`

error[E0275]: overflow evaluating whether `windows_core::ComObject<<ReadyActionWithProgress_Impl<P> as windows_core::IUnknownImpl>::Impl>` is well-formed
   --> /cargo/registry/src/index.crates.io-1949cf8c6b5b557f/windows-future-0.3.2/src/async_ready.rs:54:1
    |
 54 |   #[implement(IAsyncActionWithProgress<P>, IAsyncInfo)]
    |   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ in this attribute macro expansion
    |
   ::: /cargo/registry/src/index.crates.io-1949cf8c6b5b557f/windows-implement-0.60.2/src/lib.rs:40:1
    |
 40 | / pub fn implement(
 41 | |     attributes: proc_macro::TokenStream,
 42 | |     type_tokens: proc_macro::TokenStream,
 43 | | ) -> proc_macro::TokenStream {
    | |____________________________- in this expansion of `#[implement]`
    |
note: the requirement `windows_core::ComObject<<ReadyActionWithProgress_Impl<P> as windows_core::IUnknownImpl>::Impl> well-formed` appears on the `impl`'s method `to_object` but not on the corresponding trait's method
   --> /cargo/registry/src/index.crates.io-1949cf8c6b5b557f/windows-core-0.62.2/src/unknown.rs:147:8
    |
 78 | pub trait IUnknownImpl {
    |           ------------ in this trait
...
147 |     fn to_object(&self) -> ComObject<Self::Impl>
    |        ^^^^^^^^^ this trait's method doesn't have the requirement `windows_core::ComObject<<ReadyActionWithProgress_Impl<P> as windows_core::IUnknownImpl>::Impl> well-formed`

error[E0275]: overflow evaluating whether `windows_core::ComObject<<ReadyOperationWithProgress_Impl<T, P> as windows_core::IUnknownImpl>::Impl>` is well-formed
   --> /cargo/registry/src/index.crates.io-1949cf8c6b5b557f/windows-future-0.3.2/src/async_ready.rs:59:1
    |
 59 |   #[implement(IAsyncOperationWithProgress<T, P>, IAsyncInfo)]
    |   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ in this attribute macro expansion
    |
   ::: /cargo/registry/src/index.crates.io-1949cf8c6b5b557f/windows-implement-0.60.2/src/lib.rs:40:1
    |
 40 | / pub fn implement(
 41 | |     attributes: proc_macro::TokenStream,
 42 | |     type_tokens: proc_macro::TokenStream,
 43 | | ) -> proc_macro::TokenStream {
    | |____________________________- in this expansion of `#[implement]`
    |
note: the requirement `windows_core::ComObject<<ReadyOperationWithProgress_Impl<T, P> as windows_core::IUnknownImpl>::Impl> well-formed` appears on the `impl`'s method `to_object` but not on the corresponding trait's method
   --> /cargo/registry/src/index.crates.io-1949cf8c6b5b557f/windows-core-0.62.2/src/unknown.rs:147:8
    |
 78 | pub trait IUnknownImpl {
    |           ------------ in this trait
...
147 |     fn to_object(&self) -> ComObject<Self::Impl>
    |        ^^^^^^^^^ this trait's method doesn't have the requirement `windows_core::ComObject<<ReadyOperationWithProgress_Impl<T, P> as windows_core::IUnknownImpl>::Impl> well-formed`

error[E0275]: overflow evaluating whether `windows_core::ComObject<<Operation_Impl<T> as windows_core::IUnknownImpl>::Impl>` is well-formed
   --> /cargo/registry/src/index.crates.io-1949cf8c6b5b557f/windows-future-0.3.2/src/async_spawn.rs:102:1
    |
102 |   #[implement(IAsyncOperation<T>, IAsyncInfo)]
    |   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ in this attribute macro expansion
    |
   ::: /cargo/registry/src/index.crates.io-1949cf8c6b5b557f/windows-implement-0.60.2/src/lib.rs:40:1
    |
 40 | / pub fn implement(
 41 | |     attributes: proc_macro::TokenStream,
 42 | |     type_tokens: proc_macro::TokenStream,
 43 | | ) -> proc_macro::TokenStream {
    | |____________________________- in this expansion of `#[implement]`
    |
note: the requirement `windows_core::ComObject<<Operation_Impl<T> as windows_core::IUnknownImpl>::Impl> well-formed` appears on the `impl`'s method `to_object` but not on the corresponding trait's method
   --> /cargo/registry/src/index.crates.io-1949cf8c6b5b557f/windows-core-0.62.2/src/unknown.rs:147:8
    |
 78 | pub trait IUnknownImpl {
    |           ------------ in this trait
...
147 |     fn to_object(&self) -> ComObject<Self::Impl>
    |        ^^^^^^^^^ this trait's method doesn't have the requirement `windows_core::ComObject<<Operation_Impl<T> as windows_core::IUnknownImpl>::Impl> well-formed`

error[E0275]: overflow evaluating whether `windows_core::ComObject<<ActionWithProgress_Impl<P> as windows_core::IUnknownImpl>::Impl>` is well-formed
   --> /cargo/registry/src/index.crates.io-1949cf8c6b5b557f/windows-future-0.3.2/src/async_spawn.rs:107:1
    |
107 |   #[implement(IAsyncActionWithProgress<P>, IAsyncInfo)]
    |   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ in this attribute macro expansion
    |
   ::: /cargo/registry/src/index.crates.io-1949cf8c6b5b557f/windows-implement-0.60.2/src/lib.rs:40:1
    |
 40 | / pub fn implement(
 41 | |     attributes: proc_macro::TokenStream,
 42 | |     type_tokens: proc_macro::TokenStream,
 43 | | ) -> proc_macro::TokenStream {
    | |____________________________- in this expansion of `#[implement]`
    |
note: the requirement `windows_core::ComObject<<ActionWithProgress_Impl<P> as windows_core::IUnknownImpl>::Impl> well-formed` appears on the `impl`'s method `to_object` but not on the corresponding trait's method
   --> /cargo/registry/src/index.crates.io-1949cf8c6b5b557f/windows-core-0.62.2/src/unknown.rs:147:8
    |
 78 | pub trait IUnknownImpl {
    |           ------------ in this trait
...
147 |     fn to_object(&self) -> ComObject<Self::Impl>
    |        ^^^^^^^^^ this trait's method doesn't have the requirement `windows_core::ComObject<<ActionWithProgress_Impl<P> as windows_core::IUnknownImpl>::Impl> well-formed`

error[E0275]: overflow evaluating whether `windows_core::ComObject<<OperationWithProgress_Impl<T, P> as windows_core::IUnknownImpl>::Impl>` is well-formed
   --> /cargo/registry/src/index.crates.io-1949cf8c6b5b557f/windows-future-0.3.2/src/async_spawn.rs:112:1
    |
112 |   #[implement(IAsyncOperationWithProgress<T, P>, IAsyncInfo)]
    |   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ in this attribute macro expansion
    |
   ::: /cargo/registry/src/index.crates.io-1949cf8c6b5b557f/windows-implement-0.60.2/src/lib.rs:40:1
    |
 40 | / pub fn implement(
 41 | |     attributes: proc_macro::TokenStream,
 42 | |     type_tokens: proc_macro::TokenStream,
 43 | | ) -> proc_macro::TokenStream {
    | |____________________________- in this expansion of `#[implement]`
    |
note: the requirement `windows_core::ComObject<<OperationWithProgress_Impl<T, P> as windows_core::IUnknownImpl>::Impl> well-formed` appears on the `impl`'s method `to_object` but not on the corresponding trait's method
   --> /cargo/registry/src/index.crates.io-1949cf8c6b5b557f/windows-core-0.62.2/src/unknown.rs:147:8
    |
 78 | pub trait IUnknownImpl {
    |           ------------ in this trait
...
147 |     fn to_object(&self) -> ComObject<Self::Impl>
    |        ^^^^^^^^^ this trait's method doesn't have the requirement `windows_core::ComObject<<OperationWithProgress_Impl<T, P> as windows_core::IUnknownImpl>::Impl> well-formed`

[RUSTC-TIMING] project_model test:false 4.027
    Checking pulldown-cmark-to-cmark v10.0.4
[RUSTC-TIMING] pulldown_cmark_to_cmark test:false 0.322
For more information about this error, try `rustc --explain E0275`.