LLDB would like to substitute the original Archetype names from the
source code when demangling symbols instead of the confusing generic
'A', 'B', ...
<rdar://problem/48259889>
The demangler can be initialized with a preallocated memory on the stack. Only in case of an overflow, the bump pointer allocator mallocs new memory.
Also, support that a new instance of a demangler can "borrow" the free memory from an existing demangler. This is useful because in the runtime the demangler is invoked recursively. With this feature, all the nested demanglers can share a single stack allocated space.
This is done by disallowing nodes with children to also have index or text payloads.
In some cases those payloads were not needed anyway, because the information can be derived later.
In other cases the fix was to insert an additional child node with the index/text payload.
Also, implement single or double children as "inline" children, which avoids needing a separate node vector for children.
All this reduces the needed size for node trees by over 2x.
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
Extending the mangling of symbolic references to also include indirect
symbolic references. This allows mangled names to refer to context
descriptors (both type and protocol) not in the current source file.
For now, only permit indirect symbolic references within the current module,
because remote mirrors (among other things) is unable to handle relocations.
Co-authored-by: Joe Groff <jgroff@apple.com>
This function can be queried to find out whether the passed
mangled name is an Objective-C symbol. This will be used
in the debugger to replace an hardcoded check that would
break if the mangling prefix changed.
<rdar://problem/44467875>
Previously we could only handle symbolic references at the
top level, but this is insufficient; for example, you can
have a nested type X.Y where X is defined in the current
translation unit and Y is defined in an extension of X in
a different translation unit. In this case, X.Y mangles as
a tree where the child contains a symbolic reference to X.
Handle this by adding a new form of Demangle::mangleNode()
which takes a callback for resolving symbolic references.
Fixes <rdar://problem/39613190>.
And use them in the reflection library (TypeRef). These were
private to `TypeRef.cpp` but can be moved to the demangler as
they can be of general use, and we can use them from lldb (which
has homemade versions of the functions as well). Bonus point,
it probably makes sense for these helpers to live in the demangler
anyway.
<rdar://problem/37710513>
This makes resolving mangled names to nominal types in the same module more efficient, and for eventual secrecy improvements, also allows types in the same module to be referenced from mangled typerefs without encoding any source-level name information about them.
This particular API can be safely used with a null-terminated string,
and is used by some clients (e.g., LLDB), so add back a "const char *"
variant that safely accesses a null-terminated string.
The mangled name of protocol descriptors was the “protocol composition”
type consisting of a single protocol, which is a little odd. Instead,
use a bare protocol reference (e.g., “6Module5ProtoP”) with the “$S”
prefer to be more in line with nominal type descriptor names while still
making it clear that this is a Swift (not an Objective-C) protocol.
isMangledName() was passing the data() pointer to a routine that assumed
it was getting a null-terminated string. Define away this class of error
by using StringRef consistently.
Make function mangling backward compatible based on the prefix
of the mangled symbol, which is used to distinguish between names
with old/new parameter label mangling schemes.
Resolves: rdar://problem/36357120
As it’s not clear if we will need underscores, the demangler accepts $S and _$S.
Note that a double underscore is handled by the demangler client.
rdar://problem/32251811
The goal here is to make the short demangling as short and readable as possible, also at the cost of omitting some information.
The assumption is that whenever the short demangling is displayed, there is a way for the user to also get the full demangled name if needed.
*) omit <where ...> because it does not give useful information anyway
Deserializer.deserialize<A where ...> () throws -> [A]
--> Deserializer.deserialize<A> () throws -> [A]
*) for multiple specialized functions only emit a single “specialized”
specialized specialized Constructible.create(A.Element) -> Constructible<A>
--> specialized Constructible.create(A.Element) -> Constructible<A>
*) Don’t print function argument types:
foo(Int, Double, named: Int)
--> foo(_:_:named:)
This is a trade-off, because it can lead to ambiguity if there are overloads with different types.
*) make contexts of closures, local functions, etc. more readable by using “<a> in <b>” syntax
This is also done for the full and not only for the simplified demangling.
Renderer.(renderInlines([Inline]) -> String).(closure #1)
--> closure #1 in Renderer.renderInlines
*) change spacing, so that it matches our coding style:
foo <A> (x : A)
--> foo<A>(x: A)
Previously it was part of swiftBasic.
The demangler library does not depend on llvm (except some header-only utilities like StringRef). Putting it into its own library makes sure that no llvm stuff will be linked into clients which use the demangler library.
This change also contains other refactoring, like moving demangler code into different files. This makes it easier to remove the old demangler from the runtime library when we switch to the new symbol mangling.
Also in this commit: remove some unused API functions from the demangler Context.
fixes rdar://problem/30503344
