Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-4926] Make deserialization recovery more lenient for indirect cases of enums. #47503

Open
belkadan opened this issue May 18, 2017 · 0 comments
Labels
compiler The Swift compiler in itself improvement serialization Area → compiler: Serialization & deserialization

Comments

@belkadan
Copy link
Contributor

Previous ID SR-4926
Radar None
Original Reporter @belkadan
Type Improvement
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Improvement, Serialization
Assignee None
Priority Medium

md5: f769a07dfa816f6c4f9896c6973ef85d

Issue Description:

#9720 made it so that if any case in an enum can't be deserialized, the entire enum can't be deserialized. This is because the layout of enum cases and their payloads affects the layout of the entire enum.

However, there is a special case here (pun intended): indirect cases. These have a statically-knowable layout because they are indirect, and therefore can be dropped from the enum's public interface without affecting the other cases. This would entail:

  1. Skipping indirect cases when collecting "dependency types" for the enum (Serialization.cpp).

  2. Adding a field to the serialization format for enum elements to track dependency types (ModuleFormat.h). (This is tricky because the format we're using doesn't allow both a "blob" and an "array". We'll probably need a separate record kind whose only job it is is to hold dependencies.)

  3. Collect dependency types for indirect enum elements. (Don't bother for normal elements.) (Serialization.cpp)

  4. …then copy the dependency-type-checking logic from enums… (Deserialization.cpp)

  5. …but instead of returning an error, just pretend the associated type is Any… (Deserialization.cpp)

  6. …and mark the case unavailable using AvailableAttr. (Deserialization.cpp)

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler The Swift compiler in itself improvement serialization Area → compiler: Serialization & deserialization
Projects
None yet
Development

No branches or pull requests

1 participant