Add _mangledTypeName to allow round trips T->mangledName->T #30318
Conversation
|
@swift-ci smoke test |
|
Whoop, fixed the: |
|
@swift-ci smoke test |
1 similar comment
|
@swift-ci smoke test |
|
@swift-ci test |
|
Cool, thanks, my understanding is I should also run all tests -- doing so then :) |
|
Build failed |
|
Build failed |
|
Failure just on windows and does not seem related to this change. |
|
|
||
| return String._fromUTF8Repairing( | ||
| UnsafeBufferPointer(start: stringPtr, count: count)).0 | ||
| } |
There was a problem hiding this comment.
What do we want to do here if the input contains invalid UTF-8? It seems like our mangling should only produce ASCII, so you can use String._fromASCIIValidating which returns nil of non-ASCII, and trap in that scenario.
There was a problem hiding this comment.
CC @eeckstein @DougGregor @jckarter though to verify the ASCII-ness of mangled names for types with non-ASCII names
There was a problem hiding this comment.
CC @eeckstein @DougGregor @jckarter though to verify the ASCII-ness of mangled names for types with non-ASCII names
There was a problem hiding this comment.
Yes, that's the case. Non-ASCII characters in identifiers are encoded to ASCII with the Punycode algorithm.
There was a problem hiding this comment.
Punycode encoding is not used in all contexts; we also support disabling it for runtime mangled names, since we aren't constrained by linker limitations there. The mangled string should always be valid UTF-8.
There was a problem hiding this comment.
So... sounds like nothing to be done here then?
Anything else I can help to get this merged?
I would be happy to backport as well if possible (?), which branches should I target for "next" 5.1 / 5.2?
There was a problem hiding this comment.
This LGTM, but I would suggest adding a precondition that the repairsMade in the return value was false.
|
This looks ready to merge to me. @milseman Any other concerns before we merge this? |
|
LGTM, with a preference for a precondition that no repairs were made |
|
@swift-ci please test windows platform |
|
Ok let me have a look at the precondition then 👍 |
|
@swift-ci test |
|
Build failed |
|
Build failed |
This introduces a new _underscored function that allows to perform name mangling of types in-process. This can be used to perform round-trips from a type, to a mangled name, and back again.
This is useful in certain serialization scenarios, and just generally "completes the package" - since we can go from mangled names to Types, why not go the other way around in runtime as well.
cc @DougGregor @jckarter
cc @milseman in case there's something stdlib specific I should adjust here (naming, attributes etc)
While this does_ NOT_ address any of the API needs as discussed in SE-0262: Demangle function, it adds another piece to eventually complete the puzzle. I.e. perhaps in the future we can revise SE-262 to be about mangling in general, and then would also include this ability there?
This is out of scope of this PR and would be taken through the Swift Evolution process however.