Currently when function types like `(_: Int...) -> Void` are mangled
their names are going to include enclosing sugar BoundGenericType(Array),
which is not necessary and doesn’t play well with `AnyFunctionType::Param`
which strips the sugar away.
Resolves: rdar://problem/34941557
Rather than mangling the complete generic signature of a constrained
extension, only mangle the requirements not already satisfied by the
nominal type. For example, given:
extension Dictionary where Value: Equatable {
// OLD: _T0s10DictionaryV2t3s8HashableRzs9EquatableR_r0_lE3baryyF
// NEW: _T0s10DictionaryV2t3s9EquatableR_rlE3baryyF
public func bar() { }
}
In the existing mangling, we mangle the `Key: Hashable` requirement that’s
part of the generic signature. With this change, we only mangle the new
requirement (`Value: Equatable`).
This is a win for constrained extensions *except* in the case of a
constrained extension of a nominal type with a single, unconstrained
generic parameter:
extension Array where Element: Equatable {
// OLD: _T0Sa2t3s9EquatableRzlE3baryyF
// NEW would be: _T0Sa2t3s9EquatableRzrlE3baryyF
public func bar() { }
}
Check explicily for this shortcut mangling and fall back to the old
path, so this change is a strict improvement.
This patch allows Parser to generate a refined token stream to satisfy tooling's need. For syntax coloring, token stream from lexer is insufficient because (1) we have contextual keywords like get and set; (2) we may allow keywords to be used as argument labels and names; and (3) we need to split tokens like "==<". In this patch, these refinements are directly fulfilled through parsing without additional heuristics. The refined token vector is optionally saved in SourceFile instance.
...which didn't do the right thing in the presence of ModuleMacro,
depending on the order the macros were referenced. Already covered by
test/ClangImporter/macros.swift, but it actually seems to improve the
behavior of some of the SourceKit tests as well.
Continuing rdar://problem/32199805, which is just "get macros working
with clang::ModuleMacro".
- Deinitializers never get a custom Objective-C name.
- Classes and protocols are never bridged themselves; that only matters
for structs and enums.
This avoids another circularity issue like the one in a8bc132565,
where the Clang importer ends up importing a class and hands it to the
type checker, which then asks about conformances. The conformance
lookup table goes to add the extension from the Swift module, except
that the Swift module is what asked for the import in the first place.
It's possible there's a more general solution here, but this
particular change is good even in the non-crashy cases, and definitely
safe for Swift 4.0. Even if the test case is even more idiosyncratic
than the last one.
The test case change for SourceKit is probably due to the first
category not triggering the import of the other two
categories. Changes in import order have been known to affect source
compatibility, though not frequently. However, categories are not
intended to be ordered in the first place. There's still more we can
do in this space, and implicitly depending on these calls /outside/ of
the importer to control category import order was quite brittle
anyway.
SR-5330 / rdar://problem/32677610
This reverts commit 25985cb764. For now,
we're trying to avoid spurious non-structural changes to the mangling,
so that the /old/ mangling doesn't appear to change. That doesn't mean
no changes at all, but we can save this one for later.
- Allow them to use substitutions.
- Consistently use 'a' as a mangling operator.
- For generic typealiases, include the alias as context for any generic
parameters.
Typealiases don't show up in symbol names, which always refer to
canonical types, but they are mangled for debug info and for USRs
(unique identifiers used by SourceKit), so it's good to get this
right.
cfe9e6a3de removed calls to pre/post
printing of PrintStructureKind::GenericRequirement, so SourceKit DocInfo
requests started droping the markers for generic requirements, causing
some weirdness with documentation rendering and post-processing.
Restore the calls to printStructPre/Post when printing generic
requirements.
rdar://problem/30561880
In the following example, the two declarations should have
the same mangled type:
protocol P {
associatedtype P
}
func f1<T : P>(_: T) -> T.P where T.P == Int {}
func f2<T : P>(_: T) -> Int where T.P == Int {}
To ensure this is the case, canonicalize the entire
GenericFunctionType before taking it apart, instead of
canonicalizing structural components of it.
Introduce an algorithm to canonicalize and minimize same-type
constraints. The algorithm itself computes the equivalence classes
that would exist if all explicitly-provided same-type constraints are
ignored, and then forms a minimal, canonical set of explicit same-type
constraints to reform the actual equivalence class known to the type
checker. This should eliminate a number of problems we've seen with
inconsistently-chosen same-type constraints affecting
canonicalization.
When enumerating requirements, always use the archetype anchors to
express requirements. Unlike "representatives", which are simply there
to maintain the union-find data structure used to track equivalence
classes of potential archetypes, archetype anchors are the
ABI-stable canonical types within a fully-formed generic signature.
The test case churn comes from two places. First, while
representatives are *often* the same as the archetype anchors, they
aren't *always* the same. Where they differ, we'll see a change in
both the printed generic signature and, therefore, it's
mangling.
Additionally, requirement inference now takes much greater
care to make sure that the first types in the requirement follow
archetype anchor ordering, so actual conformance requirements occur in
the requirement list at the archetype anchor---not at the first type
that is equivalent to the anchor---which permits the simplification in
IRGen's emission of polymorphic arguments.
Previously, for an Objective-C class method declaration that could be
imported as init, we were making 4 decls:
1) The Swift 2 init
2) The Swift 2 class method decl (suppressing init formation)
3) The Swift 3 init (omitting needless words)
4) The Swift 3 class method decl (suppressing init formation and
omitting needless words)
Decls 1), 2), and 4) exist for diagnostics and redirect the user at
3). But, 4) does not correspond to any actual Swift version name and
producing it correctly would require the user to understand how
omit-needless-words and other importer magic operates. It provides
very limited value and more importantly gets in the way of future
Clang importer refactoring. We’d like to turn Decl importing into
something that is simpler and language-version parameterized, but
there is no real Swift version to correspond to decl 4).
Therefore we will be making the following decls:
1) The "raw" decl, the name as it would appear to the user if they
copy-pasted Objective-C code
2) The name as it appeared in Swift 2 (which could be an init)
3) The name as it appeared in Swift 3 (which could be an init and omit
needless words)
This aligns with the language versions we want to import as in the
future: raw, swift2, swift3, …, and current.
Note that swift-ide-test prunes decls that are unavailable in the
current Swift version, so the Swift 2 non-init decls are not printed
out, though they are still present. Tests were updated and expanded to
ensure this was still the case.
There was a ton of complicated logic here to work around
two problems:
- Same-type constraints were not represented properly in
RequirementReprs, requiring us to store them in strong form
and parse them out when printing type interfaces.
- The TypeBase::getAllGenericArgs() method did not do the
right thing for members of protocols and protocol extensions,
and so instead of simple calls to Type::subst(), we had
an elaborate 'ArchetypeTransformer' abstraction repeated
in two places.
Rewrite this code to use GenericSignatures and
GenericFunctionType instead of old-school GenericParamLists
and PolymorphicFunctionType.
This changes the code completion and AST printer output
slightly. A few of the changes are actually fixes for cases
where the old code didn't handle substitutions properly.
A few others are subjective, for example a generic parameter
list of the form <T : Proto> now prints as <T where T : Proto>.
We can add heuristics to make the output whatever we want
here; the important thing is that now we're using modern
abstractions.
