When in Swift 3 compatibility mode without
`-warn-swift3-objc-inference`, warn on the *uses* of declarations that
depend on the Objective-C runtime that became `@objc` due to the
deprecated inference rule. This far more directly captures important
uses of the deprecated Objective-C entrypoints. We diagnose:
* `#selector` expressions that refer to one of these `@objc` members
* `#keyPath` expressions that refer to one of these `@objc` members
* Dynamic lookup (i.e., member access via `AnyObject`) that refers to
one of these `@objc` members.
...and make sure we're in that mode for SIL inputs and for sil-opt and
sil-extract, even when working with AST types and declarations rather
than SIL types.
Without this, we get zillions of deprecation warnings coming out of
the validation tests SIL/parse_stdlib_*.sil, which dump the standard
library and then attempt to re-parse it. This has been causing the
"long" tests to take, well, too long.
and provide a fix-it to move it to the new location as referenced
in SE-0081.
Fix up a few stray places in the standard library that is still using
the old syntax.
Update any ./test files that aren't expecting the new warning/fix-it
in -verify mode.
While investigating what I thought was a new crash due to this new
diagnostic, I discovered two sources of quite a few compiler crashers
related to unterminated generic parameter lists, where the right
angle bracket source location was getting unconditionally set to
the current token, even though it wasn't actually a '>'.
Remove the diagnostic that warns when an availability check is unnecessary
because the minimum deployment target ensures it will always be true. This
diagnostic is valuable (it tells users that they have dead fallback code) but
can also be super annoying when a source file is shared between projects with
different deployment targets. There is not currently a good mechanism to
suppress these warnings (for example, by expressing a "compatibility version" in
the source or as a build setting) and so it is better to turn the diagnostic
off.
rdar://problem/22337402
along with recent policy changes:
- For expression types that are not specifically handled, make sure to
produce a general "unused value" warning, catching a bunch of unused
values in the testsuite.
- For unused operator results, diagnose them as uses of the operator
instead of "calls".
- For calls, mutter the type of the result for greater specificity.
- For initializers, mutter the type of the initialized value.
- Look through OpenExistentialExpr's so we can handle protocol member
references propertly.
- Look through several other expressions so we handle @discardableResult
better.
Try to match the original spelling of static/class in diagnostics and
when printing the AST. Also fixes cases with
PrintOptions.PrintImplicitAttrs = false, where we would just print
'class', which was not valid code.
Adds an associatedtype keyword to the parser tokens, and accepts either
typealias or associatedtype to create an AssociatedTypeDecl, warning
that the former is deprecated. The ASTPrinter now emits associatedtype
for AssociatedTypeDecls.
Separated AssociatedType from TypeAlias as two different kinds of
CodeCompletionDeclKinds. This part probably doesn’t turn out to be
absolutely necessary currently, but it is nice cleanup from formerly
specifically glomming the two together.
And then many, many changes to tests. The actual new tests for the fixits
is at the end of Generics/associated_types.swift.
This reflects the fact that the attribute's only for compiler-internal use, and isn't really equivalent to C's asm attribute, since it doesn't change the calling convention to be C-compatible.
We currently emit diagnostics for references to deprecated and potentially
unavailable APIs in branches that are dead for the current platform and
minimum deployment target. These dead branches can arise when sharing swift
source between targets or in playgrounds intended to be run on multiple OS
versions.
So for example, suppose the developer has the following code targeting
OSX 10.9+ and iOS 8.0+:
if #available(OSX 10.10, *) {
// Use replacement API introduced in OSX 10.10/iOS 8.0
} else {
// Use old API deprecated in OSX 10.10/iOS 8.0
}
Compiling the above for iOS and with a miniminum deployment of 8.0 will
result in a deprecation diagnostic for the use of the API in the else branch
even though that branch will never execute. (Note that the branch is not dead on
the OSX target because the minimum deployment target is 10.9. For OSX we also
won't emit a deprecation warning because the API wasn't deprecated until 10.10.
This commit updates availability checking to create refinement contexts with
empty OS version ranges for #available() else branches when those branches
will definitely not execute. It suppresses deprecation and potential
availability diagnostics within those contexts. It does not suppress diagnostics
for references to APIs annotated as unconditionally unavailable (i.e., with
@available(OSX, unavailable, ...) and friends).
rdar://problem/22307360
Swift SVN r31631
This changes the diagnostic text when a variable cannot be marked potentially unavailable
so that it does not explicitly use the long-style form of @available:
It changes:
"stored properties cannot be marked potentially unavailable with 'introduced='"
to:
"stored properties cannot be marked potentially unavailable with '@available'"
Swift SVN r30446
We were skipping building refinement contexts for function declarations without bodies
(such as protocol requirements and @asmname functions). These contexts are needed to
determine whether parameter and return types are available in those declaration.
Swift SVN r30380
It is safe to add an @available attribute to lazy properties, so suggest a
Fix-It to do so if the property references a potentially unavailable symbol.
rdar://problem/20968204
Swift SVN r30321
Update the diagnostic emitted when an accessor override is less available than the
declaration it overrides to mention the accessor kind and the name of the property rather
than just the accessor declaration name, which is '_'.
rdar://problem/20427938
Swift SVN r30319
Now that we allow types to conform to protocols that are less available than the
type itself, we should consider the availability of the protocol when
determining whether a witness is sufficiently available to satisfy the protocol
requirement.
In particular, we should allow the following:
@available(iOS 9.0, *)
class UIRefrigerator { }
@available(iOS 9.0, *)
protocol UIRefrigeratorDelegate {
func refrigeratorDidCool(refrigerator: UIRefrigerator)
}
@available(iOS 7.0, *)
class MyViewController : UIViewController, UIRefrigeratorDelegate {
@available(iOS 9.0, *)
func refrigeratorDidCool(refrigerator: UIRefrigerator) {
...
}
}
This is safe because MyViewController's refrigeratorDidCool() witness is
available everywhere the protocol is available. To check this, we now
additionally intersect the availability of the protocol with the availabilities
of the witness and the requirement before checking containment.
Swift SVN r29996
The previous rules for availability checking prevented types from conforming to protocols
that were less available than the type itself. This was too restrictive, because we want
to allow developers to add additional behavior to their existing classes to
conform to new protocols while still employing older functionality from those classes on
older OSes:
@available(iOS 9.0, *)
protocol UIRefrigeratorDelegate { }
@available(iOS 8.0, *)
class MyViewController : UIViewController, UIRefrigeratorDelegate { }
We now support this idiom (and adding conformnces via protocol extensions) by allowing
references to potentially unavailable protocols inside inheritance clauses.
It is still an availability error to refer to potentially unavailable protocols in other
settings -- so, for example, attempting to cast to an unavailable protocol will cause
a compile-time error.
rdar://problem/21718497
Swift SVN r29958
Change the fix-it suggesting adding #available to be consistent with the fix-it
adding @available.
This changes "guard with version check" to "add if #available version check".
rdar://problem/21275857
Swift SVN r29648
As Jordan notes, this uses the wrong check: isScriptMode() is also true for
main.swift in an app or command-line tool.
This reverts commit 8a72f4357bc04a386cf82acd1de06896515ab5a8.
Swift SVN r29583
We normally report a warning when a #available() check will always be true
because of the minimum deployment target. These warnings are potentially
annoying when the developer either cannot change the minimum deployment target
from the default (as in playgrounds) or when doing so is burdensome (as for
command-line scripts, which would require passing a target triple) -- so
suppress them.
rdar://problem/21324005
Swift SVN r29582
This prevents us from seeing a less useful error message from SILGen
further down the line.
Also fix a bug where @objc without importing Foundation was not diagnosed
after the first top-level form. Some tests were relying on this behavior,
so fix those tests, either by splitting off the objc parts of the test, or
just by passing the -disable-objc-attr-requires-foundation-module flag.
Fixes <rdar://problem/20660270>.
Swift SVN r29359
If 'x.init' appears as a member reference other than 'self.init' or 'super.init' within an initializer, treat it as a regular static member lookup for 'init' members. This allows a more explicit syntax for dynamic initializations; 'self.someMetatype()' looks too much like it's invoking a method. It also allows for partial applications of initializers using 'someMetatype.init' (though this needs some SILGen fixes, coming up next). While we're in the neighborhood, do some other correctness and QoI fixes:
- Only lookup initializers as members of metatypes, not instances, and add a fixit (instead of crashing) to insert '.dynamicType' if the initializer is found on an instance.
- Make it so that constructing a class-constrained archetype type correctly requires a 'required' or protocol initializer.
- Warn on unused initializer results. This seems to me like just the right thing to do, but is also a small guard against the fact that 'self.init' is now valid in a static method, but produces a newly-constructed value instead of delegating initialization (and evaluating to void).
Swift SVN r29344
Instead of the rather inscrutable "'foo()' is less available than protocol requires" be
more helpful: "protocol 'HasFoo' requires 'foo()' to be available on OS X 10.9 and newer".
Also add a note indicating where the conformance was introduced, as this may be in a
separate location from both the witness and requirement.
rdar://problem/20610411
Swift SVN r29028
The type refinement context builder now handles the case where multiple refinement
contexts have scopes ending after the same statement. This fixes a crash when we had
two guard #available()s in the same block.
rdar://problem/21012706
Swift SVN r28763
Allow availability attributes of the form:
@available(iOS 8.0, OSX 10.10, *)
func foo() { }
This form is intended for use by third-party developers when annotating their
own declarations and uses the same syntax as #available(). This annotation
says that on iOS foo() is available on version 8.0 and newer; on OSX it is
available on 10.10; and on any other un-mentioned platform it considered
available on the minimum deployment target and greater. Just like with
For now, we support this form during parsing by synthesizing multiple implicit
long-form @available attributes. So, for example, the above annotation will
synthesize two implicit attributes:
@available(iOS, introduced=8.0)
@available(OSX, introduced=10.10)
func foo() { }
Synthesizing attributes in this way is not ideal -- it makes for a poor Fix-It
experience, among other things -- but it exposes the short-form syntax with
minimal invasiveness.
rdar://problem/20938565
Swift SVN r28647
In anticipation of adding short-form @available() annotations, move validation
of #available() platform/version lists out of Sema and into the parser. This
also enables slightly more graceful recovery from errors.
Swift SVN r28637
This allows #available() to be used in the guard condition of a while loop:
while i > 10, #available(iOS 8.0, *) {
// Use APIs available on iOS 8.0 and above.
}
rdar://problem/20936160
Swift SVN r28623
Stop suggesting Fix-Its to add @available() to stored properties. We don't allow this
yet, so the "fixed" code would still emit an error when compiled.
rdar://problem/20939804
Swift SVN r28604
instead of being an expression.
To the user, this has a couple of behavior changes, stemming from its non-expression-likeness.
- #available cannot be parenthesized anymore
- #available is in its own clause, not used in a 'where' clause of if/let.
Also, the implementation in the compiler is simpler and fits the model better. This
fixes:
<rdar://problem/20904820> Following a "let" condition with #available is incorrectly rejected
Swift SVN r28521
This came out of today's language review meeting.
The intent is to match #available with the attribute
that describes availability.
This is a divergence from Objective-C.
Swift SVN r28484
We now introduce a TypeRefinementContext for the fallthrough branch of a require/else
statement that continues until the end of the BraceStmt that contains the RequireStmt. The
body of the else is checked in the context that contains the RequireStmt.
This enables availability checking with early return:
require #available(iOS 8.0, *) else { return }
Swift SVN r28113
