[Serialization] Fast lookup of nested types in modules with overlays #20024
Conversation
Previously, the fast path for nested types only worked when the nested type was defined in a Swift module or a Clang module without an overlay; this is because it was originally designed to fix circularity issues when merging partial modules for a single target. By having a Swift overlay module pass through requests for nested types to the underlying Clang module, we get the fast-path behavior in more cases. (The one case where it /won't/ kick in is if the overlay has a nested type that shadows a nested type from the Clang module, but that's probably pretty rare!)
|
@swift-ci Please test |
|
@swift-ci Please test compiler performance |
|
I did this hoping it would get past SR-9066, but no luck. It's still an improvement, though. |
| importedFromClang, /*isStatic*/false, /*ctorInit*/None, | ||
| singleValueBuffer); | ||
| if (!singleValueBuffer.empty()) { | ||
| values.assign({nestedType}); |
There was a problem hiding this comment.
Just curious, why assign a 1-element initializer list vs. calling push_back?
There was a problem hiding this comment.
A serialization cross-reference is a chain of nested names; when resolving component N, values contains the results from resolving component N-1.* So here we're saying we've resolved component N to a single result, and are replacing the results from component N-1.
* It's not always actually the immediately previous component; it's the previous component that represents a type. But, close enough.
|
Build failed |
|
!!! Couldn't read commit file !!! |
|
@swift-ci Please test macOS |
|
@swift-ci Please smoke test compiler performance |
…wiftlang#20024) Previously, the fast path for nested types only worked when the nested type was defined in a Swift module or a Clang module without an overlay; this is because it was originally designed to fix circularity issues when merging partial modules for a single target. By having a Swift overlay module pass through requests for nested types to the underlying Clang module, we get the fast-path behavior in more cases. (The one case where it /won't/ kick in is if the overlay has a nested type that shadows a nested type from the Clang module, but that's probably pretty rare!)
Previously, the fast path for nested types only worked when the nested type was defined in a Swift module or a Clang module without an overlay; this is because it was originally designed to fix circularity issues when merging partial modules for a single target. By having a Swift overlay module pass through requests for nested types to the underlying Clang module, we get the fast-path behavior in more cases. (The one case where it won't kick in is if the overlay has a nested type that shadows a nested type from the Clang module, but that's probably pretty rare!)