Use the SwiftIfConfig library for evaluating #if conditions #75688
Conversation
|
Note that this builds on #75014; only the last commit is new. |
DougGregor
force-pushed
the
swiftifconfig-replace-cpp
branch
from
4551387 to
4d8a9ff
Compare
|
@swift-ci please smoke test |
|
@swift-ci please test source compatibility |
DougGregor
requested review from
ahoppen,
bnbarham,
CodaFi,
hamishknight and
rintaro
as code owners
| var description: String { | ||
| switch self { | ||
| case .unexpectedRuntimeCondition: | ||
| return "unexpected argument for the '_runtime' condition; expected '_Native' or '_ObjC'" |
There was a problem hiding this comment.
Isn’t _multithreaded also allowed, based on the check above?
There was a problem hiding this comment.
Heh, yes. I was originally following the actually-incorrect diagnostic text in the compiler itself to try to minimize the diffs in this PR. We can fix this now.
| ) -> Int { | ||
| // Retrieve the #if condition that we're evaluating here. | ||
| // FIXME: Use 'ExportedSourceFile' when C++ parser is replaced. | ||
| let textBuffer = UnsafeBufferPointer<UInt8>(start: ifConditionText.data, count: ifConditionText.count) |
There was a problem hiding this comment.
Don’t we have an ExportedSourceFile already (the one that we also use for macro evaluation)? Or is this happening earlier where we haven’t created the ExportedSourceFile yet?
There was a problem hiding this comment.
I'm following the path @rintaro used for checking the definitions of macros, which avoids running the swift-syntax parser on the whole file (for performance reasons). This also avoids the somewhat brittle "go find this exact swift-syntax node at this source location" lookup we need to do with that approach, which can fail when the C++ parser and SwiftParser don't recover in exactly the same way.
There was a problem hiding this comment.
I see. I was still thinking we had the syntax tree for the entire file anyway and forgot that we no longer parse it completely.
Whoops, bad rebase on my part now that SE-0439 has landed and made this code well-formed. |
|
@swift-ci please test |
|
@swift-ci please test Windows |
|
Oh, I bet I have to fix my blatant layering violation for Windows . |
|
@swift-ci please smoke test |
|
@swift-ci please test Windows |
DougGregor
force-pushed
the
swiftifconfig-replace-cpp
branch
2 times, most recently
from
d2390ed to
0735f51
Compare
|
@swift-ci please test |
|
@swift-ci please test source compatibility |
|
@swift-ci please test |
|
@swift-ci please test source compatibility |
Replace the C++ implementation of #if condition operator folding, validation, and evaluation with the corresponding facilities in the SwiftIfConfig library. Leave the C++ implementation in place for now to permit the compiler to continue building without swift-syntax.
For the most part, the differences between the diagnostics introduced
by the C++ implementation and the new SwiftIfConfig implementation are
cosmetic, so these are only wording changes.
The one major difference is that we've dropped the warnings about
potential typos in os/arch checks. For example, if one writes:
#if os(bisionos)
// ...
#endif
The C++ implementation will produce a warning "unknown operating system
for build configuration 'os'" with a note asking "did you mean
'visionOS'"? These warnings rely on a static list of known operating
systems and architectures, which is somewhat unfortunate: the whole
point of these checks is that the Swift you're dealing with might not
have support for those operating systems/architectures, so while these
warnings can be helpful in a few cases, they also cause false
positives when porting. Therefore, I chose not to bring them forward.
We're not caching this now, but it lets us dodge annoying layering issues because ASTGen (where this is available) sits on top of the C++ parser, which needs to call it.
DougGregor
force-pushed
the
swiftifconfig-replace-cpp
branch
from
bcf1fe2 to
225e562
Compare
|
@swift-ci please test |
|
@swift-ci please test source compatibility |
Replace the C++ implementation of
#ifcondition operator folding, validation, and evaluation with the corresponding facilities in the SwiftIfConfig library. Leave the C++ implementation in place for now to permit the compiler to continue building without swift-syntax.There are a few differences in the diagnostics produced relative to the C++ implementation; the second commit shows the actual changes, all of which are benign or are improvements.