CF types don't have real class objects (yet...), so there's nowhere to introduce ObjC metadata for methods or protocol conformance. Let's reject them in Sema. It's still reasonable to extend CF types with pure Swift methods, and this works now. <rdar://problem/17569520>
Swift SVN r19589
In theory there's nothing wrong with this, but it makes it hard to see what
operations a class supports, and there's no obvious way to go to its nearest
public superclass.
Note that we have a similar issue with protocols, since private protocols can
refine public protocols, and then public classes can conform to private
protocols---the indirect conformance won't be listed in the inheritance
clause, but it is a public conformance nonetheless.
Swift SVN r19588
While this could be useful, a raw type implies a conformance to
RawRepresentable, and private methods cannot be used to satisfy conformances
of public types to public protocols.
Swift SVN r19587
- Change the parser to accept "objc" without an @ sign as a contextual
keyword, including the dance to handle the general parenthesized case.
- Update all comments to refer to "objc" instead of "@objc".
- Update all diagnostics accordingly.
- Update all tests that fail due to the diagnostics change.
- Switch the stdlib to use the new syntax.
This does not switch all tests to use the new syntax, nor does it warn about
the old syntax yet. That will be forthcoming. Also, this needs a bit of
refactoring, which will be coming up.
Swift SVN r19555
- Setters cannot (in this release) have more accessibility than getters.
- The modifiers don't make sense for constants and read-only vars/subscripts.
Swift SVN r19548
Also, don't diagnose accessibility violations on implicit decls. Every now
and then the compiler needs to bend the rules, such as when providing an ==
implementation for a local enum.
Swift SVN r19519
We could actually allow the default definition of an associated type to have
less accessibility than the requirement, but then we'd also have to check
that that type wasn't being used where it wasn't accessible. Since we infer
associated types anyway, it's probably not worth it.
Swift SVN r19493
This does not yet handle variables with inferred types, since those don't
have TypePatterns.
There is some nasty propagation of @public into the stdlib because of this
one, mainly because Foundation needs access to some of the implementation
details of Array and Dictionary. We may want to try to improve this later
(or just build Foundation with -disable-access-control if it comes to that).
Swift SVN r19432
...unless the type has less accessibility than the protocol, in which case
they must be as accessible as the type.
This restriction applies even with access control checking disabled, but
shouldn't affect any decls not already marked with access control modifiers.
Swift SVN r19382
We haven't been advertising this syntax much, and it's closure form
was completely broken anyway, so don't jump through hoops to provide
great Fix-Its here.
Swift SVN r19277
Handle parsing of dictionary type sugar into its own type
representation, including both type and expression contexts.
This is the first part of <rdar://problem/17460972>; we still need a
sugared Type node.
Swift SVN r19239
Better to describe how the protocol can be used than how it can't. Also include a mention of Self type requirements as a source of non-existentiability.
Swift SVN r19207
When checking an isa pattern that requires either collection
downcasting or bridging through an Objective-C class (e.g.,
"is String" or "is Dictionary<String, Int>"), form a conditional
downcast and place it in an expression pattern.
With this change, we can test for these cases (with "is") but we can't
capture the value produced on success (e.g., for "let str as
String"). This is a first small step toward <rdar://problem/17408934>.
Swift SVN r19070
These types are often useless and confusing to users who expect to be able to use Sequence or Generator as types in their own right like in C# or Java. While we're here, relax the rules for self-conformance to admit methods returning 'Self'. Covariant return types should not actually prevent a protocol type from conforming to itself, and the stdlib makes particular use of protocols with 'init' requirements which implicitly return Self.
Swift SVN r18989
This is all goodness, and eliminates a major source of implicit conversions.
One thing this regresses on though, is that we now reject "x == nil" where
x is an option type and the element of the optional is not Equtatable. If
this is important, there are ways to enable this, but directly testing it as
a logic value is more straight-forward.
This does not include support for pattern matching against nil, that will be
a follow on patch.
Swift SVN r18918
Don't use spare bits on platforms that use ObjC tagged pointers when an enum payload involves a class-constrained existential, archetype, or ObjC-defined class type. If a payload is of a Swift-defined class type, we can still assume it's a real pointer and use its spare bits. Add an @unsafe_no_objc_tagged_pointer attribute that can be applied to protocols to denote that existentials bounded by that protocol can use spare bits; this is necessary to preserve the layout of bridged Array and Dictionary types, which should not be bound to tagged pointer types in practice (fingers crossed). Fixes <rdar://problem/16270219>.
Swift SVN r18781
We removed this feature when we changed casting syntax, but left it in
the type checker to help migrate code via a Fix-It. We no longer need
it.
Swift SVN r18729
Post-WWDC, we need to update the type checking process to make these kinds of infinite loops impossible without checking special flags.
Swift SVN r18598
There's a bit of a reshuffle of the ExplicitCastExpr subclasses:
- The existing ConditionalCheckedCastExpr expression node now represents
"as?".
- A new ForcedCheckedCastExpr node represents "as" when it is a
downcast.
- CoerceExpr represents "as" when it is a coercion.
- A new UnresolvedCheckedCastExpr node describes "as" before it has
been type-checked down to ForcedCheckedCastExpr or CoerceExpr. This
wasn't a strictly necessary change, but it helps us detangle what's
going on.
There are a few new diagnostics to help users avoid getting bitten by
as/as? mistakes:
- Custom errors when a forced downcast (as) is used as the operand
of postfix '!' or '?', with Fix-Its to remove the '!' or make the
downcast conditional (with as?), respectively.
- A warning when a forced downcast is injected into an optional,
with a suggestion to use a conditional downcast.
- A new error when the postfix '!' is used for a contextual
downcast, with a Fix-It to replace it with "as T" with the
contextual type T.
Lots of test updates, none of which felt like regressions. The new
tests are in test/expr/cast/optionals.swift.
Addresses <rdar://problem/17000058>
Swift SVN r18556
This bans the syntax
x as T!
because the user probably wanted "(x as T)!", but the parsing makes
more sense as "x as (T!)". When complaining about this syntax, provide
notes with Fix-Its for both parenthesizations, and recover as if the
user took the first one, which is by far more common.
Addresses <rdar://problem/16952768>.
Swift SVN r18435
<rdar://problem/16264989> property not mutable in closure inside of its willSet
and:
<rdar://problem/16826319> willSet immutability behavior is incorrect
by changing how we handle immutability of an observing property within its willSet.
Instead of trying to model it as an rvalue, just model it as an lvalue (which it is)
and diagnose the problem with a warning in MiscDiagnostics.
Swift SVN r18184
We can't compile blocks that aren't representable in ObjC, and they wouldn't be very useful, so reject them. Fixes <rdar://problem/16746132>.
Swift SVN r18171
