-
Notifications
You must be signed in to change notification settings - Fork 10.3k
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
DynamicCast Rework, Part 1: Specification #33010
DynamicCast Rework, Part 1: Specification #33010
Conversation
@tbkka had a thought. While this document is awesome I am worried about divergences. Really whatever behavior is specified here should have an associated test that validates this. I almost imagine that we could have a sub-folder of lit tests just for this spec. I am imagining that we would want anything that is specified to have an explicit link to the test that validates that an implementation obeys this spec. Take it or leave it = ). |
A test suite is in the works. |
@tbkka nice! The dream I was imagining inline links to the individual test cases. Thanks so much for your attention to detail here! = ). |
02e5922
to
6a5a8c2
Compare
6a5a8c2
to
5ba1827
Compare
@swift-ci Please smoke test |
This validation test exercises a large matrix of types and invariants for dynamic casting. It's formulated as a Python script that emits a number of Swift test programs, compiles, and executes them. The programs are compiled in Swift 4 and 5 mode, with -O and -Onone. The invariants used by these tests follow the specification presented in PR swiftlang#33010. It should be easy to add more as desired. I've tried to design this in such a way that CI logs can provide enough information to narrowly identify the problem area: Separate test cases are generated for each invariant and each type (in particular, this helps with compiler crashes that report the full body of the function in question). The files and test suites are named to identify the optimization mode. The goal of this test suite is to cover a broad cross-section of casting capabilities and combinations, and to make it easy to expand the matrix of combinations. New invariants can easily be added and applied to many types; as new types are added to this test, they can exploit the existing invariants and be exercised across all optimization modes.
This validation test exercises a large matrix of types and invariants for dynamic casting. It's formulated as a Python script that emits a number of Swift test programs, compiles, and executes them. The programs are compiled in Swift 4 and 5 mode, with -O and -Onone. The invariants used by these tests follow the specification presented in PR swiftlang#33010. It should be easy to add more as desired. I've tried to design this in such a way that CI logs can provide enough information to narrowly identify the problem area: Separate test cases are generated for each invariant and each type (in particular, this helps with compiler crashes that report the full body of the function in question). The files and test suites are named to identify the optimization mode. The goal of this test suite is to cover a broad cross-section of casting capabilities and combinations, and to make it easy to expand the matrix of combinations. New invariants can easily be added and applied to many types; as new types are added to this test, they can exploit the existing invariants and be exercised across all optimization modes.
This is the proposed specification for dynamic casting, which has been under development as part of PR #29658
Splitting this out so it can be reviewed and merged separately from the implementation.