Print diagnostic groups as part of the LLVM printer in the same manner as the
Swift one does, always. Make `-print-diagnostic-groups` an inert option, since we
always print diagnostic group names with the `[#GroupName]` syntax.
As part of this, we no longer render the diagnostic group name as part
of the diagnostic *text*, instead leaving it up to the diagnostic
renderer to handle the category appropriately. Update all of the tests
that were depending on `-print-diagnostic-groups` putting it into the
text to instead use the `{{documentation-file=<file name>}}`
diagnostic verification syntax.
`AvailabilityRange` is now being used as a currency type in more of the
compiler, and some of those uses are in permanent `ASTContext` allocations. The
class wraps the `VersionRange` utility, which is itself a wrapper around
`llvm::VersionTuple` with some additional storage for representing sentinel
values. Even though the two sentinel values can be be represented with just a
single bit of additional storage on top of the 16 bytes required to represent
`VersionTuple`, because of alignment requirements the sentinel values end up
bloating the layout of `VersionRange` by many bytes.
To make `AvailabilityRange` and `VersionRange` more efficient to store, we can
instead reserve two unlikely `llvm::VersionTuple` bit patterns as the sentinel
values instead. The values chosen are the same ones LLVM uses to represent
version tuple tombstones and empty keys in a `DenseMap`.
This simplifies the code to emit availabilty diagnostics and ensures that they
display domain names consistently. While updating existing diagnostics, improve
consistency along other dimensions as well.
This will unblock parsing and type-checking availability queries that specify
custom availability domains, e.g.:
```
if #available(CustomDomain) {
// Use declarations protected by @available(CustomDomain)
}
```
Implement lookup of availability domains for identifiers on
`AvailabilityDomainOrIdentifier`. Add a bit to that type which represents
whether or not lookup has already been attempted. This allows both
`AvailableAttr` and `AvailabilitySpec` to share a common implementation of
domain lookup.
In order to unblock resolution of availability domains during type-checking
instead of parsing, diagnostics about missing or superfluous wildcards in
availability specification lists need to move to Sema.
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.
