Access control, availability and exportability checking missed these
because of a baked-in assumption that getGenericParams() == nullptr
rules out the presence of a trailing where clause.
Concrete types can conform to unavailable protocols because
the witness table for the conformance is not required for use
with the concrete type itself.
However, protocols cannot have unavailable base protocols.
I believe this was an oversight of the original implementation
here.
This has the effect of rejecting unavailable overrides to available
methods in a similar way as overrides that are less available than the
introduction are rejected.
This affects module interfaces, interface generation in sourcekitd, and
diagnostics. Also fixes a fixit that was assuming the 'OSX' spelling when
computing the source range to replace.
Resolves rdar://problem/64667960
Most of the changes fall into a few categories:
* Replace explicit "x86_64" with %target-cpu in lit tests
* Cope with architecture differences in IR/asm/etc. macOS-specific tests
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
