Future-proof the mangling of invertible protocols #72692
Merged
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.
Invertible protocols are currently always mangled with
Ri
, followed by a single letter for each invertible protocol (e.g.,c
ande
forCopyable
andEscapable
, respectively), followed by the generic parameter index. However, this requires that we extend the mangling for any future invertible protocols, which mean they won't be backward compatible.Replace this mangling with one that mangles the bit # for the invertible protocol, e.g.,
Ri_
(followed by the generic parameter index) is bit 0, which isCopyable
.Ri0_
(then generic parameter index) is bit 1, which isEscapable
. This allows us to round-trip through mangled names for any invertible protocol, without any knowledge of what the invertible protocol is, providing forward compatibility. The same forward compatibility is present in all metadata and the runtime, allowing us to add more invertible protocols in the future without updating any of them, and also allowing backward compatibility.Only the demangling to human-readable strings maps the bit numbers back to their names, and there's a fallback printing with just the bit number when appropriate.
Also generalize the mangling a bit to allow for mangling of invertible requirements on associated types, e.g.,
S.Sequence: ~Copyable
. This is currently unsupported by the compiler or runtime, but that may change, and it was easy enough to finish off the mangling work for it.