Leave the qualification off of enum cases and type names when 'print'-ing them, but keep them on 'debugPrint'. (At least, at the outermost level; since ad-hoc printing of structs and tuples uses debugPrint, we'll still get qualification at depth, which kind of sucks but needs more invasive state management in print to make possible.) Implements rdar://problem/21788604.
Swift SVN r30166
This enables dead argument elimination to be paired with @owned -> @guaranteed
optimization. It has the additional advantage of allowing us to potentially
eliminate additional retains, releases since the fact that the use is dead
implies that the lifetime of the value no longer needs to be live across the
function call.
Since dead argument elimination can be composed with @owned -> @guaranteed, I
had to modify the mangler, remangler, demangler, to be able to handle a mangling
that combines the two.
I just saw noise in the perf test suite.
rdar://21114206
Swift SVN r29966
Our hack to generate a unique name by appending the class pointer doesn't produce a stable class name that can persist in NSKeyedArchiver, or eventually be used as a key for dynamic runtime instantiation. Generate a proper mangled name for the class instance by building a demangling AST from the metadata nodes and feeding it into the remangler. Should fix rdar://problem/18884563, though I need to try using an archiver with a generic class to verify.
Swift SVN r29316
This changes things like Swift.Dictionary<Swift.Int, Swift.AnyObject> to Dictionary<Int, AnyObject>
It has been suggested that playgrounds would benefit from not showing the fully qualified name.
Playgrounds use the runtime demangler to obtain type names, and honestly, I do not see enough value in those qualifiers being printed out to justify hackery in PlaygroundLogger or separate demangling logic
Swift SVN r28997
To support UI applications displaying demangled names in a limited
amount of screen space, provide a new SwiftDemangle API and Demangler
option to do the following:
- Skip all module name prefixes when printing contexts
- Don't print implicit self/metatype parameters when printing
function types
Add a '-simplified' flag to swift-demangle to support testing at the
command line.
Swift SVN r28727
The __lldb_expr modules are special as in they are autogenerated by LLDB and meant to not be user-accessible, so showing them adds visual noise for no user benefit
I am open to the notion of adding a flag to swift-demangle to the same effect, but that seems much lower priority
Swift SVN r28195
demangling tree back into a mangled string.
Also, extend the demangling API in a few obvious
ways, and simplify testing for failure in the
node-returning APIs by having them simply return
null instead of a spurious Failure node.
Also, preserve slightly more information in the
demangling tree. The goal here is eventually to
always allow a perfect round-trip through the
demangler parse tree. This patch gets us close,
but we're not quite there yet.
Tests to follow.
Swift SVN r24473
Not NFC: changes some of the demangling tree schemata (in
interest of regularity and expressivity) and, incidentally,
improves support for initializer manglings.
The main schema change is that Path is now gone, and instead
the first child of an entity is its context. All contexts
are now labelled with their kind (variable/function/etc.)
rather than that being much more obscure or missing.
A secondary change is that the top-level node is now a
single node with the <global> and all its attributes as
children, rather than being weirdly sibling-linked.
Also, the representation has changed so that nodes link
only to their children, not to siblings or parents, which
means that it is no longer necessary to clone nodes when
replacing substitutions.
Finally, dump/print was brought in from swift-demangler
and made part of the core API for debugging purposes.
Swift SVN r11470
iVars of a given type should be unique by name and so in certain cases, their types will not actually add information to a consumer of the demangled string
This mode is mostly useful for LLDB. When searching for a field offset by name in a generic scenario, the search can succeed or fail depending on whether archetypes are
obtained through the Demangler ("A","B","C") or through the module (which will vend proper archetype names when poked the right way)
This mode removes that ambiguity
Swift SVN r10761
This checkin extends the Demangler to allow printing sugar on demangled types
Namely, it introduces a DemanglerOptions class with just one field SynthesizeSugarOnTypes which has the same functionality as PrintOptions::SynthesizeSugarOnTypes
This changes outputs like _TtGSqC5sugar7MyClass_ ---> swift.Optional<sugar.MyClass> into _TtGSqC5sugar7MyClass_ ---> sugar.MyClass?
By default this flag is false, so that existing clients of the Demangler API do not break
OTOH, the command-line tool swift-demangle flags sets the flag to true, unless the -no-sugar option is passed on the command-line
Test cases included
Swift SVN r9502
This is only useful for unique-identification uses of the mangler, like in SourceKit,
which has to deal with invalid code.
Since this is not related to ABI, we can change the encoding anytime we want.
Swift SVN r8557
This should allow declarations inside protocols to mangle successfully, which is needed by SourceKit to be able to use mangled names as unique decl identifiers. I'm also planning to use mangled protocol decls to name generic curry thunk symbols.
This only introduces a mangling for independent associated types. I think we will eventually want to mangle dependent associated types (such as T.AssocType for an archetype T : SomeProtocol) with a non-indexed mangling too, but this doesn't do that yet.
Swift SVN r8148
k = UncurriedFunctionType
k = UncurriedFunctionMetaType
k = Type
k = MetaType
to:
k = UncurriedFunctionType
k = MetaType
This should help Greg parse uncurried functions with greater ease
Swift SVN r7964
The previous implementation of the tree structure for the demangler had a bug in the low-level tree management code which caused the tree structure to diverge depending on whether
nodes were added as siblings or children. This checkin fixes the issue by making sure that the tree of nodes is kept coherent at all times.
Some adjustments are necessary to ensure the nodes were still generated properly and correctly turned into strings
Added a new test case
Swift SVN r7643
Previously, substitutions were treated as unstructured text chunks, but this was causing problems when using the demangler as a source of structured type information
This patch ensures that substitutions are properly stored as the type they represent for later semantic reconstruction
Swift SVN r7494
