* [CS] Decline to handle InlineArray in shrink
Previously we would try the contextual type `(<int>, <element>)`,
which is wrong. Given we want to eliminate shrink, let's just bail.
* [Sema] Sink `ValueMatchVisitor` into `applyUnboundGenericArguments`
Make sure it's called for sugar code paths too. Also let's just always
run it since it should be a pretty cheap check.
* [Sema] Diagnose passing integer to non-integer type parameter
This was previously missed, though would have been diagnosed later
as a requirement failure.
* [Parse] Split up `canParseType`
While here, address the FIXME in `canParseTypeSimpleOrComposition`
and only check to see if we can parse a type-simple, including
`each`, `some`, and `any` for better recovery.
* Introduce type sugar for InlineArray
Parse e.g `[3 x Int]` as type sugar for InlineArray. Gated behind
an experimental feature flag for now.
Ensure that we don't regress inference under
-Xfrontend -enable-experimental-lifetime-dependence-inference
Which is the default mode for .swiftinterface.
Test each basic case that requires LifetimeDependences,
first without enabling the LifetimeDependence feature,
then without specifying the kind of dependence.
This responds to some feedback on the forums. Most importantly this allows for
us to use variadic generics in the the type system to document whether we allow
for "appending" behavior or not. Previously, for some options we would take the
last behavior (and theoretically) for others would have silently had appending
behavior. This just makes the behavior simple and more explicit.
We introduce a new macro called #SwiftSettings that can be used in conjunction
with a new stdlib type called SwiftSetting to control the default isolation at
the file level. It overrides the current default isolation whether it is the
current nonisolated state or main actor (when -enable-experimental-feature
UnspecifiedMeansMainActorIsolated is set).
The attribute makes the declaration unavailable from the perspective of clients
of the module's public interface and was creating a loophole that admitted
inappropriate unavailability.
`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.
Delay resolution of availability domain identifiers parsed in availability
specifications until type-checking. This allows custom domain specifications to
be written in `if #available` queries.
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)
}
```
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
If a conformance is unavailable then checking for the potential unavailability
of a witness doesn't make sense so skip it. This is necessary now because
availability scopes no longer constrain the platform introduction version for a
source range in that is annotated in source to be simultaneously unavailable
and also introduced in a later version.
This fixes a regression caused by https://github.com/swiftlang/swift/pull/79249.
Resolves rdar://145255592.
Eventually, querying the `AvailabilityDomain` associated with an
`AvailabilitySpec` will require invoking a request that takes a `DeclContext`.
This means that any diagnostics related to the domain identified by an
`AvailabilitySpec` need to be emitted during type-checking rather than parsing.
This change migrates several `AvailabilitySpec` diagnostics from Parse to Sema
to unblock further work.
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.
If no available type eraser type exists, do not perform type erasure. If
multiple type erasers exist, choose the least available type eraser type.
Which type eraser to choose is based on the availability of the lexical
context of the erased expression.
* Include `DeclContext` of the node where possible
* Add 'default-with-decl-contexts' dump style that dumps the dect context
hierarchy in addition to the AST
* Support `-dump-parse` with `-dump-ast-format json`
Instead of making an undo() do an infer(), let's record fine-grained
changes about what was retracted, and directly re-insert the same
elements into the data structures.
When diagnosing a declaration that is more available than its context, to
preserve source compatibility we need to downgrade the diagnostic to a warning
when the outermost declaration is an extension. This logic regressed with
https://github.com/swiftlang/swift/pull/77950 and my earlier attempt to fix
this (https://github.com/swiftlang/swift/pull/78832) misidentified what had
regressed.
Really resolves rdar://143423070.
When a method override is as available as the class it's a member of, then it
can't be any more available. It doesn't make sense to diagnose such a method as
less available than the method it overrides. This regressed recently for
methods belonging to classes that are nested inside extensions. The
availability of the derived class may be defined by its context, but the
compiler was only checking the availability attributes directly on the class.
Resolves rdar://143600638.
