-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Push ast::{ItemKind, ImplItemKind}::OpaqueTy
hack down into lowering
#66197
Conversation
f1f191b
to
9ce6457
Compare
This comment has been minimized.
This comment has been minimized.
9ce6457
to
4ee926d
Compare
ItemKind::TyAlias(ref ty, _) => { | ||
let def_kind = match ty.kind.opaque_top_hack() { | ||
None => DefKind::TyAlias, | ||
Some(_) => DefKind::OpaqueTy, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, I noticed today that DefKind::OpaqueTy
and DefKind::AssocOpaqueTy
exist despite the existential type
syntax being removed.
Is it possible to remove them after this PR or it will require reworking lowering as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure. We might need something like:
type Foo = (impl Bar, impl Baz); // In AST
=> (HIR)
opaque type _0: Bar; // DefKind::OpaqueTy
opaque type _1: Baz; // DefKind::OpaqueTy
type Foo = ( // DefKind::TyAlias
_0, // TyKind::Def(..)
_1 // TyKind::Def(..)
);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From my point of view: as long we still have something like opaque type
in HIR still, that's good enough for my upcoming PR. I'd rather not remove that for a while yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We won't get rid of opaque types in HIR (they will always just arise from type aliases).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that's what I thought. :-)
This comment has been minimized.
This comment has been minimized.
4ee926d
to
c43e4d1
Compare
Looks good to me, thanks! @bors r+ |
📌 Commit c43e4d1 has been approved by |
Push `ast::{ItemKind, ImplItemKind}::OpaqueTy` hack down into lowering We currently have a hack in the form of `ast::{ItemKind, ImplItemKind}::OpaqueTy` which is constructed literally when you write `type Alias = impl Trait;` but not e.g. `type Alias = Vec<impl Trait>;`. Per rust-lang/rfcs#2515, this needs to change to allow `impl Trait` in nested positions. This PR achieves this change for the syntactic aspect but not the semantic one, which will require changes in lowering and def collection. In the interim, `TyKind::opaque_top_hack` is introduced to avoid knock-on changes in lowering, collection, and resolve. These hacks can then be removed and fixed one by one until the desired semantics are supported. r? @varkor
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
c43e4d1
to
03cf0d7
Compare
Ran @bors r=varkor |
📌 Commit 03cf0d7 has been approved by |
Push `ast::{ItemKind, ImplItemKind}::OpaqueTy` hack down into lowering We currently have a hack in the form of `ast::{ItemKind, ImplItemKind}::OpaqueTy` which is constructed literally when you write `type Alias = impl Trait;` but not e.g. `type Alias = Vec<impl Trait>;`. Per rust-lang/rfcs#2515, this needs to change to allow `impl Trait` in nested positions. This PR achieves this change for the syntactic aspect but not the semantic one, which will require changes in lowering and def collection. In the interim, `TyKind::opaque_top_hack` is introduced to avoid knock-on changes in lowering, collection, and resolve. These hacks can then be removed and fixed one by one until the desired semantics are supported. r? @varkor
Push `ast::{ItemKind, ImplItemKind}::OpaqueTy` hack down into lowering We currently have a hack in the form of `ast::{ItemKind, ImplItemKind}::OpaqueTy` which is constructed literally when you write `type Alias = impl Trait;` but not e.g. `type Alias = Vec<impl Trait>;`. Per rust-lang/rfcs#2515, this needs to change to allow `impl Trait` in nested positions. This PR achieves this change for the syntactic aspect but not the semantic one, which will require changes in lowering and def collection. In the interim, `TyKind::opaque_top_hack` is introduced to avoid knock-on changes in lowering, collection, and resolve. These hacks can then be removed and fixed one by one until the desired semantics are supported. r? @varkor
⌛ Testing commit 03cf0d7 with merge 29095e1395f6f446330750531b65536d9066d6f7... |
Push `ast::{ItemKind, ImplItemKind}::OpaqueTy` hack down into lowering We currently have a hack in the form of `ast::{ItemKind, ImplItemKind}::OpaqueTy` which is constructed literally when you write `type Alias = impl Trait;` but not e.g. `type Alias = Vec<impl Trait>;`. Per rust-lang/rfcs#2515, this needs to change to allow `impl Trait` in nested positions. This PR achieves this change for the syntactic aspect but not the semantic one, which will require changes in lowering and def collection. In the interim, `TyKind::opaque_top_hack` is introduced to avoid knock-on changes in lowering, collection, and resolve. These hacks can then be removed and fixed one by one until the desired semantics are supported. r? @varkor
@bors retry rolled up. |
Push `ast::{ItemKind, ImplItemKind}::OpaqueTy` hack down into lowering We currently have a hack in the form of `ast::{ItemKind, ImplItemKind}::OpaqueTy` which is constructed literally when you write `type Alias = impl Trait;` but not e.g. `type Alias = Vec<impl Trait>;`. Per rust-lang/rfcs#2515, this needs to change to allow `impl Trait` in nested positions. This PR achieves this change for the syntactic aspect but not the semantic one, which will require changes in lowering and def collection. In the interim, `TyKind::opaque_top_hack` is introduced to avoid knock-on changes in lowering, collection, and resolve. These hacks can then be removed and fixed one by one until the desired semantics are supported. r? @varkor
We currently have a hack in the form of
ast::{ItemKind, ImplItemKind}::OpaqueTy
which is constructed literally when you writetype Alias = impl Trait;
but not e.g.type Alias = Vec<impl Trait>;
. Per rust-lang/rfcs#2515, this needs to change to allowimpl Trait
in nested positions. This PR achieves this change for the syntactic aspect but not the semantic one, which will require changes in lowering and def collection. In the interim,TyKind::opaque_top_hack
is introduced to avoid knock-on changes in lowering, collection, and resolve. These hacks can then be removed and fixed one by one until the desired semantics are supported.r? @varkor