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
This reverts commits r26369 & r26381.
After upstream clang changes, reverted r25843 which was compensating for a previous upstream clang change.
But keep test/IDE/complete_from_clang_framework.swift disabled for further investigation, because it
seems to have some duplications in a code-completion test.
rdar://20245658&20247922
Swift SVN r26430
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
- Add frontend and standard library build support for tvOS.
- Add frontend support for watchOS.
watchOS standard library builds are still disabled during SDK bring-up.
To build for TVOS, specify --tvos to build-script.
To build for watchOS, specify --watchos to build-script (not yet supported).
This patch does not include turning on full tests for TVOS or watchOS, and
will be included in a follow-up patch.
Swift SVN r26278
When an imported Objective-C property has nullability, force that
nullability onto the result of its getter and the parameter of its
setter, so that we have consisteny nullability among the three. SILGen
assumes that this is the case, so this fixes the null_resettable-based
crash in <rdar://problem/20145910>.
Swift SVN r26198
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
We don't handle a line 0 in Swift, and this led to LLDB crashing. I'm not
actually sure why Clang was emitting an error on line 0, either; the full
location was "<built-in>:0:4" and the error was
module 'CoreFoundation' found in both '.../CoreFoundation-17XE9QM744UO5.pcm'
and '.../CoreFoundation-2BVMOFFOYI8X.pcm'
which turned out to be another manifestation of rdar://problem/19817341
(this was an older LLDB build). No test cases because I'm not sure how to
trigger this, especially not since the previous Radar was fixed, but I'll
clone it to track down why Clang is using such an unusual location.
rdar://problem/19951280
Swift SVN r25766
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
The new modules are:
* SwiftUnstable -- assorted additions to the core standard library
(more algorithms etc.)
* SwiftUnstableDarwinExtras -- proposed additions to the Darwin overlay,
not yet reviewed by the Darwin team.
* SwiftUnstablePthreadExtras -- wrappers that make it possible to
use pthread in Swift (they work around the lack of block-based API in
pthread). In future these could be possibly folded into the Darwin
overlay as well.
These APIs are useful without StdlibUnittest for writing automation
tools in Swift. Just like SwiftExperimental, none of these modules are
exposed to extrenal users.
Also, since these new modules can be compiled with -sil-serialize-all
(unlike StdlibUnittest, where we can't apply the flag because of
compiler bugs), standard library tests that need to run optimized code
(like AtomicInt.swift) are *much* faster now.
Swift SVN r25679
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
typedef unsigned long ByteCount;
typedef unsigned long ItemCount;
Both of these are still in use by CoreMIDI, but we don't have a reason to
keep them distinct in Swift.
rdar://problem/19939552
Swift SVN r25529
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
This pattern isn't too uncommon:
typedef CF_ENUM(CFIndex, CFFoo) {
CFFooBar
};
typedef NS_ENUM(NSInteger, NSFoo) {
NSFooBar = CFFooBar
};
NSFoo and CFFoo are distinct types, but sometimes you need to convert from
one to the other. Today the only way to do to that is via rawValue, which
is especially unpleasant if the raw types don't match.
This commit introduces a new converting initializer for NSFoo:
init!(_ value: CFFoo) {
self.init(rawValue: RawType(value.rawValue))
}
It's failable by necessity because init(rawValue:) is failable for proper
enums. In practice an audit of our public headers found zero cases where
there are "more" cases in CFFoo than in NSFoo, i.e. cases where the
conversion would fail.
This also applies to option sets and opaque enums, but those use a
non-failable initializer because there's no way to check validity.
rdar://problem/19667625
Swift SVN r25401
This renames their 'value' field to 'rawValue'.
This is needed for consistency in the next commit. I can't find a Radar for
it, though.
Swift SVN r25399
It doesn't make sense to try to construct a partially-imported struct elementwise in Swift. We don't know what all the fields are yet. Part of rdar://problem/19807099.
Swift SVN r25366
This should help us avoid crashes like rdar://problem/19798049 in the future.
Of course, since fatal errors are so rare, I don't have a way to test this,
but it isn't breaking any of the paths we currently use.
rdar://problem/19827938
Swift SVN r25285
