Implement parsing and conversion of generalized where clauses

[jroesch]

Going to tentatively open a PR before I move on to other things tonight. I think everything should be good minus a failing test case for region bounds (gonna push that now, i.e 'a : 'b). r? @nikomatsakis

Fixes #20023.

[nikomatsakis]

I'll take another read through, but what is here looks pretty good to me.

There are several follow-on points though. These could be addressed in separate PRs. I will create issues for these points and attach them to #17657.

1. According to the RFC, where clauses that do not involve parameters (e.g., where int : Eq) are supposed to be illegal, but we can always open an issue to check for those.

2. We'll want to modify the code that checks that impls are consistent with traits. I think that it only looks at the bounds of the TypeParameterDef. We should modify it to just call to_bounds() on the Generics and examine the resulting predicate sets. We may want to change it to just create its own trait fulfillment context and check that, given the parameter environment derived from the trait, we can derive all the requirements of the impl. This could also be something we address in a followup PR.

3. The last point gives rise to a curious case where the impl (which has more concrete types than the trait) actually knows that some methods can never be invoked. We never did clarify what to do here. I am presently leaning towards allowing impl methods to be declared with no body, which corresponds to a case that we can statically show does not occur. Thus fn foo(); in an impl would be equivalent to fn foo() { panic!() } (and that is how we would codegen it), except that we statically check that the where clauses from the trait, if substituted with the type parameters of the impl, cannot be satisfied.

4. I think we will need to modify the parser to permit for qualifiers to appear in more places. In particular, i'd like to be able to write something like this:

   where for<'a, 'b> &'a T : Foo<&'b T>

but today the parser only accepts for after the :. the rest of the code already considers 'a and 'b to be in scope for the self-type of the trait, so it's just the parser that has to be changed. I imagine that the for, in that case, would distribute over all the attached where clauses, so:

where for<'a> T : Foo<&'a T> + Bar<&'a T>

would be equivalent to:

where T : for<'a> Foo&'a T> + for<'a> Bar<&'a T>

Points 3 and 4 probably require an RFC.

[nikomatsakis]

I've created issues for each of those points in #17657

[nikomatsakis]

No, this is fine, I don't see how privacy impacts anything here.

[nikomatsakis]

OK, I went through the commits and offered commits. It's also probably a good idea to cleanup the history a bit, though I'm not a stickler about this (but the intermediate commits don't seem... especially useful here; also, don't worry about preserving authorship on the commit that came from me). I'd like to see some more tests. Here are two I wrote to test the code, they seem to work (which is awesome):

https://github.com/nikomatsakis/rust/tree/jroesch-generalized-where-clause-parser/

It'd be great to see also tests that add builtin bounds locally, since they are treated rather differently. In particular Copy and Sized. I think though that Sized still has some parts of the code that use the bounds lists rather than checking the parameter environment. I was working on refactoring those. So you may encounter that those tests don't work, in which case we should just follow another follow-up issue (and I should figure out why my branch wasn't bootstrapping...)

[nikomatsakis]

OK, ping me on IRC if there are any questions.

[jroesch]

I just rebased, and squashed them into a single commit. Hopefully I have addressed all the comments, and will begin chasing down some of the follow up issues.

[nikomatsakis]

As discussed on IRC, r+ with one additional test that shows a where clause with a generic trait, so that substitution is required.

[jroesch]

Tests should be in an acceptable state now. Should be good to go 👍.

[nikomatsakis]

Giving p=1 because this enables work on stdlib