The compiler treats version tuples that are all zeros as empty, or the same as
not having a version. Diagnose attempts to specify all-zeroes versions in
attributes and availability queries to prevent surprising behavior.
Resolves rdar://124661151
Unavailable decls cannot be overridden by available decls. This change improves
the compiler diagnostics for this restriction in a few ways:
- Duplicate diagnostics are suppressed for getters and setters inside property
declarations that have already been diagnosed.
- Diagnostics are suppressed for implicit accessors since they would typically
duplicate diagnostics for the explicit accessors the implicit ones are
derived from.
- Decls inside unavailable a derived class are no longer incorrectly diagnosed.
When a no-args init is the only designated init in the superclass, Swift will automatically
call it from the subclass. Unfortunately, if this initializer is
unavailable, an error is issued that points at the subclass' init but
makes no mention of the implicit call. Fix that by providing a note that
explains what's going on here.
We used to diagnose references to unavailable declarations in
two places:
- inside Exprs, right after type checking the expression
- inside TypeReprs, from resolveType()
In broad terms, resolveType() is called with TypeReprs
stored inside both Stmts and Decls.
To handle the first case, I added a new overload of
diagAvailability() that takes a Stmt, to be called from
typeCheckStmt(). This doesn't actually walk into any Exprs
stored inside the statement; this means it only walks
Patterns and such.
For the second case, a new DeclAvailabilityChecker is
now defined in TypeCheckAccess.cpp. It's structure is
analogous to the other three walkers there:
- AccessControlChecker
- UsableFromInlineChecker
- ExportabilityChecker
The new implementation of availability checking for types
introduces a lot more code than the old online logic
it replaces. However, I hope to consolidate some of the
code duplication among the four checkers that are defined
in TypeCheckAccess.cpp, and do some other cleanups that
will make the benefit of the new approach apparent.
This change permits a subclass to redeclare an unavailable member from a superclass. For instance, suppose you write this code (or, more likely, a version where `Base` is an ObjC class):
```swift
class Base {
@available(*, unavailable) init() {}
}
class Derived: Base {
/* override */ init() {}
}
```
Previously, Swift would reject `Derived.init()` without the `override` keyword, telling you that you should add it, but it would also reject it *with* the `override` keyword, telling you that you can't override something that's unavailable. This PR makes Swift accept it without the `override` keyword; declaring it with the keyword is still forbidden.
Fixes rdar://65702529.
This change permits the use of unavailable types in unavailable signatures.
It affects only usage of `available(*, unavailable)`.
This fixes a compilation error in swift-corelibs-foundation/Foundation/
URLSession/URLSessionConfiguration.swift where an unavailable property
was typed by an unavailable type.
This change permits the use of unavailable types in unavailable signatures.
It affects only usage of `available(*, unavailable)`.
This fixes a compilation error in swift-corelibs-foundation/Foundation/
URLSession/URLSessionConfiguration.swift where an unavailable property
was typed by an unavailable type.
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.
This is still useful for the feature where deprecated declarations are
allowed to be used within a context that's marked deprecated. There's
probably a better balance to be found here, because marking the
extension deprecated still does not mark all the members deprecated,
but for now it still has an effect, and we shouldn't produce a warning
for legitimately making use of that effect.
The warning was added in f21d9f332, mostly as an opportunity "fix".
https://bugs.swift.org/browse/SR-7577
This handles the case where one accessor is /unavailable/ but not the
other. This is rarer than deprecation (handled in b0e12f4c), but could
still happen.
Finishes rdar://problem/18633725 / SR-7201.
This handles the case where just one accessor is deprecated but not
the other, which does come up sometimes in Apple's frameworks.
rdar://problem/18633725
Previously, we treated this as an attempt to widen the availability
of a member beyond its context, but it's really a different axis of
availability.
Also, warn about using @available on extensions without an OS, which
we just completely ignore right now.
rdar://problem/32632327
This flips the switch to have @noescape be the default semantics for
function types in argument positions, for everything except property
setters. Property setters are naturally escaping, so they keep their
escaping-by-default behavior.
Adds contentual printing, and updates the test cases.
There is some further (non-source-breaking) work to be done for
SE-0103:
- We need the withoutActuallyEscaping function
- Improve diagnostics and QoI to at least @noescape's standards
- Deprecate / drop @noescape, right now we allow it
- Update internal code completion printing to be contextual
- Add more tests to explore tricky corner cases
- Small regressions in fixits in attr/attr_availability.swift
What I've implemented here deviates from the current proposal text
in the following ways:
- I had to introduce a FunctionArrowPrecedence to capture the parsing
of -> in expression contexts.
- I found it convenient to continue to model the assignment property
explicitly.
- The comparison and casting operators have historically been
non-associative; I have chosen to preserve that, since I don't
think this proposal intended to change it.
- This uses the precedence group names and higherThan/lowerThan
as agreed in discussion.
It is currently impossible to declare a protocol as unavailable and
still ship valid Swift code because while typechecking protocol Self,
we attempt to do an accessibility check on its generic signature and
find that, surprise surprise, the protocol is unavailable. Rather than
plumb another parameter through Sema, this patch piggybacks on existing
behavior of AllowPotentiallyUnavailableProtocol to disable the check
for protocol self.
* [Fixit] Add a fixit for converting non-trailing closures to trailing closures.
* [test] Update test to reflect the added note about converting to trailing closures.
This can be used as QoI for things like 'NSASCIIStringEncoding', which
is going to canonically be `String.Encoding.ascii` if/when SE-0086 is
accepted.
We can't actually handle this in NS_SWIFT_NAME (that is, we can't
/import/ something onto a nested type), but that's okay: we already
have stricter limitations on NS_SWIFT_NAME enforced by Clang.
rdar://problem/26352374
We were failing to create an unavailable TypeAlias for the old name
in the case the renamed type was generic, leading to poor diagnostics.
Also, Sema resolves generic TypeAliases very early, while building
a Type from a TypeRepr -- this means the unavailable/deprecated
check runs too late to catch generic TypeAlises.
Add a hack where we preserve a reference to the original TypeAliasDecl
by way of constructing a SubstitutedType which desugars to the
replacement type, rather than resolving the replacement type
directly, so that the availability check can pick it up.
A better fix for this would be to introduce a BoundGenericAliasType
sugared type, but that's a bigger change that can come later.
Fixes <rdar://problem/26206263>.
...or renaming to operators, unless we're sure the original thing was
an operator expression. There are just a lot of ways this can be
screwed up.
(Some cases of this can certainly be implemented. I may file a
StarterBug later.)
