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
local contexts. Get the parser in consultation with the DebuggerClient
to handle moving persistent declarations from the debugger function to the
source file.
<rdar://problem/15302321> [ER] Define Swift classes in expressions
Swift SVN r17948
missed on previous commits. This fixes:
<rdar://problem/16792095> QoI: misleading error message when trying to make a weak property be implicitly-unwrapped optional
and enables a useful pattern, where implicitly unwrapped weak pointers don't require !'ing on every use.
Swift SVN r17940
variables) because I can't inject synthesized decls into the parent declcontext
correctly. This sux and is fixable eventually, but until I do, reject these with
a clean error.
Swift SVN r17922
1) Change our "static variables not yet supported in classes" error to
print as "class variables not yet support".
2) Add a sema testcase for @NSManaged
3) Move NSManaged type checking logic to TypeCheckAttr.cpp to follow the
form of the other attributes, and to benefit from the infrastructure there.
Swift SVN r17885
We now allow bridging so long as both K and V can be bridged to
Objective-C, as determined by _BridgedToObjectiveC conformance. Note
that Dictionary's implementation still needs to handle this, which is
tracked separately.
Swift SVN r17859
weak variables can change at runtime, which means that two loads from
the same let could produce two different results. We have a concept for
this, it is called 'var'.
unowned pointers are not subject to this restriction of course.
Swift SVN r17847
- Mine conjunction constraints for constraint failure data. (rdar://problem/16833763)
- Rather than crash, add a diagnostic to signify a missing user constraint. (rdar://problem/16747055) I don't have a deterministic repro for this to include as a test, but users hit it from time to time, I'd like to address this issue holistically, and we're hoping that the new diagnostic will help us collect isolated repros.
- As promised, remove the temporary "compiler_submit_version" build configuration predicate in time for WWDC. (rdar://problem/16380797)
Swift SVN r17705
Even though declarations end up in the top-level module, this can still
/expose/ them if the submodule is explicit. I'll have to think more about
this.
This reverts r17656 / <rdar://problem/16818519>
Swift SVN r17668
...if the element type is an ObjC class or protocol type.
This currently only works if the element type is AnyObject;
that restriction will be lifted (on all @objc methods) once array bridging
is fully in place.
<rdar://problem/15607154>
Swift SVN r17574
Subscript declarations were still encoding the names of index
variables in the subscript type, which unintentionally made them
keyword arguments. Bring subscript declarations into the modern day,
using compound names to encode the subscript argument names, which
provides consistency for the keyword-argument world
<rdar://problem/14462349>. Note that arguments in subscripts default
to not being keyword arguments, which seems like the right default.
We now get keyword arguments for subscripts, so one can overload
subscripts on the names of the indices, and distinguish at the call
site. Under -strict-keyword-arguments, we require strictness here as well.
The IRGen/IDE/SILGen test updates are because the mangling of common
subscripts changed from accidentally having keyword arguments to not
having keyword arguments.
Swift SVN r17393
Implement a completely new path for matching up an argument tuple to a
parameter tuple, which handles the specific rules we want for
calls. The rules are:
- The keyword arguments at the call site must match those of the
declaration; one cannot omit a keyword argument if the declaration
requires it, nor can one provide a keyword argument if the
declaration doesn't have one.
- Arguments must be passed in order, except that arguments for
parameters with defaults can be re-ordered among themselves (we
can't test all of this because neither constraint application nor
the AST can express these).
QoI is extremely important in this area, and this change improves the
situation considerably. We now provide good diagnostics for several
important cases, with Fix-Its to clean up the code:
- Missing keyword arguments:
t.swift:8:13: error: missing argument labels 'x:y:' in call
allkeywords1(1, 2)
^
x: y:
- Extraneous keyword arguments:
t.swift:17:12: error: extraneous argument labels 'x:y:' in call
nokeywords1(x: 1, y: 1)
^~~~ ~~~
- General confusion over keyword arguments (some missing, some
wrong, etc.):
t.swift:26:14: error: incorrect argument labels in call (have
'x:_:z:', expected '_:y:z:')
somekeywords1(x: 1, 2, z: 3)
^~~~
y:
There are still a few areas where the keyword-argument-related
diagnostics are awful, which correspond to FIXMEs in this
implementation:
- Duplicated arguments: f(x: 1, x: 2)
- Extraneous arguments: f(x: 1, y: 2, z: 3) where f takes only 2
parameters
- Missing arguments
- Arguments that are out-of-order
- Proper matching of arguments to parameters for diagnostics that
complain about type errors.
And, of course, since this has only been lightly tested, there are
undoubtedly other issues lurking.
This new checking is somewhat disjoint from what constraint
application can handle, so we can type-check some things that will
then fail catastrophically at constraint application time. That work
is still to come, as is the AST work to actually represent everything
we intend to allow.
This is part of <rdar://problem/14462349>.
Swift SVN r17341
We want to eliminate single-element tuples, but for now we need to
keep them from crashing the compiler. Fixes
<rdar://problem/16795899>.
Swift SVN r17286
This is the simplest case to test the infrastructure for
adding/removing/fixing keyword arguments at the call site that don't
line up with the keyword arguments in a declaration. Baby steps toward
<rdar://problem/14462349>.
Swift SVN r17136
// IBAction, OS X:
@IBAction func foo(sender: AnyObjCClassCompatibleType?)
// IBAction, iOS:
@IBAction func foo()
@IBAction func foo(sender: AnyObjCClassCompatibleType?)
@IBAction func foo(sender: AnyObjCClassCompatibleType?, event: UIEvent?)
All argument types may be unchecked-optional or non-optional as well.
This commit doesn't check that the second argument to an iOS action method
is a UIEvent; the user may want to declare it as AnyObject or perhaps some
other protocol, so I just left it unenforced.
I'm also drawing on my knowledge of Cocoa to disallow String as an IBAction
parameter. Array and Dictionary also shouldn't appear here and thus don't
need special-casing even when bridged.
Finishes up <rdar://problem/16281474>
Swift SVN r17049
double-quoted string literals that contain a single extended grapheme cluster
SEGCL by default infer type String, but you can ask to infer Character
for them.
Single quoted literals continue to infer Character.
Actual extended grapheme cluster segmentation is not implemented yet,
<rdar://problem/16755123> Implement extended grapheme cluster
segmentation in libSwiftBasic
This is part of
<rdar://problem/16363872> Remove single quoted characters
Swift SVN r17034
Fixes <rdar://problem/15042686>, i.e.,
t.swift:3:7: error: call to non-function of type 'Int'; did you mean
to leave off the '()'?
i = i()
^~~
Swift SVN r16950
