Refactor supertrait handling #23026
Refactor supertrait handling #23026
Conversation
|
cc @jroesch |
👍 |
nikomatsakis
force-pushed
the
issue-20220-supertrait
branch
from
dd072a8
to
4dbe918
Compare
|
☔ The latest upstream changes (presumably #22235) made this pull request unmergeable. Please resolve the merge conflicts. |
interface, so that we can perform this query without requiring a full trait def or set of supertraits.
us to construct trait-references and do other things without forcing a full evaluation of the supertraits. One downside of this scheme is that we must invoke `ensure_super_predicates` before using any construct that might require knowing about the super-predicates.
nikomatsakis
force-pushed
the
issue-20220-supertrait
branch
from
4dbe918
to
1d3de19
Compare
|
r+ with comments addressed |
|
@bors r+ 9b332ff p=1 Giving higher priority because I believe this fixes a number of open associated type issues (probably more than I have tagged here). |
|
⌛ Testing commit 9b332ff with merge eb1fc4e... |
|
💔 Test failed - auto-linux-64-nopt-t |
|
@bors: retry (Failed due to a force push, sorry) |
|
⚡ Previous build results are reusable. Rebuilding only auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-32-nopt-t, auto-win-32-opt, auto-win-64-nopt-t, auto-win-64-opt... |
…sakis The main gist of this PR is commit 1077efb which removes the list of supertraits from the `TraitDef` and pulls them into a separate table, which is accessed via `lookup_super_predicates`. This is analogous to `lookup_predicates`, which gets the complete where clause. This allows us to create the `TraitDef`, which contains the list generics and so forth, without fully knowing the list of supertraits. This in turn allows the *supertrait listing* to contain references to associated types like `<Self as Foo>::Item`, which were previously impossible because conversion required having the `TraitDef` for `Foo`. We do not yet support `Self::Item` in a supertrait listing. This doesn't work because to convert that, it attempts to expand out the full set of supertraits, which are in the process of being created. This could potentially be worked out by having the expansion of supertraits proceed in a lazy fashion, but we'd have to define shadowing rules for associated types which we don't currently have. Along the way (in 9de9ec5) I also removed the restriction against duplicate bounds and generalized the code so that it can handle having the same supertrait multiple times with different arguments, e.g. `Foo : Bar<i32> + Bar<u32>`. This restriction was serving no particular purpose, since the same trait could be extended multiple times indirectly, and in the era of multidispatch it is actively harmful. This is technically a [breaking-change] because it affects the definition of a super-trait. Anything in a where clause that looks like `where Self : Foo` is now considered a supertrait. Because cycles are disallowed in supertraits, that could lead to some errors. This has not been observed in any existing code. r? @nrc
|
⌛ Testing commit 9b332ff with merge f0c74f8... |
The main gist of this PR is commit 1077efb which removes the list of supertraits from the
TraitDefand pulls them into a separate table, which is accessed vialookup_super_predicates. This is analogous tolookup_predicates, which gets the complete where clause. This allows us to create theTraitDef, which contains the list generics and so forth, without fully knowing the list of supertraits. This in turn allows the supertrait listing to contain references to associated types like<Self as Foo>::Item, which were previously impossible because conversion required having theTraitDefforFoo.We do not yet support
Self::Itemin a supertrait listing. This doesn't work because to convert that, it attempts to expand out the full set of supertraits, which are in the process of being created. This could potentially be worked out by having the expansion of supertraits proceed in a lazy fashion, but we'd have to define shadowing rules for associated types which we don't currently have.Along the way (in 9de9ec5) I also removed the restriction against duplicate bounds and generalized the code so that it can handle having the same supertrait multiple times with different arguments, e.g.
Foo : Bar<i32> + Bar<u32>. This restriction was serving no particular purpose, since the same trait could be extended multiple times indirectly, and in the era of multidispatch it is actively harmful.This is technically a [breaking-change] because it affects the definition of a super-trait. Anything in a where clause that looks like
where Self : Foois now considered a supertrait. Because cycles are disallowed in supertraits, that could lead to some errors. This has not been observed in any existing code.r? @nrc