tree: b7fbac8d8ea084c262a9cd111df5df3b197734d1 [path history] [tgz]
  1. Inputs/
  2. README.md
  3. test_change_default_argument_to_magic.swift
  4. test_class_add_override.swift
  5. test_class_add_property.swift
  6. test_class_add_property_subclass.swift
  7. test_class_add_virtual_method.swift
  8. test_class_add_virtual_method_subclass.swift
  9. test_class_change_size.swift
  10. test_class_change_stored_to_computed.swift
  11. test_class_insert_superclass.swift
  12. test_class_remove_property.swift
  13. test_enum_add_cases.swift
  14. test_enum_add_cases_trap.swift
  15. test_enum_change_size.swift
  16. test_enum_reorder_cases.swift
  17. test_function_change_transparent_body.swift
  18. test_generic_resilient_struct_add_property.swift
  19. test_global_change_size.swift
  20. test_global_stored_to_computed.swift
  21. test_protocol_add_requirements.swift
  22. test_protocol_reorder_requirements.swift
  23. test_rth.swift
  24. test_struct_add_initializer.swift
  25. test_struct_add_property.swift
  26. test_struct_change_size.swift
  27. test_struct_change_stored_to_computed.swift
  28. test_struct_change_stored_to_computed_static.swift
  29. test_struct_fixed_layout_add_conformance.swift
  30. test_struct_fixed_layout_remove_conformance.swift
  31. test_struct_remove_property.swift
  32. test_struct_resilient_add_conformance.swift
  33. test_struct_resilient_remove_conformance.swift
  34. test_struct_static_stored_to_computed.swift
  35. test_superclass_methods.swift
  36. test_superclass_properties.swift
validation-test/Evolution/README.md

Resilient Library Evolution Tests

This directory tests for the correctness of resilience, which is a broad term for Swift maximizing binary compatibility of a dependency while maintaining the freedom to do things that would normally break clients in other languages, such as changing the layout of nominal types. The detailed explanation of resilience is out of scope of this little readme and can be found in docs/LibraryEvolution.rst.

Each main test file should compile against “before” and “after” versions of the corresponding library file. The old and new versions are selected via the BEFORE or AFTER preprocessor variables.

In the library, going from BEFORE to AFTER must be an ABI-compatible change, as documented in the library evolution specification.

In the main program, going from BEFORE to AFTER does not have to be backward compatible.

In the main file, use your test library's getVersion helper function to know which version of the library to expect at runtime.

There are four valid combinations for each test:

  1. Main file compiled against old library, linked against old library a.k.a. “before before”
  2. Main file compiled against old library, linked against new library, a.k.a. “before after”
  3. Main file compiled against new library, linked against old library, a.k.a. “after before”
  4. Main file compiled against new library, linked against new library, a.k.a. “after after”

The version of the library available at compile time determines which serialized declarations and transparent function bodies are visible.

When adding a new test, see the boilerplate at the top of each file for the general pattern for this kind of test. Use the StdlibUnittest library for assertions.