Compatibility of the serialised AST

Development Compiler
1

To async deinit support I need to add a new field to the DestructorLayout. Can I insert it in the middle (after objc?, before GenericSignatureIDField) or it must be the last one for compatibility?

Serialization doc is confusing. It describes backward compatibility, but also, IIUC, says that currently there is not compatibility at all:

Today's Swift uses a "major" version number of 0 and an always-incrementing "minor" version number. Every change is treated as compatibility-breaking; the minor version must match exactly for the compiler to load the module.

I've tried to check few previous commits where SWIFTMODULE_VERSION_MINOR was bumped, and I don't see any code that would be taking care of backwards compatibility. Do llvm::BitstreamCursor and friends automatically handle backward compatibility? If so, how to they know which records are missing? Is there any control over default values? I could not find anything inside the LLVM sources myself.

Can you point me to an example of handling backwards compatibility?

2

You can make arbitrary changes if you bump the version; there is no functioning backwards compatibility of binary module files.

Edit: we were thinking about backwards compatibility when we brought up binary modules, but we eventually decided that a textual format was a much smarter way of achieving stability, which is why we introduced .swiftinterface files. There are definitely a few scattered legacies of those initial ideas still in the codebase.

4 Likes