We wanted to omit the 'Self: TheProtocolBeingExtension' part of the
generic signature, but the logic that was there accidentally omitted
/all/ constraints on Self.
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.
To make generic signature builder more robust it's imperative to
eliminate possibility of out-of-order typealias substitution.
These changes try to make it so potential archetypes could only be
constructed with associated types by doing early concrete type (typealias)
subsitution while trying to resolve equivalence class.
This converts the instances of the pattern for which we have a proper
substitution in lit. This will make it easier to replace it
appropriately with Windows equivalents.
Before conditional conformances, the archetypes in conformance
extensions (i.e. extension Foo: SomeProtocol) were equivalent to those
in the type decl, with the same protocol bounds and so on. The code for
printing "synthesized" members relied on this fact. This commit teaches
that code to deal with archetypes in the conditional conformance
extension when required.
Fixes rdar://problem/36553066 and SR-6930.
Stop parsing frontend arguments directly and use the driver instead. The
most intersting part of this change is that it forces us to consider
whether our compiler invocation will have inputs or not. We have
several kinds of requests that need to create a compiler instance, but
not parse any inputs (interface-generation, doc-info, and indexing when
operating on a module instead of source files).
Incidentally, add an error when trying to do doc-info on multiple source
files. This was already very broken (assertion failures and bogus source
locations), so add an error for it.
rdar://problem/17897287
These tests were relying on sourcekitd parsing as frontend instead of
using the driver. Update them now to avoid churn when we fix command
line argument parsing in sourcekit.
The changes from clang-importer-sdk to clang-importer-sdk-nosource -I %t
are because clang-importer-sdk implies using -enable-source-import.
Rather than hack them up to use -Xfrontend, it is cleaner to just stop
using source import at all for these tests. Incidentally, this improved
fidelity in a few places. When using the generated swift modules we
also need to pass a target triple to sourcekit, which exposed some tests
that had mac-specific data. This is a systemic issue for sourcekit
tests, but for now just make those few specific tests that we had
problems with run only on mac.
(and 'La'...'Lj')
Use this for the synthesized structs for error enums, as described in
the previous commit, instead of reusing the "private discriminator"
feature. I left some space in the APIs for "related entity kinds" that
are longer than a single character, but I don't actually expect to use
it any time soon. It's mostly just easier to deal with StringRef than
with a bare char.
Note that this doesn't perfectly round-trip to the old mangling; I had
it treat these nodes as private discriminators with a prefixed "$"
instead. We don't depend on that for anything, though.
When importing a C enum with the ns_error_domain attribute, we
synthesize a struct containing an NSError object to represent errors
in that domain. That synthesized struct should have a mangled name
that ties it to the original C enum, if we want it to be stable, and
now it does.
Before: $SSC7MyErrorV (a normal struct, which is a lie)
After: $SSC11MyErrorCode13ns_error_enumLLV
kind=Global
kind=Structure
kind=Module, text="__C_Synthesized"
kind=PrivateDeclName
kind=Identifier, text="ns_error_enum"
kind=Identifier, text="MyErrorCode"
Using the "private discriminator" feature allows us to pack in extra
information about the declaration without changing the mangling
grammar, and without stepping on anything the importer is using.
More rdar://problem/24688918
This makes them consistent no matter what shenanigans are pulled by
the importer, particularly NS_ENUM vs. NS_OPTIONS and NS_SWIFT_NAME.
The 'NSErrorDomain' API note /nearly/ works with this, but the
synthesized error struct is still mangled as a Swift declaration,
which means it's not rename-stable. See follow-up commits.
The main place where this still falls down is NS_STRING_ENUM: when
this is applied, a typedef is imported as a unique struct, but without
it it's just a typealias for the underlying type. There's also still a
problem with synthesized conformances, which have a module mangled
into the witness table symbol even though that symbol is linkonce_odr.
rdar://problem/31616162
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.
Use this to remove the last bit of the hack to suppres noescape on setter
arguments. Add a more comprehensive test of noescape's interaction with
accessors.
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.
I noticed in a follow-up patch that if you just swiftc without passing Onone
these flags are not set and sometimes happen to default to right thing ... or
not; as can be seen by the test cases modified. For example, at Onone we are
supposed to include an extra swift module "SwiftOnoneSupport".
...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
We don't need to force the creation of potential archetypes when
finding anchors, because new potential archetypes will only be created
by this process in ill-formed generic signatures. Tolerate failure
whenever this happens (for now) and the failure paths will become dead
once AlwaysPartial is eliminated fully.
