[4.2] Start recovering from missing types in SIL deserialization #17591
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
…ly-idea Start recovering from missing types in SIL deserialization rdar://problem/40899824 (cherry picked from commit 747e318)
|
@swift-ci Please test |
|
@swift-ci Please nominate |
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.
Explanation: When mixing Swift language versions, entities from Objective-C can import very differently, or even vanish entirely. (Consider a library that uses an
NS_TYPED_ENUMtype in Swift 4.2, but then an app built with 4.0 comes along and sees the type as a plain typedef. The unique struct type is gone.) This affects both AST declarations and SIL entities, including functions that appear in a SIL witness table. This change adds a simple check for not being able to decode the type of the function; if that is the case, the entire function is ignored, as if it were dropped from the module.Scope: Changes the code used to deserialize all SILFunctions, but shouldn't actually change the happy-path behavior, only cases that would have crashed.
Issue: rdar://problem/40899824
Risk: Medium-low. This only changes the behavior of code the compiler would have crashed on, but if there are problems later on because of the recovery they'll be a little harder to track down.
Testing: Passed existing compiler regression tests, verified that original (reduced) project builds successfully.
Reviewed by: @slavapestov