The Objective-C method corresponding to a throwing method has an extra
error parameter; note that within the arity mismatch diagnostic to
reduce head-scratching.
Swift SVN r27277
When computing an Objective-C selector for a throwing method,
introduce an "error:" selector piece at the location specified by the
foreign error convention. If it's part of the first selector piece,
append "WithError" to the method base name.
Also require the manually-specified @objc(selector) of a throwing
method to include a selector piece for the error parameter.
Swift SVN r27276
Enable checking for uses of potentially unavailable APIs. There is
a frontend option to disable it: -disable-availability-checking.
This commit updates the SDK overlays with @availability() annotations for the
declarations where the overlay refers to potentially unavailable APIs. It also changes
several tests that refer to potentially unavailable APIs to use either #available()
or @availability annotations.
Swift SVN r27272
For any @objc method, attach either the foreign error convention we inherit
from an overridden method (if available) or the foreign error
convention we computed as part of @objc validation.
Extend the AST dumper to dump the foreign error convention so that we
can test this.
Swift SVN r27267
Throwing @objc methods need to get mapped down to the Objective-C
runtime, so check that we can establish a foreign error convention for
them, and complain otherwise.
As a drive-by, don't allow any throwing function types to occur any
place else within @objc declarations.
Swift SVN r27259
FuncDecl::throws() is misleading because it only tells us whether the
'throws' keyword was present on the declaration. Since source
locations are lost during deserialization, it would give the wrong
result. Nobody was making this mistake now, but it's better not to
leave this trap in the ASTs.
Use AbstractFuncitonDecl::isBodyThrowing() to determine whether a
particular function (or initializer, eventually) can throw.
Swift SVN r27257
Make sure that a witness declaration is at least as available as
the protocol requirement declaration. This is analogous to requiring that an
override is at least as available as the base declaration.
We don’t use the RequirementMatch machinery to mark a candidate as unsafe but
rather let the witness be chosen and then diagnose for potential unavailability.
That is, potential unavailability will not affect the search for a candidate
witness to a requirement. This is less expressive (users cannot write a protocol
that selects an available implementation) but is more predictable.
Swift SVN r27256
A non-throwing function can be a trivial subtype of a throwing
function. Encode this rule more directly, introduce some additional
tests to ensure that we get the behavior right where we need exact
matches, and add a failure kind with custom diagnostic for cases where
function types mismatch due to 'throws'.
Swift SVN r27255
This is new attribute we're using to coalesce @thin, @objc_block, and @cc, and to extend to new uses like C function pointer types. Parse the new attribute, but preserve support for the old attributes, and print with the old attributes for now to separate out test changes. Migration fixits and test updates to come. I did take the opportunity here to kill off the '@cc(cdecl)' hack for AST-level function pointer types, which are now only spelt with @convention(c).
Swift SVN r27247
Consistently open all references into existentials into
opened-existential archetypes within the constraint solver. Then,
during constraint application, use OpenExistentialExprs to record in
the AST where an existential is opened into an archetype, then use
that archetype throughout the subexpression. This simplifies the
overall representation, since we don't end up with a mix of operations
on existentials and operations on archetypes; it's all archetypes,
which tend to have better support down the line in SILGen already.
Start simplifying the code in SILGen by taking away the existential
paths that are no longer needed. I suspect there are more
simplifications to be had here.
The rules for placing OpenExistentialExprs are still a bit ad hoc;
this will get cleaned up later so that we can centralize that
information. Indeed, the one regression in the compiler-crasher suite
is because we're not closing out an open existential along an error
path.
Swift SVN r27230
For now, disallow potential unavailability on stored properties. We will
eventually want to support this. Unfortunately, doing so will require changes to
definite initialization and (probably) deinitialization.
This is the same as the reverted r27216 except that it does not suggest a FixIt
to make the property lazy.
Swift SVN r27223
For now, disallow potential unavailability on stored properties. We will
eventually want to support this. Unfortunately, doing so will require changes to
definite initialization and (probably) deinitialization.
We can safely support potential unavailability on lazily initialized
properties (and statics), so suggest a Fix-It that adds a lazy attribute when
the property declaration allows for it.
Swift SVN r27216
We may want to use optimized ErrorType representations that don't naturally "become" NSErrors, such as tagged-pointer representations of small error enums, or a tagged function pointer to a deferred error type constructor. Rename the runtime function to something a bit more descriptive of its real purpose, not its implementation.
Swift SVN r27209
Remove the suppression of deprecation and potential unavailability diagnostics in
synthesized functions. We still suppress some explicit unavailability diagnostics -- those
in synthesized functions in synthesized functions that are lexically contained in
declarations that are themselves annotated as unavailable. For these cases, the right
solution <rdar://problem/20491640> is to not synthesize the bodies of these functions in
the first place.
rdar://problem/20024980
Swift SVN r27203
Suppress diagnostics about references to unavailable declarations when all
of the following conditions are met:
(1) the reference is in synthesized code;
(2) the reference is in a synthesized method; and
(3) the reference is inside a declaration marked as unavailable.
This, combined with prior work to infer availability annotations for synthesized
methods should eliminate the spurious diagnostics we have seen (e.g.,
rdar://problem/20154926) for references to unavailable types without the hammer
of suppressing all references to unavailable declarations in synthesized
functions. The right thing to do here is to not synthesize the bodies of these
functions in the first place. I've filed <rdar://problem/20491640> to track
this.
We will continue to emit an error for references to unavailable declarations
in non-implicit code, even if the reference is inside a declaration marked
unavailable.
Swift SVN r27197
Previously, we were only opening the existentials as part of
constraint application, which involved some ugly, redundant code. This
should be NFC because it's just moving the existential opening
operation earlier, but it's a step toward opening up all existential
references.
Swift SVN r27190
A common operation for availability checking is determining whether some
lexically enclosing declaration matches a condition. This commit factors
out that logic. NFC.
Swift SVN r27181
This unblocks standard library work by preventing us from going exponential when extending existing struct types to have failable initializers. (rdar://problem/20336356)
On my laptop, it also results in a 7% end-to-end improvement in the time it takes to run our unit tests under DebugAssert (previously: 591.63s, now: 552.64s). Though, as usual, YMMV.
Swift SVN r27156
In source files that are in script mode, global variable initialization
expressions are eagerly executed. For this reason, disallow @availability
attributes having 'introduced=' on script-mode globals.
I had to rejigger a fair number of potential unavailability tests because they
weren't written with this distinction in mind.
Swift SVN r27137
Remove some unnecessary boilerplate when working with ExprRewriter and
eliminate some closeExistential() call sites that are no longer
useful. NFC.
Swift SVN r27107
Place OpenExistentialExprs for references to lvalue subscripts or properties
(in protocol extensions) via existentials just outside of the member
or subscript reference, rather than far outside the expression. This
gives us a tighter bound on the open-existential expressions without
introducing the post-pass I was threatening.
OpenExistentialExprs just outside of lvalue member/subscript are
themselves lvalues. Resurrect John's OpenOpaqueExistentialComponent to
handle the opening of a (materialized) existential lvalues as an
lvalue path component. This has the nice effect of codifying the
formal access rules for opened existentials as well as handling inout
on opened existentials appropriately.
Big thanks to John for talking through the model with me and leaving
dead code around for me to use.
Swift SVN r27105
If a conformance to _BridgedToObjectiveC is statically known, generate a more efficient code by using the newly introduced library functions for bridging casts.
This covers the cases arising from the source code, but does not cover any casts resulting from SIL optimizations. Those will be covered by the subsequent commit.
This change is to stay in CSApply for now. But the plan is to make the bridged casts optimization a guaranteed optimization. Once it is done, there is no need to lower the bridged casts in a special way inside Sema, because they all can be handled by the optimizer in a uniform way. This would apply to bridging of Error types too.
Swift SVN r27101
These aren't really orthogonal concerns--you'll never have a @thick @cc(objc_method), or an @objc_block @cc(witness_method)--and we have gross decision trees all over the codebase that try to hopscotch between the subset of combinations that make sense. Stop the madness by eliminating AbstractCC and folding its states into SILFunctionTypeRepresentation. This cleans up a ton of code across the compiler.
I couldn't quite eliminate AbstractCC's information from AST function types, since SIL type lowering transiently created AnyFunctionTypes with AbstractCCs set, even though these never occur at the source level. To accommodate type lowering, allow AnyFunctionType::ExtInfo to carry a SILFunctionTypeRepresentation, and arrange for the overlapping representations to share raw values.
In order to avoid disturbing test output, AST and SILFunctionTypes are still printed and parsed using the existing @thin/@thick/@objc_block and @cc() attributes, which is kind of gross, but lets me stage in the real source-breaking change separately.
Swift SVN r27095
To properly deal with mutating methods on protocol extensions accessed through an existential (such as a property or subscript setter), open the existential as an lvalue so that its value can be mutated.
As part of this, make sure we form any OpenExistentialExprs at the top level of the expression if we didn't manage to build them sooner. This is a fairly ad hoc approach that I am not happy with (these could probably be placed better with a post-pass), but the cost of opening too early is fairly minimal.
Swift SVN r27068
Improves the placement of open-existential expressions when accessing
a property or subscript declared in a protocol extension. We need to
delay until the load occurs when the property/subscript has a usable
setter.
Swift SVN r27064
This is the new and improved version of
__attribute__((annotate("swift1_unavailable"))), with the "improved" being
specifically that the 'availability' attribute supports a message.
This requires a corresponding Clang commit.
Swift side of rdar://problem/18768673.
Swift SVN r27053
"Autoclosure" is uninteresting to SIL. "noescape" isn't currently used by SIL and we shouldn't have it until it has a meaningful effect on SIL. "throws" should be adequately represented by a SIL function type having an error result.
Swift SVN r27023
The set of attributes that make sense at the AST level is increasingly divergent from those at the SIL level, so it doesn't really make sense for these to be the same. It'll also help prevent us from accidental unwanted propagation of attributes from the AST to SIL, which has caused bugs in the past. For staging purposes, start off with SILFunctionType's versions exactly the same as the FunctionType versions, which necessitates some ugly glue code but minimizes the potential disruption.
Swift SVN r27022
Synthesize implicit @availability attributes to make sure that a synthesized
materializeForSet accessor is available enough to access the underlying storage and its
getter and setter.
These synthesized attributes could trigger redundant diagnostics when a subclass gives
overriding getters or setters non-contravariant availability. We detect when this
happens and suppress the redundant diagnostics.
This commit also improves availability diagnostics in synthesized code. We now respect
synthesized @availability annotations on containing DeclContexts when determining the
potential OS versions that could be executed at invalid SourceLocations.
Swift SVN r27002
The API review list found it confusing that if #os() and #if os() looked so similar, so
change the availability checking query to be spelled #available:
if #available(iOS >= 9.0, *) {
...
}
Swift SVN r26995
A "switch" can't be empty, so special-case the 'code' implementation for an empty ErrorType to just return zero. It doesn't really matter what the value is since the enum can't be instantiated.
Swift SVN r26992
