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
- 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
The @semantics attribute allows the stdlib to mark some functions as
having a specific semantics. The optimizer can use this information
to optimize the code.
Swift SVN r19328
JoeP helped tweak things to ensure that pointer conversions are still
considered, but we no longer need the disjunction on InOutExprs to accommodate
user-defined inout conversions.
This causes some regressions in error reporting:
<rdar://problem/17489983> inout type mismatches complain about '@lvalue inout T'
<rdar://problem/17489894> inout not rejected as operand to assignment operator
Swift SVN r19306
This does no validation of the access control modifiers.
As part of this commit, note that "virtual" attributes may actually be
written in the source under another spelling. Update a few other parts of
the source to account for that.
Swift SVN r19140
When type checking a patternbindingdecl with an initializer, we check the
initializer expression, then apply the inferred type to the pattern. This
works except that we get down to a NamedPattern, see that it has various
attributes on it (e.g. iboutlet, weak) that affect the type of the pattern,
and we weren't re-propaging it back out through the pattern. Do that.
Swift SVN r18355
we can represent such a thing.
This fixes: <rdar://problem/16655091> @IBOutlet should imply ImplicitlyUnwrappedOptional+weak by default
Swift SVN r18320
at the SIL level. Now, the referent type of a WeakStorageType is always
an optional type, instead of always being the underlying reference. This
allows us to represent both optional types. Before, both of these had the
same AST representation of WeakStorageType(T):
weak var x : T?
weak var x : T!
which doesn't work. Now we represent the optional type explicitly in the
AST and at SIL level. This also significantly simplifies a bunch of code
that was ripping off the optional type and resynthesizing it in other places,
and makes SILGen of weak pointers much more straight-forward by eliminating
the need for emitRefToOptional and emitOptionalToRef entirely (see the diffs
in test/SILGen/weak).
Weak pointers still have problems, but this is a big step forward.
Swift SVN r18312
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
A closure can only be bridged if its arguments and returns can. Make the diagnostic for non-bridgeable function types a bit more precise too.
Swift SVN r18166
Drop a note in the source file containing the top-level code to make it easier to navigate to (and avoid hardcoding the magic "main.swift" name).
Swift SVN r18093
Now that runtime class names are mangled we should be able to safely allow local classes to be @objc without unduly polluting the class namespace. <rdar://problem/16844347>
Swift SVN r18064
Introduce the UIApplicationMain attribute, and check that it's only applied to nongeneric classes that conform to UIApplicationDelegate.
Swift SVN r18048
