-
Notifications
You must be signed in to change notification settings - Fork 439
Fix debugInitCall #1543
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
Fix debugInitCall #1543
Conversation
09f9c9b
to
f1f846b
Compare
@swift-ci Please test |
@swift-ci Please test Windows |
1 similar comment
@swift-ci Please test Windows |
f1f846b
to
c017cfd
Compare
@swift-ci Please test |
@swift-ci please test windows |
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'd personally prefer not having the runtime hackery by making the assumption that SyntaxChildChoices
is within a type and then:
- Not supporting printing
SyntaxChildChoices
directly (can override to print something to that effect) - Pass down the parent type name when making the recursive call
But it's just a debug call and only in _SwiftSyntaxTestSupport so I don't feel super strongly about that. Any thoughts @rintaro?
I broke `debugInitCall` when I removed the custom mirrors for syntax nodes. Fix it again, also fixing some more issues along the way that previously caused us to generate Swift code that didn’t compile.
c017cfd
to
6017000
Compare
I found a fairly elegant solution without calling into the runtime. |
@swift-ci Please test |
@swift-ci Please test Windows |
Ah, I forgot we had |
@swift-ci Please test Windows |
@swift-ci Please test macOS |
I broke
debugInitCall
when I removed the custom mirrors for syntax nodes. Fix it again, also fixing some more issues along the way that previously caused us to generate Swift code that didn’t compile.