This allows SILGen to recognize them as foreign declarations, fixing a bug when classes with subscripts defined in Objective-C were extended to conform to Swift protocols with subscript requirements. rdar://problem/20371661
Swift SVN r27998
The Clang importer was relying on stashing the protocol list within a
nominal type or extension and then retrieving it to fill in all of the
members, which will typically happen before the protocol conformances
can be handled. This prevented the conformance lookup table from being
directly usable for these protocol queries.
In time, the conformance lookup table should have separate callbacks
for "list the protocols to which this conforms" and "provide all of
the conformances", which can make these computations lazier. For now,
use a side table to stash these conformances.
Part of rdar://problem/18448811.
Swift SVN r27980
When deserializing a protocol, the conformance lookup table would not
contain entries for the inherited protocols of that protocol. They
were stashed in the "Protocols" array in TypeDecl (which will
eventually go away), but since there are no conformances for a
protocol, the conformance lookup table never got updated.
Nothing important seems to query this now; that will change soon.
Swift SVN r27967
Previously, we were importing Clang's 'deprecated' attribute in as
@availability(*, unavailable), based on the idea things that were
unconditionally deprecated in Objective-C shouldn't even be accessible
in Swift. (We were motivated by 'tmpnam', among others). However, this
plays havoc with mixed Objective-C/Swift projects, because the
Objective-C 'deprecated' attribute was useless as a mechanism for
making internal changes in the project. We have Clang's
__attribute__((availability(swift, unavailable))) to make an API
unavailable in Swift, so the deprecated -> unavailable mapping here no
longer makes sense.
Fixes rdar://problem/18934173.
Swift SVN r27358
Allow an unversioned 'deprecated' attribute to specify unconditional
deprecation of an API, e.g.,
@availability(*, deprecated, message="sorry")
func foo() { }
Also support platform-specific deprecation, e.g.,
@availability(iOS, deprecated, message="don't use this on iOS")
func bar() { }
Addresses rdar://problem/20562871.
Swift SVN r27355
Allow an unversioned 'deprecated' attribute to specify unconditional
deprecation of an API, e.g.,
@availability(*, deprecated, message="sorry")
func foo() { }
Also support platform-specific deprecation, e.g.,
@availability(iOS, deprecated, message="don't use this on iOS")
func bar() { }
Addresses rdar://problem/20562871.
Swift SVN r27339
This works around a big performance regression in code completion
performance that was introduced with r25741. This hack does not work
completely correctly with multiple file builds, but a) this should be a
minor issue for enum code completions, and b) this simply returns to the
pre-25741 behaviour. This hack should disappear when we fix
rdar://problem/20047340.
For rdar://problem/20445407.
Swift SVN r27320
Introduce basic validation for throwing @objc initializers, e.g., a
failable @objc initializer cannot also be throwing. However,
Objective-C selector computation is broken.
Swift SVN r27292
I don't want to call this complete until
a) we handle using alias names in switch statements (right now they're
straight-up rejected, not just non-complete), and
b) we prefer non-deprecated names over deprecated ones to be the "real"
enum cases.
but this is a good start, and fixes them showing up poorly in the SDK
analyzer.
rdar://problem/18662118
Swift SVN r27130
This is the new and improved version of
__attribute__((annotate("swift1_unavailable"))), with the "improved" being
specifically that the 'availability' attribute supports a message.
This requires a corresponding Clang commit.
Swift side of rdar://problem/18768673.
Swift SVN r27053
...and bump our "Foundation epoch" guard to 3 to match.
Long-term we should switch to an attribute for "yes, this is really a set
of enumerated constants" (and "this is a set of related bitmask options"),
but this unblocks things for now, and doesn't cause any issue if we end
up doing something else.
rdar://problem/20418505
Swift SVN r26944
Previously some parts of the compiler referred to them as "fields",
and most referred to them as "elements". Use the more generic 'elements'
nomenclature because that's what we refer to other things in the compiler
(e.g. the elements of a bracestmt).
At the same time, make the API better by providing "getElement" consistently
and using it, instead of getElements()[i].
NFC.
Swift SVN r26894
Start parsing a "trailing" where clause for extension declarations, which follows the extended type name and (optional) inheritance clause. Such a where clause is only currently permitted for protocol extensions right now.
When used on a protocol extension, it allows one to create a more-constrained protocol extension, e.g.,
extension CollectionType where Self.Generator.Element : Equatable { ... }
which appears to be working, at least in the obvious cases I've tried.
More cleanup, tests, and penance for the previous commit's "--crash" introductions still to come.
Swift SVN r26689
Remove the semantic restrictions that prohibited extensions of
protocol types, and start making some systematic changes so that
protocol extensions start to make sense:
- Replace a lot of occurrences of isa<ProtocolDecl> and
dyn_cast<ProtocolDecl> on DeclContexts to use the new
DeclContext::isProtocolOrProtocolExtensionContext(), where we want
that behavior to apply equally to protocols and protocol extensions.
- Eliminate ProtocolDecl::getSelf() in favor of
DeclContext::getProtocolSelf(), which produces the appropriate
generic type parameter for the 'Self' of a protocol or protocol
extension. Update all of the callers of ProtocolDecl::getSelf()
appropriately.
- Update extension validation to appropriately form generic
parameter lists for protocol extensions.
- Methods in protocol extensions always use the witnesscc calling
convention.
At this point, we can type check and SILGen very basic definitions of
protocol extensions with methods that can call protocol requirements,
generic free functions, and other methods within the same protocol
extension.
Regresses four compiler crashers but improves three compiler
crashers... we'll call that "progress"; the four regressions all hit
the same assertion in the constraint system that will likely be
addressed as protocol extensions starts working.
Swift SVN r26579
I'm not sure this code is even still necessary, but while we're still
using it we can at least not pretend we're still using it for properties.
No functionality change.
Swift SVN r26480
We have an SPI between the Swift compiler and Foundation based on the
SWIFT_SDK_OVERLAY_FOUNDATION_EPOCH preprocessor macro that allows us to
request the new API. rdar://20270080 tracks removing it.
Swift SVN r26475
Currently a no-op, but effective access for entities within the current
module will soon need to take testability into account. This declaration:
internal func foo() {}
has a formal access of 'internal', but an effective access of 'public' if
we're in a testable mode.
Part of rdar://problem/17732115 (testability)
Swift SVN r26472
We now access the conformances of a nominal type through the
conformance lookup table, so there is no reason to continue storing
conformances directly on the nominal type declaration, which was
error-prone regardless. This mirrors the change to ExtensionDecl from
my previous commit.
Swift SVN r26354
Stop storing a conformances array on ExtensionDecls. Instead, always use the conformance lookup table to retrieve conformances (which is lazy and supports multi-file, among other benefits).
As part of this, space-optimize ExtensionDecl's handling of conformance loaders. When one registers a conformance loader, it goes into a DenseMap on ASTContext and gets erased once we've loaded that data, so we get two words worth of space back in each ExtensionDecl.
Swift SVN r26353
This lets us tag imported declarations with arbitrary synthesized
protocols. Use it to handle imported raw option sets as well as the
RawRepresentable conformances of enums that come in as structs.
Swift SVN r26298
This fixes the import of enums like NSCalendarUnit, which changed from
NSXXXCalendarUnit to NSCalendarUnitXXX, as has been the guideline in
recent years. Now even when the old names are present, we can still
prefix-strip based on the new names. If /all/ options are deprecated,
though, we'll prefix-strip as we did before.
Note that we /don't/ check the current deployment target for this,
because we want to use the "nice" names as soon as we have an SDK where
they're available, not when the deployment target matches such an SDK.
rdar://problem/17686122
Swift SVN r26184
This changes 'if let' conditions to take general refutable patterns, instead of
taking a irrefutable pattern and implicitly matching against an optional.
Where before you might have written:
if let x = foo() {
you now need to write:
if let x? = foo() {
The upshot of this is that you can write anything in an 'if let' that you can
write in a 'case let' in a switch statement, which is pretty general.
To aid with migration, this special cases certain really common patterns like
the above (and any other irrefutable cases, like "if let (a,b) = foo()", and
tells you where to insert the ?. It also special cases type annotations like
"if let x : AnyObject = " since they are no longer allowed.
For transitional purposes, I have intentionally downgraded the most common
diagnostic into a warning instead of an error. This means that you'll get:
t.swift:26:10: warning: condition requires a refutable pattern match; did you mean to match an optional?
if let a = f() {
^
?
I think this is important to stage in, because this is a pretty significant
source breaking change and not everyone internally may want to deal with it
at the same time. I filed 20166013 to remember to upgrade this to an error.
In addition to being a nice user feature, this is a nice cleanup of the guts
of the compiler, since it eliminates the "isConditional()" bit from
PatternBindingDecl, along with the special case logic in the compiler to handle
it (which variously added and removed Optional around these things).
Swift SVN r26150
It causes some fails in compiler_crashers:
Swift :: compiler_crashers/0986-swift-unboundgenerictype-get.swift
Swift :: compiler_crashers/1103-swift-unboundgenerictype-get.swift
Swift :: compiler_crashers/1223-swift-lexer-leximpl.swift
Swift :: compiler_crashers/1276-swift-metatypetype-get.swift
Swift :: compiler_crashers/1287-swift-printingdiagnosticconsumer-handlediagnostic.swift
Swift SVN r26136
This is effectively NFC, but we had two implementations of "figure out
the protocols that this type should implicitly conform to". The one in
the conformance table is what will matter going forward.
Swift SVN r26115
The fix for rdar://problem/19924834 introduced a 10% performance hit when importing Foundation. Playgrounds are performance-sensitive, and ought to be able to keep working without the fix, because they're never multi-file and it's not yet possible to dynamically access an Equatable or RawRepresentable conformance using 'is' or 'as'. Preserve the old behavior in playground mode, until we have time to recover the performance hit in a more principled way (covered by rdar://problem/20047340).
Swift SVN r25772
Fixes rdar://problem/19924834, which exposes a case where delayed protocols cause an imported enum's Equatabe protocol conformance to get instantiated too late, if the enum is imported by one file that doesn't use the Equatable conformance, and a subsequent file in the same invocation then uses the conformance. Jordan notes that delaying these conformances is no longer desirable, now that we dynamically detect conformances.
Swift SVN r25741
...rather than just assuming any initializer without a body that makes it
to SILGen is a memberwise initializer.
In the long term we want SILGen to stop handling these initializers, at
which point we can see if it makes sense to remove this body kind.
No intended functionality change.
Swift SVN r25723
This is a workaround for us saying that the setter generated for a property
conflicts with the setter-method explicitly declared in the Objective-C
protocol. (After all, they do have the same name.) If we really want to
support this, we need something like "var foo { get optional set }", which
our model doesn't really support right now. But we should at least allow
the user's code to build.
rdar://problem/19933285
Swift SVN r25634
The contract for LazyResolver::loadAllMembers() was that the caller
would handle actually adding the members, since it was an iterable
declaration context and could centralize that (simple) logic. However,
this fails in the Clang importer in rare but amusing ways when some of
the deferred actions (e.g., finishing a protocol conformance) depend
on having the members already set. The deferred action occurs after
the member list is complete in ClangImporter's loadAllMembers(), but
before its caller actual set the member list, leaving incomplete
conformances. Fixes rdar://problem/18884272.
Swift SVN r25630
This ensures we don't leave references to Clang-importer-generated symbols in overlays, working around rdar://problem/19925662, and seems like a good idea regardless.
Swift SVN r25582
This reverts r25401. After reviewing the issues this was intended to solve,
and then talking to Dave, I've decided that this doesn't actually solve
enough of the problems we wanted it to, and it creates added complexity,
so I'm taking it back out.
Originally rdar://problem/19667625.
Swift SVN r25489
...even if they were designated in the base class. (Unless they're required,
in which case they're still required.)
This led to Swift subclasses treating convenience initializers as
designated initializers, which (if synthesized) led to properties being
initialized twice.
rdar://problem/19730160
Swift SVN r25410
