-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[Parse] Fix nested ifConfig compiler checks #74415
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
Conversation
I'm unsure if this fix needs to be ported to SwiftSyntax as well — I couldn't find the "skip parsing unmatched compiler checks" logic there. If it exists, could someone please point me to it? |
The change looks good to me. Thanks! @kabiroberai Could you squash the change and add relevant commit message? Or I if you write it here, I can squash and add the comment when merging. |
@rintaro feel free to use the issue title: "[Parse] Fix nested ifConfig compiler checks". Thanks! |
@swift-ci Please smoke test |
OK, but I hope to put more explanation in the comment.
|
The parser is supposed to avoid looking inside unmatched `#if` compiler (et al) blocks. This usually means that the following code builds fine #if compiler(>=100) foo bar #endif however, a logical bug meant that if the check was nested inside an already-inactive `#if` block, it would not adhere to this evaluation-skipping behavior #if false #if compiler(>=100) foo bar // error! #endif #endif This PR fixes this specific case.
The parser is supposed to avoid looking inside unmatched
#if compiler
(et al) blocks. This usually means that the following code builds finehowever, a logical bug meant that if the check was nested inside an already-inactive
#if
block, it would not adhere to this evaluation-skipping behaviorThis PR fixes this specific case.