Extra trait bound makes function body fail to typecheck

[jplatte]

I tried this code (playground):

pub trait Foo<'a> {}

impl Foo<'_> for () {}
impl<'a, T> Foo<'a> for Option<T> where T: Foo<'a> {}

pub fn bar<T>()
where
    T: for<'a> Foo<'a>,
{
}

fn baz<'a>()
where
    (): Foo<'a>,
{
    bar::<Option<()>>();
}

Or with references instead of Option

impl<'a, 'b, T> Foo<'a> for &'b T where T: Foo<'a> {}
bar::<&()>();

I expected to see this happen: Compile successfully, with or without the unneeded (): Foo<'a> bound.

Instead, this happened: It works when the (): Foo<'a> bound is removed, but as written it produces:

error: implementation of `Foo` is not general enough
  --> src/lib.rs:16:5
   |
1  | pub trait Foo<'a> {}
   | -------------------- trait `Foo` defined here
...
16 |     bar::<Option<()>>();
   |     ^^^^^^^^^^^^^^^^^ implementation of `Foo` is not general enough
   |
   = note: `Option<()>` must implement `Foo<'0>`, for any lifetime `'0`...
   = note: ...but `Option<()>` actually implements `Foo<'1>`, for some specific lifetime `'1`

Meta

rustc --version --verbose:

rustc 1.50.0 (cb75ad5db 2021-02-10)
binary: rustc
commit-hash: cb75ad5db02783e8b0222fee363c5f63f7e2cf5b
commit-date: 2021-02-10
host: x86_64-unknown-linux-gnu
release: 1.50.0

Also happens on Nightly.

[jplatte]

@rustbot label: +A-traits

[BoxyUwU]

theres a zulip topic in wg-traits about this here

[bsodmike]

I'm on rustc 1.59.0-beta.5 (28c8a34e1 2022-01-27) and am getting this as well,

error: implementation of `sqlx::Decode` is not general enough
   --> src/models.rs:183:5
    |
183 |     Decode,
    |     ^^^^^^ implementation of `sqlx::Decode` is not general enough
    |
    = note: `std::string::String` must implement `sqlx::Decode<'0, sqlx::Postgres>`, for some specific lifetime `'0`...
    = note: ...but it actually implements `sqlx::Decode<'r, sqlx::Postgres>`
    = note: this error originates in the derive macro `Decode` (in Nightly builds, run with -Z macro-backtrace for more info)

[grv07]

I am on 1.65 and still getting this :(

[frederikhors]

Is there a way to close this? This is very huge.

[MirrorBytes]

It's been 3 years and this issue is still occurring on 1.76.0. Not even higher-ranked trait bounds fixes this; applying them causes another set of errors, and after correcting them, that ultimately leads right back to this one.

[BoxyUwU]

I suspect we will never fix this and it should be closed as wontfix, the FCP in #119820 means that we never intend to consider the region constraint 'a eq !'0 during candidate assembly for the goal so I don't think we'll ever have a way to choose the impl candidate over the param candidate.

In theory (under the new solver) the proof tree for the issue description should look somewhat like:

• for<'a> Option<()>: Foo<'a>
  • Option<()>: Foo<'?0> // instantiating the goal with placeholders then canonicalizing it results in all regions being infers
    • Impl Candidate Option<?0>: Foo<'?1>
      • which has a nested goal of ?0: Foo<'?1>
    • Param Candidate Option<()>: Foo<'?1>

Both of these candidates will have results of Ok(Yes) with external constraints for equating '?0 from the goal with the in the candidate. The region constraint from the param candidate (which does not actually hold) is only checked in the root for<'a> Option<()>: Foo<'a> goal after we have already completed candidate assembly for the Option<()>: Foo<'?0> goal.

Going to just copy the thing we did with #121602 and do an fcp to close this incase anyone on t-types thinks there's a reasonable way to support this that does not involve going back on our decision in #119820.
@rfcbot fcp close

(as a sidenote the bump on this thread is hilarious timing as I intended to write this fcp close comment once I got back from rust nation but had not gotten the chance to find this issue again so the notification was perfect for saving me time doing that lol)

[rfcbot]

Team member @BoxyUwU has proposed to close this. The next step is review by the rest of the tagged team members:

• @BoxyUwU
• @aliemjay
• @compiler-errors
• @jackh726
• @lcnr
• @nikomatsakis
• @oli-obk
• @spastorino

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[oli-obk]

We should keep this issue open for improving the diagnostics (or open a new one)

Also not sure whether we have a test. Should add one, too

[lcnr]

This could get theoretically fixed by switching to an entirely eager approach to region unification/constraints.

I don't expect that to happen any time soon (next ~5 years) so I believe wontfix to be appropriate.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[jplatte]

I came across a seemingly related issue with many many more linked issues yesterday: #24066 (via this blog post: https://veera.app/trait_selection_bug.html)
If this is not fixable in the next years, does the same apply there?

[rfcbot]

The final comment period, with a disposition to close, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.