It replaces `DeclAttr::getUnavailable()` and `AvailableAttr::isUnavailable()`
as the designated way to query for the attribute that makes a decl unavailable.
The renamed decl is now stored exclusively in the split request evaluator
storage, which is more efficient since most availability attributes do not
specify a renamed decl.
When a protocol which has a read (or modify) requirement is built with
the CoroutineAccessors feature, it gains a read2 (or modify2,
respectively) requirement. For this to be compatible with binaries
built without the feature, a default implementation for these new
requirements must be provided. Cause these new accessor requirements to
have default implementations by returning `true` from
`doesAccessorHaveBody` when the context is a `ProtocolDecl` and the
relevant availability check passes.
Mangling and looking up the opaque result type decl
for serialized decls is a fairly expensive
operation. Instead, fallthrough to the request
which will have a cached value set by deserialization.
This shaves ~30ms off the cached completion for:
```swift
import SwiftUI
struct V: View {
var body: some View {
Table(#^CC^#
}
}
```
If the feature is enabled, base the requirement for the underscored
accessors on the availability of the non-underscored accessors. If the
(non-underscored) accessor's was available earlier than the feature,
interpret that to mean that the underscored version was available in
that earlier version, and require the underscored version. The goal is
to ensure that the ABI is preserved, so long as the simplest migration
is done (namely, deleting the underscores from the old accessors).
For modify2, cache the required-ness in the same way that it is cached
for modify.
Whether read2/modify2 are required will not always be identical to
whether read/modify are required. Add separate prediates for the
former. For now, duplicate the latter's implementation.
Also rename it to `getExplicitReturnStmts` for clarity and have it
take a `SmallVector` out parameter instead as a small optimization and
to discourage use of this new method as an alternative to
`AnyFunctionRef::bodyHasExplicitReturnStmt`.
Lifetime dependencies will now be represented with @lifetime attribute in the language.
dependsOn is a type modifier and was represented as a LifetimeDependentTypeRepr in the AST.
I am deleting dependsOn syntax parsing support and retaining LifetimeDependentTypeRepr support.
We may want to represent lifetime dependencies in a function type with a type attribute in the future.
If we use a decl attribute instead, then support for LifetimeDependentTypeRepr can be deleted.
As the optimizer uses more and more AST stuff, it's now time to create an "AST" module.
Initially it defines following AST datastructures:
* declarations: `Decl` + derived classes
* `Conformance`
* `SubstitutionMap`
* `Type` and `CanonicalType`
Some of those were already defined in the SIL module and are now moved to the AST module.
This change also cleans up a few things:
* proper definition of `NominalTypeDecl`-related APIs in `SIL.Type`
* rename `ProtocolConformance` to `Conformance`
* use `AST.Type`/`AST.CanonicalType` instead of `BridgedASTType` in SIL and the Optimizer
Fixes `cast<GenericContext>(someDecl)`.
I don't know why this didn't show up as a crash so far. But slightly changing `Decl` results in a wrong type cast and a crash.
With the upcoming `MemberImportVisibility` feature enabled, code built with Cxx
interop also enabled could be rejected by the compiler with cryptic errors
about the `__ObjC` module not being imported. This is the result of a
surprising implementation detail of Cxx interop. When importing C++ namespaces
and their members, the Clang importer puts these declarations in the Clang
header import module (a.k.a. the bridging header module, `__ObjC`). C++
namespaces don't have a logical modular home in the Swift AST because they can
span multiple modules, so it's understandable why this implementation was
chosen. However, the concrete members of namespaces also get placed in the
`__ObjC` module too, and this really confuses things.
To work around this idiosyncrasy of Cxx interop, I've introduced
`Decl::getModuleContextForNameLookup()` which returns the module that a
declaration would ideally belong to if Cxx interop didn't have this behavior.
This alternative to `Decl::getModuleContext()` is now used everywhere that
`MemberImportVisibility` rules are enforced to provide consistency.
Additionally, I found that I also had to further special-case the header import
module for Cxx interop because it turns out that there are some additional
declarations, beyond imported namespaces, that also live there and need to be
implicitly visible in every source file. The `__ObjC` module is not implicitly
imported in source files when Cxx interop is enabled, so these declarations are
not deemed visible under normal name lookup rules. When I tried to add an
implicit import of `__ObjC` when Cxx interop is enabled, it broke a bunch
tests. So for now, when a decl really belongs to the `__ObjC` module in Cxx
interop mode, we just always allow it to be referenced.
This Cxx interop behavior really needs a re-think in my opinion, but that will
require larger discussions.
Resolves rdar://136600598.
The generality of the `AvailabilityContext` name made it seem like it
encapsulates more than it does. Really it just augments `VersionRange` with
additional set algebra operations that are useful for availability
computations. The `AvailabilityContext` name should be reserved for something
pulls together more than just a single version.
Some requirement machine work
Rename requirement to Value
Rename more things to Value
Fix integer checking for requirement
some docs and parser changes
Minor fixes
Allow any declaration to be marked with `@unsafe`, meaning that it
involves unsafe code. This also extends to C declarations marked with
the `swift_attr("unsafe")` attribute.
Under a separate experimental flag (`DisallowUnsafe`), diagnose any
attempt to use an `@unsafe` declaration or any unsafe language feature
(such as `unowned(unsafe)`, `@unchecked Sendable`). This begins to
define a "safe" mode in Swift that prohibits memory-unsafe constructs.
