When comparing a requirement to a witness for @objc protocols, strip
optionality out of the types and keep track of the optionality
differences separately. When we have actually matched a witness,
diagnose any unsafe (via an error) or ill-advised (via a warning)
differences, providing Fix-Its to update the optionality.
This change addresses a usable problem introduced by the fix to
rdar://problem/18383574: witnesses for optional requirements of @objc
protocols could previously have completely wrong optionality, and we
would "allow" it by not actually matching the witness to the
requirement. Then it would happen to work at runtime because it's
@objc. Now, we match those witnesses and diagnose issues, with Fix-Its
to clean up the user's code.
Addresses rdar://problem/19656106.
Swift SVN r24939
The materializeForSet accessor for a `dynamic` property needs to dynamically invoke the getter and setter of the property in order to allow for runtime modification, so it doesn't need to be dynamically dispatched itself. If the property came from an imported ObjC class, then we can't dynamically dispatch it without polluting the selector namespace. Introduce a new 'ForcedStaticDispatch' bit and set it in order to force `dynamic` materializeForSet accessors to be statically dispatched. (They can't be `final` because it's legal to override a dynamic property.) If the property came from ObjC, register materializeForSet as an external declaration so it gets generated by SIL. Fixes rdar://problem/18706056.
Swift SVN r24930
These haven't ever been safe in Swift's development because they require
generating thunks, and we currently don't do that. However, we were letting
existential conversions slip through the cracks because we consider them
subtypes, so that /metatype/ conversions work correctly. To be concrete:
"let _: Any.Type = Int.self" is okay.
"let _: (Int) -> Void = { (_: Any) -> Void in return }" is not.
We should implement this some day; that's rdar://problem/19517003.
This produces some lousy error messages, which I intend to fix soon.
Part of rdar://problem/19600325
Swift SVN r24915
Previously, trailing closures would try to match the first parameter
of (possibly optional) function type that didn't seem to have an
argument already, but in practice this broke when there were
parameters with default arguments before the function parameter.
The new rule is far simpler: a trailing closure matches the last
parameter. Fixes rdar://problem/17965209.
Swift SVN r24898
Semantically, a dynamic property must always be dispatched in case it gets replaced at runtime, and an @NSManaged property may not have static accessors at all. Use ordinary access to the computed property accessors in materializeForSet when a property is dynamic or ObjC-originated. More rdar://problem/18706056.
There's still a problem--we try to vtable-dispatch materializeForSet, which is redundant for native classes, but impossible for imported ObjC classes. We should suppress this, but trying to make materializeForSet "final" breaks subclassing if the property is overridden.
This time, update test/SILGen/objc_properties.swift to avoid a false negative test failure.
Swift SVN r24888
Semantically, a dynamic property must always be dispatched in case it gets replaced at runtime, and an @NSManaged property may not have static accessors at all. Use ordinary access to the computed property accessors in materializeForSet when a property is dynamic or ObjC-originated. More rdar://problem/18706056.
There's still a problem--we try to vtable-dispatch materializeForSet, which is redundant for native classes, but impossible for imported ObjC classes. We should suppress this, but trying to make materializeForSet "final" breaks subclassing if the property is overridden.
Swift SVN r24882
When generating constraints for an 'as' expression, consider the
possibility that the code is supposed to be 'as!' instead of 'as'. Emit
the appropriate fixit if that branch of the disjunction is chosen by the
constraint solver.
This is a more comprehensive fix for <rdar://problem/19499340> than the
one in r24815.
Swift SVN r24872
This commit adds checking for accesses of potentially unavailable getters and setters.
When walking an expression to check availability, AvailabilityWalker now keeps track of
the context for when it encounters a MemberRefExpr. This context be either
(1) the next encountered member reference could cause the member's getter to be called
(e.g., the member ref is for a read of the property); (2) the member's setter could be
called (e.g., the member ref is the left-hand-side of an assignment); or (3) the member
ref generates the lvalue for for an InOutExpr (&) -- in which case we have to assume both
the getter and the setter could be called. These diagnostics are protected by the
-enable-experimental-availability-checking flag.
This commit does not import separate getter and setter availability from Objective-C; that
is coming in a future commit.
Swift SVN r24870
Another fix for rdar://problem/18706056. This should make @NSManaged properties work fine with @objc protocols, but I expect us to still be broken with native protocols.
Swift SVN r24862
- Situations where the type of a return statement's result expression doesn't line up with the function's type annotation.
- Situations where the type of an initializer expression doesn't line up with its declaration's type pattern.
- Situations where we assume a conversion to a built-in protocol must take place, such as in if-statement conditionals.
(Addresses rdar://problem/19224776, rdar://problem/19422107, rdar://problem/19422156, rdar://problem/19547806 and lots of other dupes.)
Swift SVN r24853
Per discussion with the IB team, a class can retroactively be marked as
designable via an extension (or if not retroactively, at least from elsewhere
in the module). This matches the documentation for Objective-C.
(The attribute still has no semantics in Swift itself. The only restriction
is that it must appear on a class or an extension of a class.)
rdar://problem/19654163
Swift SVN r24837
This commit moves potential unavailability diagnostics (when not treating unavailable
symbols as optional) out of CSApply.cpp and into MiscDiagnostics.cpp, alongside the
deprecation-based and explicitly unavailable checks. This move is a precursor to adding
support for separate availability information on getters and setters. No intended
functional change.
Swift SVN r24836
Previously, we attempted to infer @objc-ness based on conformance, but
doing so is fraught with ordering dependencies, and just doesn't work
in the general case. Among other crimes, this allowed us to
retroactively mark a non-@objc method from an imported module as
@objc... even though nobody would ever then emit the @objc entry
points for it.
Fixes the rest of rdar://problem/18383574.
Swift SVN r24831
An optional @objc requirement within a protocol can be left
unsatisfied in a well-formed program. However, there may still be a
conflict within the Objective-C runtime if the conforming class
defines a method with the corresponding Objective-C selector(s) for
that requirement, which means that the Swift and Objective-C semantics
will differ. Diagnose such issues.
More steps along the road to fixing rdar://problem/18383574.
Diagnose conflicts between unsatisfied, optional @objc requirements and
Swift SVN r24830
When we match a witness to a requirement in a protocol, we do so based
on the Swift name (which is correct). When the requirement is @objc
(because it is in an @objc protocol), also check that the Objective-C
selectors of the witness match those of the requirement.
Fixes the majority of rdar://problem/18383574.
Swift SVN r24829
Parser may stop at some erroneous constructions like stray #else or #endif, in some cases closing brace ‘}’, etc…
continue parsing until we are done.
Swift SVN r24822
- Closures that are comprised of only a single return statement are now considered to be "single expression" closures. (rdar://problem/17550847)
- Unannotated single expression closures with non-void return types can now be used in void contexts. (rdar://problem/17228969)
- Situations where a multi-statement closure's type could not be inferred because of the lack of a return-type annotation are now properly diagnosed. (rdar://problem/17212107)
I also encountered a number of crashers along the way, which should now be fixed.
Swift SVN r24817
They don't work properly, and if we want eager static initialization,
we'll add a Swift feature for it. Fixes rdar://problem/18423731.
Swift SVN r24814
This was one of our most visible user-facing crashers, manifesting itself any time a user performed an equality comparison on an unresolved enum case.
Swift SVN r24753
Instead, just check the generic parameters, then do a lookup as usual in the
enclosing context.
Fixes crash suite #58 and quite a few others (~200). This looks way more
impressive than it is; in most of these test cases it's the exact same
pattern causing the crash, and that pattern was just the last outstanding
crash trigger in a sea of garbage. (The few deleted tests were identical
to #58.)
Swift SVN r24748
func a(b: Int = 0) {}
let c = a // should be (b: Int) -> Void, not (b: Int = 0) -> Void
Fixes crash suite #23.
rdar://problem/18232797
Swift SVN r24747
Local type declarations are saved in the source file during parsing,
now serialized as decls. Some of these may be defined in DeclContexts
which aren't Decls and previously weren't serialized. Create four new
record kinds:
* PatternBindingInitializer
* DefaultArgumentInitializer
* AbstractClosureExpr
* TopLevelCodeDecl
These new records are used to only preserve enough information for
remangling in the debugger, and parental context relationships.
Finally, provide a lookup API in the module to search by mangled name.
With the new remangling API, the debugging lifecycle for local types
should be complete.
The extra LOCAL_CONTEXT record will compressed back down in a
subsequent patch.
Swift SVN r24739
with more explicit/semantic conversions in and out.
Using a PointerUnion with overlapping pointer types
is both error-prone and pretty close to illegible.
Swift SVN r24707
Aside from tidying things up, doing this results in some significant benefits:
- Allows for global constraint ordering optimizations over a given expression, not just on a peephole basis.
- Eliminates a set of order-dependent bugs in the solver that have been dogging us for a while. (rdar://problem/19459079)
- Brings another set of tyvar-to-tyvar solving problems out of the realm of the exponential. (rdar://problem/19005271)
- Opens up the possibility of optimizing constraints during later solving phases - not just while generating them.
Swift SVN r24693
Previously, adding observing accessors to a variable caused it to require
an explicit type /and/ an initializer. Now you just need one or the other;
the type of the accessors is drawn from the type of the VarDecl, whether
inferred or explicitly written.
rdar://problem/18148072
Swift SVN r24664
Before:
error: use of module 'Foo' as a type
After:
error: use of undeclared type 'Foo'
note: cannot use module 'Foo' as a type
Improves on rdar://problem/17763309 a little.
Swift SVN r24564
Fix diagnostics for 'as' and 'as!' expressions by ensuring that the
conversion constraint used to generate them actually corresponds to the
expression in question. Add tests from 19495142.
Swift SVN r24547
Rather than keeping just a "main class" in every module, track the "main file"
that's responsible for producing the module's entry point. This covers both
main source files and files containing classes marked @UIApplicationMain or
@NSApplicationMain.
This should have no functionality change, but is preparation for the next
commit, where we will preserve some of this information in serialization.
Swift SVN r24529
Curried function parameters (i.e., those past the first written
parameter list) default to having argument labels (which they always
have), but any attempt to change or remove the argument labels would
fail. Use the fact that we keep both the argument labels and the
parameter names in patterns to generalize our handling of argument
labels to address this problem.
The IDE changes are due to some positive fallout from this change: we
were using the body parameters as labels in code completions for
subscript operations, which was annoying and wrong.
Fixes rdar://problem/17237268.
Swift SVN r24525
Also, these changes fix the performance regressions that were introduced as a result of September's convertible/init requirement modifications, and allow us to roll back the associated workarounds that were added to the Adventure sample (rdar://problem/18942100).
Swift SVN r24520
