The type refinement context builder had a bunch of logic to try to
model type refinement contexts for the first variable declaration that
shows up within a pattern binding declaration. Instead, model this
more syntactically by creating a type refinement context for the
pattern binding declaration itself. This both addresses a regression
in the handling of `if #available` within a closure that's part of an
initializer, and fixes a bug in the same area where similar code has
explicit availability annotations.
Marking a stored property as unavailable with `@available` should be banned,
just like it already is banned for potential unavailability. Unavailable code
is not supposed be reachable at runtime, but unavailable properties with
storage create a back door into executing arbitrary unavailable code at
runtime:
```
@available(*, unavailable)
struct Unavailable {
init() {
print("Unavailable.init()")
}
}
struct S {
@available(*, unavailable)
var x = Unavailable()
}
_ = S() // prints "Unavailable.init()"
```
Resolves rdar://107449845
It turns out that we must allow declarations with `introduced:` availability
nested inside of other declarations that are `unavailable` in order to
influence weak linking. Stop diagnosing declarations as being more available
than their unavailable containers and revert some changes to availability
inference that were designed to avoid creating these nestings but caused
regressions for declarations marked `@_spi_available.`
Reverts parts of https://github.com/apple/swift/pull/64310,
https://github.com/apple/swift/pull/64015, and
https://github.com/apple/swift/pull/62900.
Previously, the following test case produced an erroneous diagnostic:
```
class A {
init() {}
}
@available(macOS 12, *)
class B: A {
@available(macOS 12, *)
override init() { // error: overriding 'init' must be as available as declaration it overrides
super.init()
}
}
```
The overridden `init()` constructor is as available as it can possibly be. Removing the explicit `@available` annotation suppressed the diagnostic.
To fix this, we check to see if the override is as available as its self type and accept it if it is.
You may be wondering how this works when the `@available` annotation is removed from `override init()` in the example. It turns out that `AvailabilityInference::availableRange()` returns a result that is based only on the explicit availability of the decl in question without taking the availability of the context into account (except when the context is an extension). So with the explicit annotation gone, both the base `init()` and the override are both considered to be "always" available. This is pretty unintuitive and arguably wrong. However, it seems like a lot of existing code depends on this behavior so I've left it for now.
Resolves rdar://96253347
Previously, `TypeChecker::checkDeclarationAvailability()` would behave this way for most explicitly unavailable decls by _accident_. An explicitly unavailable decl has no introduction version, and the existing logic therefore would fail to find a lower bound on the availability of the decl. The edge case that exposed the fragility of this logic was an unavailable extension containing a member with it's own explicit availability. The unavailability of the extension ought to trump the availability of the member, but the existing logic couldn't detect that.
The compiler also ought to diagnose the conflicting availability annotations but I'd like to address that separately.
Resolves rdar://92551870
We would only check conditioanlavailability once we had committed
to a best witness. Instead, let's use this information to disambiguate
among multiple best witnesses, if we have them.
Access control and unconditional unavailability are still only
checked once the witness is chosen.
Fixes rdar://problem/77259046.
This cannot be supported for the same reasons struct and class stored
properties with potential unavailability cannot be supported.
It is possible that some users relied on this, because it worked in
some cases where the type metadata for the potentially unavailable
type was not actually needed for anything (eg, if the type was @frozen
and trivial, or a simple class reference). If this becomes an issue
we can downgrade this to a warning.
Note that just like the previous fix for stored properties, we do
still allow writing an '@available' attribute on the enum element if
the OS version is not any newer than the deployment target. This allows
annotating APIs with the OS version where they were introduced.
We were checking that the witness is at least as available as
the intersection of the protocol and the conforming type.
In the case where the conformance is defined in an extension,
this should actually be the intersection of the protocol and
the _availability of the extension_.
Fixes <rdar://problem/74114880>.
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.
