When the start of a name describes both the type of the context and
the type of the result, and is followed by a preposition, the start of
the name is redundant with the 'self' value, so strip it off. For
example:
url.URLWithHTTPS
becomes
url.withHTTPS
Swift SVN r31701
When the prefix of a method/property name is restating the result
type, followed by "By" and then a gerund, drop everything up to the
gerund. For example:
func stringByAppendingString(string: String) -> String
becomes
func appending(string: String) -> String
Swift SVN r31683
When the type name we're looking at is a collection of some element
type, also try to match the plural form of the element type name. For
example:
- func deselectItemsAtIndexPaths(_: Set<NSIndexPath>)
+ func deselectItemsAt(_: Set<NSIndexPath>)
Swift SVN r31666
Identify gerunds by stripping off the "ing" and looking for a
verb. This lets us transform, e.g., "stringByAppendingString" to
"stringByAppending", since "append" is a verb.
Swift SVN r31660
The presence of a verb or preposition prior to the redundant part
provides a firm linguistic split that lets the actual argument fill in
for the reader. For other parts of speech (adjectives, especially)
it's awkward to transition from "reading part of the name" to "reading
the argument". This eliminates a significant number of bad omissions,
e.g., "setTextColor()" -> "setText()", and generally makes the
transformation more conservative.
Swift SVN r31656
"With" tends to have value in separating the verb of the base of a
method name from the description of the first argument. The poster
child here is "copyWithZone", where "copy(_:)" makes it sound like
we're copying the argument. We're considering a more nuanced rule that
can drop "With" in cases where it's not separating a verb from a
description of the argument; that will follow if we do come across
such a result.
Swift SVN r31627
While there are cases where it makes sense to drop the first argument
label in initializers---when they're primarily conversions---it's an
heuristic that produces poor results (e.g., init(_:) rather than
init(coder:)) more often than not. Thus, remove this heuristic.
Swift SVN r31626
We want to see the results of the omit-needless-words heuristics under
the assumption that we won't need to quote these argument labels in
the future, and it avoids some head-scratching to not have this
heuristic in place.
Swift SVN r31625
This is more resilient, since we want to be able to add more information behind the address point of type objects. 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. We also aren't able to generate references to aliases within the same module due to an MC bug with alias refs on i386 and armv7 (rdar://problem/22450593).
Swift SVN r31523
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
