Fix a Source Break With Function Builders #32893
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@swift-ci smoke test |
|
Don't we also need some logic in CSGen to pick up the cached type? Otherwise we'll open a fresh type var disconnected from the rest of the system. Here's a test case that relies on them being connected: protocol P {}
extension String : P {}
@_functionBuilder
struct FooBuilder<T> {}
extension FooBuilder where T : P {
static func buildBlock(_ x: Int, _ y: Int) -> String { "" }
}
func foo<T : P>(@FooBuilder<T> fn: () -> T) {}
foo {
0
0
} |
xedin
reviewed
Jul 17, 2020
Before 09db290, the function builder transform used to try to detect when the builder type wasn't fully resolved. In such a case, rather than fail the solution set as we do currently, it would construct a null TypeLoc, then stash the type- variable-laden builder type inside of a TypeExpr and rely on CSGen to reinterpret that as a request to read the stashed type as it was constructing the rest of the system. This used to rely on the ability to construct an implicit TypeExpr node with a null type but now such a thing is banned by the TypeExpr interface. Instead, we have to detect this case and construct an *explicit* TypeExpr node pointing to all the usual fake data. This node's type will be used to resolve the build* member, but the final applied type of the node will be the builder type we stashed earlier - hopefully with outstanding type variables solved. rdar://65116204
|
@swift-ci smoke test |
xedin
approved these changes
Jul 17, 2020
|
@swift-ci smoke test macOS platform |
|
@swift-ci smoke test Windows |
|
⛵ |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Before 09db290, the function builder
transform used to try to detect when the builder type wasn't fully
resolved. In such a case, rather than fail the solution set as we do
currently, it would construct a null TypeLoc, then stash the type-
variable-laden builder type inside of a TypeExpr and rely on CSGen
to reinterpret that as a request to read the stashed type as it was
constructing the rest of the system. This used to rely on the ability to construct
an implicit TypeExpr node with a null type but now such a thing is
banned by the TypeExpr interface.
Instead, we have to detect this case and construct an explicit
TypeExpr node pointing to all the usual fake data. This node's type will
be used to resolve the build* member, but the final applied type of the
node will be the builder type we stashed earlier - hopefully with
outstanding type variables solved.
rdar://65116204, SR-13132