-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Add missing types to TASTy reflect #5483
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
Add missing types to TASTy reflect #5483
Conversation
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.
It seems the new abstract types are not used, what is the motivation of having more refined types?
abstract class TypeTreeCoreModule { | ||
|
||
/** Type tree representing an inferred type */ | ||
type Synthetic <: TypeTree |
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.
Inferred
instead of Synthetic
?
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.
Good idea. I will propose it in another PR.
type Return = tpd.Return | ||
type Repeated = tpd.SeqLiteral | ||
type Inlined = tpd.Inlined | ||
type SelectOuter = tpd.Select |
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.
What is SelectOuter
? I think maybe there is no need for constructor for Inline
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.
Select outer is a special case of a Select
where it keeps track of the inlined scoped to avoid ambiguities.
Inline is used to keep track of the source file where the tree came from to have a correct position. If the macros would just drop them, every position in the resulting tree would be incorrect.
When working on gestalt, I have a hypothesis that macro authors will never need to inspect type trees, because type trees are not semantic -- instead they can always inspect types. If this assumption is true, it can help simplify the reflection API. |
That is assuming that we do not care about positions. For example we would not be able to emit an error such as: fooMacro[List[Int]]
^^^ |
No description provided.