Demangler: handle errors in demangleType
#74767
Conversation
|
@swift-ci test |
eeckstein
force-pushed
the
demangle-type-error-handling
branch
2 times, most recently
from
ee43266 to
5a0faf4
Compare
|
@swift-ci test |
eeckstein
force-pushed
the
demangle-type-error-handling
branch
from
5a0faf4 to
50d2531
Compare
|
@swift-ci test |
|
@swift-ci test macos |
|
|
||
| return createNode(Node::Kind::Suffix, Text); | ||
| return Result; |
There was a problem hiding this comment.
Is there harm to keeping the Suffix production? The runtime demangler should never accept it as a valid mangling, but it's helpful when demangling generated symbol names in binaries. Could it be kept as an option?
There was a problem hiding this comment.
Yeah, it can also be helpful when debugging mangling errors, since it generally points at exactly what you messed up.
There was a problem hiding this comment.
This change only affects demangleType (the runtime demangler). Nothing changes for demangling symbols
There was a problem hiding this comment.
debugging mangling errors
Pro tip: Demangler::dump() prints the internal state of the demangler which is very useful for debugging mangling problems
Makes sure that invalid runtime type strings result in errors and not fail silently. In worst case this could lead to wrong reconstructed metatypes which can result in all kind of memory corruption. relates to rdar://129861211
The motivation for this is to test the `Demangler::demangleType` API.
eeckstein
force-pushed
the
demangle-type-error-handling
branch
from
50d2531 to
b9cb593
Compare
|
@swift-ci test |
Makes sure that invalid runtime type strings result in errors and not fail silently.
In worst case this could lead to wrong reconstructed metatypes which can result in all kind of memory corruption.
Also add an option
-typeto the swift-demangle tool to testdemangleTyperelates to rdar://129861211