Instead, check them and their error handling right away.
In addition to fixing the crash in the radar, this also causes
us to emit unused variable warnings in functions containing
local functions.
Eventually, TC.definedFunctions should go away altogether.
Fixes <rdar://problem/53956342>.
This does several different things to improve how platforms are described in availability diagnostics:
• Mentions the platform in diagnostics for platform-specific @available(unavailable) attributes.
• Replaces “OS X” with “macOS”.
• Replaces “fooOS application extension” with “application extensions for fooOS”.
• Replaces “on fooOS” with “in fooOS”.
Fixes <rdar://problem/49963341>.
This makes diagnostics more verbose and accurate, because
it's possible to distinguish how many parameters there are
based on the message itself.
Also there are multiple diagnostic messages in a format of
`<descriptive-kind> <decl-name> ...` that get printed as
e.g. `subscript 'subscript'` if empty labels are omitted.
...and collapse StaticVar/ClassVar and StaticLet/ClassLet into
StaticProperty/ClassProperty.
"var" and "let" aren't great nouns to use in diagnostics to begin with,
especially alongside semantic terms like "instance method". Focus on
the type vs. non-type aspect instead with "property", which better
matches how people talk about member vars (and lets) anyway.
The code for performing the third pass using the GenericToArchetypeResolver
is still there, but it only runs for non-generic declarations.
The next step is to consolidate this path with the generic path.
Inherited designated initializers got the same availability
as the corresponding initialier in the superclass.
However if the superclass was more available than the subclass,
we would generate a diagnostic that a member cannot be more
available than its containing type.
This diagnostic had an unknown source location, since the
location was for a synthesized declaration, causing confusion.
Fixes <https://bugs.swift.org/browse/SR-7881> aka
<rdar://problem/40853731>.
That is, if there's a problem with a witness, and the witness comes
from a different extension from the conformance (or the original type,
when the conformance is on an extension), put the main diagnostic on
the conformance, with a note on the witness. This involves some
shuffling and rephrasing of existing diagnostics too.
There's a few reasons for this change:
- More context. It may not be obvious why a declaration in file
A.swift needs to be marked 'public' if you can't see the conformance
in B.swift.
- Better locations for imported declarations. If you're checking a
conformance in a source file but the witness came from an imported
module, it's better to put the diagnostic on the part you have
control over. (This is especially true in Xcode, which can't display
diagnostics on imported declarations in the source editor.)
- Plays better with batch mode. Without this change, you can have
diagnostics being reported in file A.swift that are tied to a
conformance declared in file B.swift. Of course the contents of
A.swift also affect the diagnostic, but compiling A.swift on its
own wouldn't produce the diagnostic, and so putting it there is
problematic.
The change does in some cases make for a worse user experience,
though; if you just want to apply the changes and move on, the main
diagnostic isn't in the "right place". It's the note that has the info
and possible fix-it. It's also a slightly more complicated
implementation.
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
