Just like we do with SILFunction, allow a code generation model to be
specified on a SILGlobalVariable and maintain that through the printed
and serialized forms.
The code generation model for a particular declaration or conformance
can be defined explicitly with `@export(interface)`,
`@export(implementation)`, or `@inlinable` (for declarations),
indicating where the definition will occur.
Embedded Swift also has some limitations on what can be emitted into
IR. For example, a generic function cannot be `@export(interface)`
because Embedded Swift does not support unspecialized generics.
Compute the effective code generation model based on what was
explicitly specified, the limitations of the model, and the default
code generation model for the given module, which defaults to
"inlinable" but can be made "implementation" by the DeferredCodeGen
feature. Use the effective code generation model for IR- and SIL-level
determinations of linkage and where to emit symbols.
[WIP] Start computing and using the "effective" code generation model
FIXUP linkage of the alias symbol
Adds a new DynamicMemberLookupSubscriptRequest type for evaluating and
caching the validity of a `SubscriptDecl`'s usage to fulfill a
`@dynamicMemberLookup` requirement for a specific usage.
`SubscriptDecl`s may get checked multiple times for eligibility in
fulfilling `@dynamicMemberLookup` requirements; since the checks are
non-trivial and the result doesn't change, this eligibility can be
cached in the decl's `Bits`.
Pending swift evolution discussion: https://github.com/swiftlang/swift-evolution/pull/3133
replaces #87171
update new error message according to proposal
also handle untyped throws in _nonDiscardableWhenThrowing attr
Rename the internal attr _nonDiscardableWhenThrowingOperation
A fileprivate access scope should always be rooted in the outermost
SourceFile since macros do not introduce their own file access scopes.
rdar://174872704
For a given function, we might end up emitting it's definition as
object code, serialized SIL, or both. The @export, @inlinable, and
@inline(always) attributes provide control of this behavior at the
declaration level.
Centralize the query function that will look for each of these
attributes and map down to a specific "code generation model", whose 3
options follow the naming from SE-0497: interface, inlinable, and
implementation. Use this one computation to back the queries for
"always emit into client", "never emit into client", and "inlinable"
so we can't get inconsistent results from places that are doing
one-off checks for these attributes.
Back in January, I updated the swiftinterface _reading_ code to accept either
`read`/`modify` or `yielding borrow`/`yielding mutate`. That update has been
around for long enough that we can now switch over the swiftinterface _writing_
code to emit the standard final `yielding borrow`/`yielding mutate` spellings.
Interface files written with the old spellings will continue to be
accepted for some time (likely a year or more).
When hiding dependencies in embedded mode there are special rules for
classes. Classes properties can safely reference the hidden
dependencies, however code referencing these properties must be marked
`@export(interface)`.
We previously added a check to report implicit code without the requited
`@export(interface)`. However explicit references from user written code
wasn't fully checked, only explicit references to the imported type or
the type's services would be reported, not references to the property
itself.
We patch that hole here by introducing new requirements and a new layer
of check specific to class properies in embedded mode.
---
Class properties referencing a hidden dependency must be marked
`@_implementationOnly`. This adds on top of the requirement for the
class itself to have an explicit `@export(interface) deinit`.
This allows to report references from user written code using existing
diagnostics.
Without library-evolution we can be more permissive about references to
hidden dependencies from classes properties. However, lifting these
checks broke other checks on properties. Here we fix this hole and
ensure that while we allow references from stored properties we still
checking implicit initializers.
rdar://173011223
Even without library-evolution, we allow references to hidden
dependencies from class properties as long as the class is not marked
open. In embedded, references from functions are only accepted when
marked `@export(interface)` as it can't be inlined in clients.
Combine both requirements to protect the implicitly generated destructor
as well. Add a requirement for classes with such a property to
explicitly declare a `@export(interface)` deinit. Otherwise that deinit
may be inlined in clients and cause a deserialization failure.
rdar://170855491
borrow accessors can be supported in classes when they return 'let' properties, global 'let'.
Remove blanket restriction and add tests for supported cases
Introduce new syntax for parsing arbitrary integer literal expressions for generic value arguments:
```swift
InlineArray<(<Expr>), T>
[(<Expr>) of T]
```
Which, for now, will co-exist alongside the current syntax of simple integer literals.
Replace `IntegerTypeRepr` with `GenericArgumentExprTypeRepr`, a new `TypeRepr` node that wraps arbitrary expressions in generic argument positions (e.g., `InlineArray<(1 + 3), Int>`). The node tracks resolution state, distinguishing whether the expression resolved to a type or an integer value.
Key changes:
- Parse parenthesized generic arguments as expressions
- Recover and distinguish types from integer expressions in `resolveGenericArgumentExprTypeRepr`.
- When the `LiteralExpressions` feature is enabled, type-check and constant-fold expressions to integer values
- Extract `PreCheckTarget` into a public header to expose `simplifyTypeExpr` for use during type resolution
Resolves rdar://168005391
Extract logic that synthesizes a `VarDecl` for an alias into
`VarDecl::createImported` and set the new declaration as
synthesized, imported and `@preconcurrency`.
Use `makeComputed` to set all the appropriate bits about storage.
Implementations functions marked `@c @implementation` or members of an
`@objc @implementation` aren't part of the Swift API. Their declaration
in C is the API definition, the Swift part only contributes to the ABI.
This allows us to loosen some of the usual exportability checks on these
functions as these checks are only relevant to APIs.
Here we allow such functions to be marked public even if their signature
use types from a restricted import. One may want to do so to set the
symbol visibility. Since the API visibility is determined by how the
C headers are distributed, the restrictions on the import aren't
relevant here.
Ensure we correctly handle the case where you're overriding a witness
that should be `public`. Currently this is working as a side-effect
of conformance checking, but we ought to be able to compute it with
lazy type-checking. No test case since it will be covered once we
rip out the eager type-checking in a following commit.
Doug Gregor
Slava Pestov
Itai Ferber
Cal Stephens
Hamish Knight
Pavel Yaskevich
Konrad Malawski
Tim Kientzle
Alexis Laferrière
John Hui
Meghana Gupta
Artem Chikin
Pavel Yaskevich
Meghana Gupta
Kavon Farvardin
Susana Monteiro
Anthony Latsis