Lazier type checking of lazy vars #9916
Merged
Conversation
This file contains 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
This introduces a new TypeCheckExprFlags::SkipApplyingSolution flag, and a ExprTypeCheckListener::foundSolution() that is invoked before the solution is applied. While the existing getTypeOfExpressionWithoutApplying() method is similar, it's tailored for diagnostics and has some hacks in it. It should be refactored to use the new mechanism I added.
|
@swift-ci Please smoke test |
Record the initializer type as soon as we have a solution, before it is applied, and get the type from the constriant system instead of from the final type checked expression. Note that the coerceToMaterializable() was unnecessary, since we always coerce the value to an rvalue type with coerceToType(). Eventually coerceToMaterializable() should go away. This is mostly NFC, except using the result of simplifyType() rather than the type of the final expression changes some diagnostics where it appears we were previously losing sugar. Also this accidentally fixes a crasher. Unfortunately the underlying issue is still there (applying a solution has bugs with opened existentials "leaking" out) -- this merely masks the problem by getting the initializer type directly from the constriant system.
If a lazy var has no declared type, we have to type check the initializer to get a type before we can build the getter. Then, the initializer is type checked as part of the getter again. Use the new SkipApplyingSolution flag when type checking for the first time. We still end up doing redundant work, but by not applying the solution we avoid feeding invalid AST nodes back into the constraint solver. This fixes some bad diagnostics and crashes. Fixes <https://bugs.swift.org/browse/SR-2616> and <rdar://problem/28313602>.
slavapestov
force-pushed
the
lazier-type-checking-of-lazy-vars
branch
from
a76555b
to
d8234ba
Compare
|
@swift-ci Please smoke test |
rudkx
approved these changes
May 25, 2017
| @@ -129,15 +129,15 @@ func defaultToAny(i: Int, s: String) { | |||
|
|
|||
| let a2: Array = [1, "a", 3.5] | |||
| // expected-error@-1{{heterogeneous collection literal could only be inferred to '[Any]'; add explicit type annotation if this is intentional}} | |||
| let _: Int = a2 // expected-error{{value of type '[Any]'}} | |||
| let _: Int = a2 // expected-error{{value of type 'Array<Any>'}} | |||
There was a problem hiding this comment.
Most of the diagnostics changes here seem like improvements, but not this and the one below. Any idea why?
There was a problem hiding this comment.
It's because we declare 'let a2: Array', so we're only inferring generic arguments here and not the whole type.
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.
Fixes https://bugs.swift.org/browse/SR-2616.
rdar://problem/28313602
rdar://problem/21669808