[3.1] Improve compile-time performance of string interpolation #7146
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
Remove 16 concrete init(stringInterpolationSegment:) overloads and replace them with 3 generic overloads, significantly reducing the exponential blow-up from larger string interpolations. Fixes rdar://problem/29389887. (cherry picked from commit f6cac54)
…eholders. The type checker introduces fresh type variables for editor placeholders that are encountered in the source. If there are many such editor placeholders, we'll create a large number of type variables with very little context, which can cause poor scaling in the type checker. Since we get very little information out of these type variables, artificially limit the number of type variables we create (to 2) and rotate through them. Another piece of rdar://problem/29389887. (cherry picked from commit 207fffc)
…rals. Constraint generation for interpolated string literals was meticulously producing a constraint system that included all of the generated calls to init(stringInterpolationSegment:). While accurate, this is completely unnecessary (because the ExpressibleByStringInterpolation protocol allows *anything* to be interpolated) and leads to large, intertwined constraint systems where: (1) There are two additional type variables per string interpolation segment, and (2) Those type variables form a bridge between the string interpolation's type variable and the type variables of each string interpolation segment, and (3) init(stringInterpolationSegment:) tends to be overloaded (4 overloads, down from 17 due to 2935301) which left each string interpolation as a large connected component with big disjunctions. Drop the calls to init(stringInterpolationSegment:) from the constraint system. This eliminates two type variables per segment (due to (1) going away), and breaks the bridge described in (2), so that each string interpolation segment is treated as an separate connected component and, therefore, will be solved independently. The actual resolution of init(stringInterpolationSegment:) overloads is pushed to the constraint application phase, where we are only dealing with concrete types and *much* smaller constraint systems. Fixes rdar://problem/29389887 more thoroughly. (cherry picked from commit 21ee10b)
…ement. NFC; the prior commit eliminated all uses of this locator path element. (cherry picked from commit 4127f70)
|
@swift-ci please test |
|
Build failed |
|
Stack trace printing failed? Weird. |
|
@swift-ci please test Linux |
|
Build failed |
|
@swift-ci please test Linux |
|
Build failed |
|
We need a 3.1 cherry-pick of apple/swift-lldb@dbb730e for this to work |
|
@swift-ci please test Linux |
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.
Constraint generation for interpolated string literals was
meticulously producing a constraint system that included all of the
generated calls to
init(stringInterpolationSegment:). While accurate,this is completely unnecessary (because the
ExpressibleByStringInterpolationprotocol allows anything to beinterpolated) and leads to large, intertwined constraint systems
where:
(1) There are two additional type variables per string interpolation
segment, and
(2) Those type variables form a bridge between the string
interpolation's type variable and the type variables of each string
interpolation segment, and
(3)
init(stringInterpolationSegment:)tends to be overloaded (17 overloads onString!)which left each string interpolation as a large connected component
with big disjunctions.
Drop the calls to
init(stringInterpolationSegment:)from theconstraint system. This eliminates two type
variables per segment (due to (1) going away), and breaks the bridge
described in (2), so that each string interpolation segment is
treated as an separate connected component and, therefore, will be
solved independently. The actual resolution of
init(stringInterpolationSegment:)overloads is pushed to theconstraint application phase, where we are only dealing with concrete
types and much smaller constraint systems. Still, eliminate 16 concrete-type overloads of
String.init(stringInterpolationSegment:)in favor of 3 generic ones.Fixes rdar://problem/29389887.