This logic was introduced in https://github.com/swiftlang/swift/pull/75135.
The intent was to prevent an implied conformance from overriding an
existing unavailable one, for example in the case of Sendable. Let's
relax this check a bit to only diagnose if the mismatch is in the
unconditional availability, and not OS version.
Fixes rdar://142873265.
When type checking a .swiftinterface file, Assume that a mutating methods does
not depend on its parameters. This is unsafe but needed because some
MutableSpan APIs snuck into the standard library interface without specifying
dependencies.
Fixes rdar://148697444 error: a mutating method with a ~Escapable 'self' requires '@lifetime(self:
...)'
(cherry picked from commit a86fe4fa30)
Most SDKs use only swiftinterfaces under usr/lib/swift. Let's make sure
we standardize this behavior and use only swiftinterface when they are
present, even if there are also binary swiftmodule files available.
Apply the same logic to SubFrameworks as well while we're at it.
rdar://145316821
An `AvailableAttr` written in source with an unrecognized availability domain
is now only marked invalid after type-checking the attribute. This resulted in a
regression where `CaseIterable` synthesis was blocked incorrectly under the
following very narrow circumstances:
1. Every `@available` attribute on the elements of the enum is invalid.
2. The module is being emitted and lazy type-checking is enabled.
3. The enum is public and the only top-level declaration in the file.
Type-checking the attribute was delayed just enough that it would not be
considered invalid by the type the `CaseIterable` conformance was being
synthesized, resulting in a spurious error.
There were zero tests exercising `CaseIterable` synthesis for enums with
elements that have availability requirements, so I added some.
Resolves rdar://144897917.
10.50 was once greater than any real macOS version, but now it compares
less than real released versions, which makes these tests depend on the
deployment target unnecessarily. Update these tests to use even larger
numbers to hopefully keep them independent a little longer.
When `-warn-on-potentially-unavailable-enum-case` was introduced, the build
system was required to invoke `swift-frontend` at artificially low deployment
targets when emitting `.swiftinterface` files for legacy architectures. Because
the deployment target was low, some availability diagnostics needed to be
de-fanged in order to allow module interface emission to succeed. Today, the
build system is able to use the correct deployment target when emitting module
interfaces and the `-warn-on-potentially-unavailable-enum-case` is superfluous,
so deprecate it.
Resolves rdar://114092047
The original bug was a crash-on-invalid with a missing '}', but it
actually exposed a bug with nested protocols (SE-0404) and another
long-time bug.
- Whatever we do, we should skip this for protocols because their 'Self'
parameter is not bound from context.
- getTrailingWhereClause() is not the right proxy for "has a generic
signature different than its parent", in particular it doesn't
round-trip through serialization. Instead, just compare generic
signatures for pointer equality in the early return check.
The second change is source-breaking because it was possible to
write a nested type with a `where` clause and use it contradicting
its requirements across a module boundary.
Fixes rdar://113103854.
SE-390 concluded with choosing the keyword discard rather than forget for
the statement that disables the deinit of a noncopyable type. This commit
adds parsing support for `discard self` and adds a deprecation warning for
`_forget self`.
rdar://108859077
We can't implement `forget` unless if we know all of the fields
in the type, so it cannot be resilient at all. We go further and
say that you can only `forget` from the same module, since that's
what the proposal currently states. If needed we can loosen that
in the future.
- Unapplied functions: `if #_hasSymbol(foo(_:))`
- Member references: `if #_hasSymbol(a.x)`
- `.self` expressions on static metatypes: `if #_hasSymbol(SomeEnum.self)`
- Dot syntax call expressions with unapplied functions: `if #_hasSymbol(SomeType.init(_:)`
Additionally, we diagnose when the concretely referenced declaration is not weak linked since this likely indicates that the programmer misidentified the declaration they wish to check or the build is not configured in a way such that the check will be meaningful.
Resolves rdar://99826340
Consider both frameworks and free floating modules imported from more
private path as SPI. This will make the compiler raise errors on public
imports of more private modules.
rdar://91904154
Diagnostics of public imports of private modules are more likely to be
wrong about imports of the underlying module from a Swift overlay due to
project configuration/installation, or the fact that private overlays
are installed in the same folder as public ones. Let's always downgrade
these diagnostics to warnings to help landing the rest of the
diagnostics as errors.
rdar://87262431
There are two pieces here:
- A -warn-on-potentially-unavailable-enum-case flag is passed down by
the driver when *producing* a swiftinterface
- When *consuming* a swiftinterface, also enable this behavior
Part of rdar://problem/78306593.
If a conformance is found in an imported module as well as the current module,
and one of the two conformances is conditionally unavailable on the current
deployment target, pick the one that is always available.
Fixes <rdar://problem/78633800>.
This will allow teams writing access notes to use -Raccess-note=all-validate to check that their access notes are correct, or teams working around problems to use -Raccess-note=failures or -Raccess-note=none to suppress diagnostics.
Intro the concept of library access or distribution level to identify
layers of libraries and report public imports of private libraries from
public ones.
rdar://62934005
The LLVM rebranch added an “AllowUnknownKeys” setting to llvm::yaml::Input, which lets us rip out a lot of marginal code and encourages a broader rework of access note error diagnosis:
• Access note warnings and errors are now diagnosed as they’re found during YAML parsing
• They now have proper SourceLocs inside the .accessnotes file
• They’re now tested using -verify-additional-file instead of FileCheck
• A lot of gross duct tape is now gone
LLVM’s YAML support wants to show a hard error if an unknown string appears in an access note. Instead, emit a remark but load the parts of the access note we do understand to allow for future expansion of access notes.
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.
Mention the type, the requirement, and the extension in the error that
follows. In editor mode, try to insert stubs for the missing requirement
as well so the user isn't just left with a pile of unactionable errors.
A recent change to witness matching in #32578 suddenly made the
following construction illegal:
// File1.swift
enum MyEnumInAnotherFile { /**/ }
// File2.swift
extension MyEnumInAnotherFile {
static var allCases: [MyEnumInAnotherFile] { /**/ }
}
Because it was no longer possible to derive the type witness for
`AllCases`. This is because, when inference ran before synthesis, we
would use the value witness to pick out the type witness and thus had no
need for synthesis. Now that we run synthesis first, we ought to just
allow deriving type witnesses across files, but still ban deriving value
witnesses. In general, if you can utter a type in a different file to
extend it, you should be able to see the requirements necessary to
derive a default type witness.
rdar://66279278, rdar://66279375, rdar://66279384, rdar://66279415, rdar://66279503
We already ban all structs from declaring storage that comes from implementation-only imports. Until now we missed property wrappers, they were just dropped in deserialization.
Resolves rdar://problem/59403617
This commit changes the behaviour of the error for
passing a temporary pointer conversion to an
@_nonEphemeral parameter such that it doesn't
affect overload resolution. This is done by recording
the fix with an impact of zero, meaning that we don't
touch the solution's score.
In addition, this change means we no longer need
to perform the ranking hack where we favour
array-to-pointer, as the disjunction short-circuiting
will continue to happen even with the fix recorded.
Diagnose ephemeral conversions that are passed to @_nonEphemeral
parameters. Currently, this defaults to a warning with a frontend flag
to upgrade to an error. Hopefully this will become an error by default
in a future language version.
Instead of computing it from the extended type after deserialization --
which is tricky to do, due to potential presence of protocol
compositions -- we obtain the extended nominal directly.
Fixes SR-11227 and linked rdar://problem/53712389.
Introduce callables: values of types that declare `func callAsFunction`
methods can be called like functions. The call syntax is shorthand for
applying `func callAsFunction` methods.
```swift
struct Adder {
var base: Int
func callAsFunction(_ x: Int) -> Int {
return x + base
}
}
var adder = Adder(base: 3)
adder(10) // desugars to `adder.callAsFunction(10)`
```
`func callAsFunction` argument labels are required at call sites.
Multiple `func callAsFunction` methods on a single type are supported.
`mutating func callAsFunction` is supported.
SR-11378 tracks improving `callAsFunction` diagnostics.
