Collected fixes from the 4.1 branch #14612
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
Member
DougGregor
commented
Feb 13, 2018
DougGregor
commented
- Weaken over-eager assertion in deserialization of generic parameters
- Tolerate missing generic environments better in the solver
- Make conformance access paths more robust
- Suppress conformance near-miss warnings within the type definition
…Params. An over-eager assertion in ModuleFile::maybeReadGenericParams() rejected deserialization into the context of a generic subscript for a generic parameter within one of its accessors. Weaken the assertion; the DeclContext of the generic parameter will be overwritten with the correct context later. Fixes rdar://problem/37408205. (cherry picked from commit ba8e86d)
Before matching witnesses, ensure that we have a valid signature, and be more tolerant of null generic environments by using the mapTypeIntoContext entry point meant to handle null. We haven't managed to get a decent reproducer for this, but it's happening often enough, and this change hardens the affected code paths. Should fix rdar://problem/37255982. (cherry picked from commit fd5d3af)
…atures. With specific type-checking interleavings in large projects, the generic signature builder for the generic signature of a protocol might not have been built from the requirement signature of the protocol, which would lead to malformed conformance access paths. Make this code path more robust by building a new generic signature builder when this happens. This is a stop-gap solution that is suitable for the Swift 4.1 branch; a better solution would be to re-canonicalize the generic signature builder itself somehow, but this carries more risk in the short term. Fixes rdar://problem/37335173. (cherry picked from commit 89bc3a6)
There are a number of things that can only be written within the main type definition (e.g., required initializers, stored properties), making it far more likely that we'll get false positives from the newly-introduced "near-miss" warnings for protocol conformances. Moreover, sometimes a number of protocol conformances are placed on the main type definition, increasing the potential for false positives. Suppress near-miss warnings for potential candidates when the protocol conformance is stated on the main type definition itself. Therefore, we only perform near-miss checking of non-@objc requirements when the conformance itself was declared on an extension, which is roughly the development style that near-miss warnings favor. Fixes rdar://problem/37283860. (cherry picked from commit 3883ff0)
|
@swift-ci please smoke test and merge |
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.