-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Add support for multiple designated types for an operator declaration. #19816
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 multiple designated types for an operator declaration. #19816
Conversation
Update the representation to allow for multiple types to be specified for a single operator. No parsing, serialization, or deserialization support yet, so NFC.
Add parsing, type checking, serialization, and deserialization support for specifying multiple types as "designated" for operator lookup for a given operator declaration. The constraint solver still considers only the first type when deciding the order to attempt the elements of a disjunction, so this doesn't really change behavior yet.
@swift-ci Please smoke test |
It looks like I missed a few printing changes so I'll finish those up and push another commit tomorrow. |
@swift-ci Please smoke test |
@swift-ci Please smoke test Linux platform |
1 similar comment
@swift-ci Please smoke test Linux platform |
@swift-ci Please smoke test |
@dmbryson Is this issue that popped up in my linux build one you're already aware of?
Here's the log: https://ci.swift.org/job/swift-PR-Linux-smoke-test/10353/consoleFull#-906433348ba62d58e-7248-467b-91e0-c7508d5cf947 |
Will retry in case this is a non-deterministic failure. |
@swift-ci Please smoke test Linux platform |
:/ Not sure what happened there. There should have been more detailed log messages for any of the failure conditions. |
Hmm, failed again. Very strange. |
Looking into it: rdar://problem/45196629 lane-release.llbuild test is failing in some Swift-CI linux runs |
@swift-ci Please smoke test |
@rintaro @harlanhaskins It's not clear to me if there is a better way to deal with the libSyntax update here. This captures the syntax, but nothing about the semantic meaning of the identifiers in the list after the colon. |
''', | ||
is_optional=True), | ||
]), | ||
|
||
Node('IdentifierList', kind='SyntaxCollection', | ||
element='IdentifierToken'), | ||
|
||
# infix-operator-group -> ':' identifier ','? identifier? |
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.
Can you update this grammar to:
# infix-operator-group -> ':' identifier-list
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.
Ah yes, I'll fix that up.
''', | ||
is_optional=True), | ||
]), | ||
|
||
Node('IdentifierList', kind='SyntaxCollection', |
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.
This probably needs another production that includes a trailing comma after each identifier.
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 patterned this on what was happening for inheritance with InheritedTypeList
. I don't see any notion of a comma-separated list there. Am I missing something?
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.
Ah, I missed InheritedType
which has the trailing comma embedded in it.
Latest error:
|
@swift-ci Please smoke test Linux platform |
I'll merge the other Swift syntax fixes in a separate PR. |
Add parsing, type checking, serialization, and deserialization support
for specifying multiple types as "designated" for operator lookup for
a given operator declaration.
The constraint solver still considers only the first type when
deciding the order to attempt the elements of a disjunction, so this
doesn't really change behavior yet.