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
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
Remove the logic that allowed an extension to provide an Objective-C
method that was already declared in the class itself, relying on the
existing Objective-C method redeclaration logic to detect such
conflicts. Fixes rdar://problem/17687082.
Swift SVN r25175
This way, we don't have issues with the verifier bringing in new types and
then those new types having members with un-type-checked bodies. Also,
delaying this is probably future goodness anyway, when we can skip the work
entirely if it's not needed.
I can't come up with a test case that currently fails besides the project in
rdar://problem/19778991, but all existing tests pass.
Swift SVN r25166
We certainly can't import them as stored properties, and it's too late to try to bridge them as computed property, so restore the old behavior of importing them as unbridged object types. The types still come in as strong managed reference types, which is still wrong, but seems to be right enough for Khan Academy and potentially other existing apps for now, and I don't want to introduce additional source-breaking changes and instability this late in the game. Fixes rdar://problem/19789023, leaving rdar://problem/19790608 to be done when we can afford more churn.
Swift SVN r25158
This commit changes the clang importer to always import attributes on property accessors.
Previously, attributes were only imported if the accessor method was declared before the
property but not if the accessor method was declared after it.
Swift SVN r25018
attribute or appear in a whitelist.
The initial whitelist is based on an audit I performed of our current
public SDKs. If there are CF types which appear only in our internal
SDKs, and somebody urgently needs to use them from Swift, they can
adopt the bridging attributes. The goal is to eventually eliminate
the whitelist and rely solely on bridging attributes anyway.
Sadly, CoreCooling was not included in my SDK audit and must be
explicitly annotated. :(
I've left the main database organized by framework, but I wanted
a quasi-lexicographically sorted version to permit efficient lookup.
We generate that copy automatically with gyb. I ended up having
to tweak handle_gyb_sources to allow it to drop the result in
CMAKE_CURRENT_BINARY_DIR instead of CMAKE_CURRENT_BINARY_DIR/{4,8}
if an architecture is not provided. I think this is abstractly
reasonable for generated includes, which have independent ability
to detect the target word size. But just between you and me,
I did it because I couldn't figure out how to add
"-I${CMAKE_CURRENT_BINARY_DIR/{4,8}" as a compile flag;
the obvious thing didn't work. Anyway, I'd appreciate it if
someone double-checked my cmake hackery here.
Swift SVN r24850
If a property, method, or subscript overrides an imported property, method,
or subscript that was originally declared using NSUInteger as a property,
parameter, or return type, print the subclass's member using "NSUInteger"
in the generated header to prevent override warnings.
This doesn't handle all cases--in particular, it doesn't handle the
NSUInteger being nested inside a larger type--but it does get the easy
ones correct. I think the easiest way to be more correct would be to mark
NSUInteger-as-Int somehow using a distinct type. (Hidden attribute?
Another typealias? Not sure.)
rdar://problem/19321126
Swift SVN r24771
...rather, over implicit decls mirrored from protocols into other categories
or the main @interface. But only in the same module, to try to minimize
differences.
rdar://problem/19398912
Swift SVN r24627
Previously the "as" keyword could either represent coercion or or forced
downcasting. This change separates the two notions. "as" now only means
type conversion, while the new "as!" operator is used to perform forced
downcasting. If a program uses "as" where "as!" is called for, we emit a
diagnostic and fixit.
Internally, this change removes the UnresolvedCheckedCastExpr class, in
favor of directly instantiating CoerceExpr when parsing the "as"
operator, and ForcedCheckedCastExpr when parsing the "as!" operator.
Swift SVN r24253
Previously we'd try to put the same method into the list of members multiple
times--once for each redeclaration in the @interface. This led to an
assertion failure.
Checking the canonical decl isn't super cheap, but the ObjCMethodDecl
redeclaration infrastructure seems to be fairly broken. We can revisit this
later.
There's also a test for what happens when categories get involved. I'm not
convinced this is correct behavior, either, and will file an additional bug
to look into that at some point.
rdar://problem/19039485
Swift SVN r24129
We were skipping this step, which meant that the initializers weren't
getting the availability information from their factory methods.
rdar://problem/18323494
Swift SVN r24034
"private" is a very overloaded term already. "Cascading" instead of
"non-private" is a bit more clear about what will happen with this sort
of lookup.
No functionality change. There are some double negatives I plan to clean
up in the next commit, but this one was supposed to be very mechanical.
Swift SVN r23969
If the common prefix of all enumerators ends with an underscore, but the
enumerators don't have a common prefix with the enum itself, we can't
drop the underscore.
rdar://problem/18730653
Swift SVN r23941
We were losing the nullability of factory methods that turned into
initializers (which should have been mapped to failability), and more
generally, methods with nullability for related result types
(instancetype in Clang, dynamic Self in Swift).
Note that this commit also contains tests for a similar Clang-side fix
where Clang itself wasn't correctly recording that an Objective-C
method with a nullability-qualified instancetype result type in fact
had a related result type.
Found by browsing through the most excellent Swift SDK Analyzer.
Swift SVN r23834
