We would previously hide the protocol, its extensions and members, but the '_'
prefix really just means the protocol itself isn't intended for clients, rather
than its members.
This also adds support for 'fully_annotated_decl' entries in doc-info for
extensions to be consistent with every other decl, and removes the
'fully_annotated_generic_signature' entry we supplied as a fallback.
Also fixes several bugs with the synthesized extensions mechanism:
- The type sustitutions applied to the extension's requirements were computed
using the extension itself as the decl context rather than the extension's
nominal. The meant the extension's requirements themselves were assumed to
hold when determining the substitutions, so equality constraints were always
met. Because of this extension members were incorrectly merged with the base
nominal or its extensions despite having additional constraints.
- Types within the requirements weren't being transformed when printed (e.g.
'Self.Element' was printed rather than 'T') both in the interface output and
in the requirements list. We were also incorrectly printing requirements
that were already satisfied once the base type was subsituted in.
- If both the protocol extension and 'enabling' extension of the base nominal
that added the protocol conformance had conditional requirements, we were
only printing the protocol extension's requirements in the synthesized
extension.
- The USR and annotated decl output embedded in the 'key.doc.full_as_xml'
string for synthesized members were printed to match their original context, rather than
the synthesized one.
Resolves rdar://problem/57121937
This attribute is intended to mean there's a replacement declaration that
should be used instead in Swift code. We already filter out decls with this
attribute in code completion, but were still exposing them in generated
interfaces.
Resolves rdar://problem/62464954
It's treated as a keyword by syntactic highlighting, but wasn't annotated as a
keyword by code completion, cursor info, or doc info.
Resolves rdar://problem/61114942
Not NFC because it changes the printing behavior for function type
parameters. They are no longer reported as types (paren, tuple, or raw),
but as Params.
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.
