-
Notifications
You must be signed in to change notification settings - Fork 419
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 support for qualified interface access #25924
Add support for qualified interface access #25924
Conversation
Strangely, even though we have an `isym` when building the class hierarchy, I chose to use the symbol's name to construct an `implements` statement. This works when the name is available in scope without qualification, but not when qualified access is used. The principled solution is to allow interface statements to be constructed using a known interface symbol. This PR does that, and switches the class hierarchy logic to avoid using a name. Signed-off-by: Danila Fedorin <[email protected]>
Signed-off-by: Danila Fedorin <[email protected]>
module M { | ||
import Other; | ||
class C: Other.CC {} | ||
record R: Other.II {} |
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 about this case?
record RR {}
RR implements Other.II;
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 think that's not valid syntactically, but I can double check.
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.
you are correct, it is not valid syntax
@@ -317,6 +317,9 @@ struct Witnesses { | |||
|
|||
class ImplementsStmt final : public Stmt { | |||
public: | |||
static ImplementsStmt* build(InterfaceSymbol* isym, | |||
CallExpr* actuals, | |||
BlockStmt* body); | |||
static ImplementsStmt* build(const char* name, |
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.
do we still need the const char*
overload? Is it ever the correct thing to use?
It is still used by convert-uast
, but I suspect that to make R implements Other.I
work that also should change.
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.
Well, we don't always have scope resolution results available in convert-uast.cpp
, so const char*
will be needed sometimes. I can adjust it to use the interface symbol when possible.
Per an offline conversation with Jade, given that |
Closes #25829.
Strangely, even though we have an
isym
when building the class hierarchy, I chose to use the symbol's name to construct animplements
statement. This works when the name is available in scope without qualification, but not when qualified access is used. The principled solution is to allow interface statements to be constructed using a known interface symbol. This PR does that, and switches the class hierarchy logic to avoid using a name.Reviewed by @jabraham17 -- thanks!
Testing