We allow overloads on foo(() -> T) and foo(@auto_closure () -> T) in Sema, so they need distinct manglings. Fixes <rdar://problem/16045566>.
Swift SVN r13856
Implement the demangling for generic signatures and their requirements, dependent parameters, and member types, now that we actually use these manglings when naming reabstraction thunks.
Swift SVN r13764
This is mostly useful for the standard library, whose name is going to
change to "Swift" soon. (See <rdar://problem/15972383>.) But it's good DRY.
Swift SVN r13758
This time, be sure to reset the demangler state after demangling the
specialization header, because it is a prefix of the demangled symbol
name.
Swift SVN r13378
- Int and UInt are now struct types backed by Builtin.Word. Previously they
were typealiases for Int64; Int and Int64 are now distinct types.
- Mangled names 'i' and 'u' are now Int and UInt. Int64 is mangled longhand.
- Word is a typealias for Int. It is expected to go away in the future.
- Builtin.Word is unchanged.
- CLong and CUnsignedLong are typealiases for Int and UInt.
- FixedPoint.swift is now FixedPoint32.swift and FixedPoint64.swift.
Reunifying these requires better builtins, especially for checked
conversions (rdar://15472770).
- Updated many tests, mostly because Int is no longer spelled Int64 in sil.
- One check was removed from test decl/operator/operators.swift
because it changed behavior when Int became a non-typealias
type (rdar://15934688).
Swift SVN r13109
type, so we emit them. Add mangler (and demangler) support for these.
Enhance our testcase to check to make sure that stores within these
specifiers are direct, they don't cause recursive infinite loops.
John, I picked w/W for the mangling letters, let me know if this is ok.
Swift SVN r13050
When we're using Objective-C's memory allocation, emit .cxx_construct
methods whenever we have instance variables with in-class
initializers. Presently, these methods are just empty stubs.
Swift SVN r12211
The Objective-C runtime executes the .cxx_destruct method after the
last -dealloc has executed when destroying an object, allowing the
instance variables to remain live even after the subclass's
destructor/-dealloc has executed, which is important for memory
safety. This fixes the majority of <rdar://problem/15136592>.
Note that IRGenModule::getAddrOfIVarDestroyer() contains an egregious
hack to find the ivar destructor SIL function via a linear
search. We need a better way to find SIL functions that we know exist,
because LinkEntity does not suffice.
Swift SVN r12206
Revert "add a hackaround for rdar://15753317. I don't unerstand the code enough to tell if this is the right fix."
This reverts commit 416983b0734dde6979c98971948068c7a157e336.
Swift SVN r11942
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
decl context of the type alias.
This implements <rdar://problem/15290346> "typealias sugar needs to be
mangled into debug info mangled type names".
Swift SVN r10749
This "greedy" demangling should not be necessary anymore once <rdar://problem/15444866> goes in
As of now, this extension should help LLDB support generics in functions
Swift SVN r10493
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
- Change type attribute printing logic (in astprinter and the demangler)
to print in the new syntax
- Change the swift parser to only accept type attributes in the new syntax.
- Update canParseTypeTupleBody to lookahead over new-syntax type attributes.
- Update the testsuite to use the new syntax.
Swift SVN r9273
