[NFC] TypeCheckType No Longer Returns Null #32321
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
This method's only caller was using this to form a substituted DictionaryType, but also using TypeChecker::applyUnboundGenericArguments. We need to use the latter unconditionally so we actually check the requirements on DictionaryType and emit diagnostics. Also clean up resolveDictionaryType so it consistently returns ErrorTypes.
Directly return the parameter vector, and handle missing types the same way we handle error types.
Inline it into its only caller
Inline it into its only caller
|
@swift-ci smoke test |
|
@swift-ci test source compatibility |
slavapestov
approved these changes
Jun 11, 2020
| @@ -7,4 +7,4 @@ protocol P1 { | |||
| } | |||
| extension Foo: P1 where A : P1 {} // expected-error {{unsupported recursion for reference to associated type 'A' of type 'Foo<T>'}} | |||
| // expected-error@-1 {{type 'Foo<T>' does not conform to protocol 'P1'}} | |||
| // expected-error@-2 {{type 'Foo<T>' in conformance requirement does not refer to a generic parameter or associated type}} | |||
| // expected-error@-2 {{type '<<error type>>' in conformance requirement does not refer to a generic parameter or associated type}} | |||
There was a problem hiding this comment.
Looks like the result of a !ty -> ty->hasError() transition somewhere in TypeCheckType.cpp. The error message is bogus though, anyway..
There was a problem hiding this comment.
The second time we come around to add these requirements while computing the generic signature for the extension, the base is invalidated somewhere else in the stack. I think we should just not emit this diagnostic if the subject is an ErrorType - it doesn't make sense here in the first place.
|
Lost connection to macOS nodes @swift-ci smoke test macOS |
|
Release builder died. @swift-ci test source compatibility Release |
|
@swift-ci smoke test macOS |
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.
Make it structurally impossible for TypeCheckType to return the null type to both itself and its callers. A large amount of this is based on the work in #29780, but there's some additional deletions and structural assertions here.
Resolves SR-12085 and rdar://58879303