This is more resilient, since we want to be able to add more information behind the address point of type objects, and also makes IR a lot less cluttered. The start of the metadata object is now an internal "full metadata" symbol.
Note that we can't do this for known opaque metadata from the C++ runtime, since clang doesn't have a good way to emit offset symbol aliases, so for non-nominal metadata objects we still emit an adjustment inline.
Swift SVN r31515
Specifically, "Ref", "Ptr", and dimensionality suffixes (1D, 2D, 3D)
in the type name should not prevent us from finding redundancy in type
information.
Swift SVN r31428
Sink the actual logic for omitting needless words way down into
Basic, so we can re-use it elsewhere. Tie the Clang importer into that
logic, mapping Clang types down to strings appropriately. NFC
Swift SVN r31233
This way they can be used from other projects, like LLDB. The downside
is we now have to make sure the header is included consistently in all
the places we care about, but I think in practice that won't be a problem,
especially not with tests.
rdar://problem/22240127
Swift SVN r31173
The demangler recently regressed to not printing any context
names, including nominal type contexts. This means that symbols
like Optional.init where only printed as init. Continue printing
contexts but not modules (per the original simplified demangling
design).
rdar://problem/19312992
Swift SVN r31066
Break up "Simplified" demangling mode (shortened demangled descriptions
for the sake of displaying in UI with small areas) into more
fine-grained options instead of an opaque "Simplified" option and
provide a static preset of options for displaying stack traces in
Xcode UI and other tools, for example.
- Don't print unmangled suffixes
- Don't print module names
- Shorten various generic specialization descriptions as just
"specialized"
- Don't display long protocol conformances
- Truncate where clauses
- Don't display so-called "entity" types
- Shorten "partial apply *"
- Shorten thunk phrases
- Shorten value witness phrases
- Truncate archetype references
rdar://problem/21753651
Swift SVN r30247
These will be used for reflection, and eventually to speed up generic
operations on single payload enums as well.
Progress on <rdar://problem/21739870>.
Swift SVN r30214
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
Constrained and protocol extensions should always include the extension context in their mangling, since they are never equivalent to definitions in the original type context. Have them use the extension mangling, and include the generic signature of the extension in its mangling, which is necessary to disambiguate properties and other definitions that are defined with the same name and type in differently constrained extensions. Fixes rdar://problem/21027215.
Swift SVN r29209
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
We already do for the iOS simulator and the tvOS simulator. This fixes
the 'unrecognized selector sent to instance’ bridging crashes in the stdlib
watch simulator tests.
Greg Parker did the hard work of tracking this down and suggested the fix.
<rdar://problem/20932146>
Swift SVN r28846
As part of this, I've made the demangler base the colon-vs.-not
decision on the entity kind instead of assuming that anything
with a function type must be a function. It also looks through
new-style generics when it didn't before.
Swift SVN r28814
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
Mangle the generic signature and interface type of the conforming type signature. Fix the demangler to reset the generic context between mangling a witness's conformance and requirement; they have independent generic contexts, and the bookkeeping for generic signatures notes the discrepancy.
Swift SVN r28377
Share the logic we use to map archetype depth-index pairs to friendly unique names like 'A', 'B', so that demangle generic signatures are still somewhat readable, and so that archetype references into outer contexts with interface type manglings still make sense. Change the remangler to mangle archetypes and dependent generic params using nested index nodes instead of trying to parse the depth and index from the arbitrary names we give them.
Swift SVN r28343
Single generic parameters are common, as are a lack of requirements, so tweak things so that generic parameter counts are mangled as (count - 1), with a special mangling for zero, and give a single generic parameter at depth zero the empty-string mangling. Most requirements are protocol constraints, so use a better mangling for them that doesn't require the 'P..._' wrapping of the general type mangling. On the other hand, dependent member types ought to mangle in the protocol of the associated type, which adds some length, but isn't too bad since the protocol will almost definitely have a substitution introduced by a preceding protocol constraint.
Swift SVN r28296
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
Equivalent to llvm::sys::fs::rename, except that if the destination file
exists and has the same contents as the source file, the source file is
simply deleted and the destination file is not touched.
Used in next commit.
Swift SVN r28041
Keep track of a second set of "direct method reference" curry thunks that don't end in a dynamic dispatch in order to properly implement a partial application such as 'let foo = super.foo'. Fixes rdar://problem/20598526.
Swift SVN r27538
To use members of protocol extensions on existential types, we
introduce an OpenExistentialExpr expression to open up the existential
type (into a local archetype) and perform the operations on that local
archetype.
Unlike with uses of initializers or dynamic-Self-producing
methods of protocols, which produce similar ASTs, we have the type
checker perform the "open" operation and then track it through
constraint application. This scheme is better (because it's more
direct), but it's still using a simplistic approach to deciding where
the actual OpenExistentialExpr goes that needs improvement.
Swift SVN r26964
- Add frontend and standard library build support for tvOS.
- Add frontend support for watchOS.
watchOS standard library builds are still disabled during SDK bring-up.
To build for TVOS, specify --tvos to build-script.
To build for watchOS, specify --watchos to build-script (not yet supported).
This patch does not include turning on full tests for TVOS or watchOS, and
will be included in a follow-up patch.
Swift SVN r26278
The deallocating parameter convention is a new convention put on a
non-trivial parameter if the caller function guarantees to the callee
that the parameter has the deallocating bit set in its object header.
This means that retains and releases do not need to be emitted on these
parameters even though they are non-trivial. This helps to solve a bug
in +0 self and makes it trivial for the optimizer to perform
optimizations based on this property.
It is not emitted yet by SILGen and will only be put on the self
argument of Deallocator functions.
Swift SVN r26179
Clang does this in the driver. Why not Swift? Because (a) this is an
implementation detail that really only affects IRGen, and even then
somewhat incorrectly, and (b) Swift has a good handful of clients that
don't go through the driver to create an ASTContext (specifically, LLDB,
along with many of our testing tools).
rdar://problem/19779274
Swift SVN r25909
This lets us disambiguate the symbols for static and instance properties, and enables us to eventually leave the useless "self" type mangling out of method symbols. Fixes rdar://19012022 and dupes thereof, including crasher #1341.
Swift SVN r25111
If a subclass overrides methods with variance in the optionality of non-class-type members, emit a thunk to handle wrapping more optional parameters or results and force-unwrapping any IUO parameters made non-optional in the derived. For this to be useful, we need IRGen to finally pay attention to SILVTables, but this is a step on the way to fixing rdar://problem/19321484.
Swift SVN r24705
