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.
Modify relevant portions of the type-checker and parser to allow, when the 'LiteralExpressions' experimental feature is enabled, for arbitrary integer-typed expressions in enum raw value specifiers. These expressions will be type-checked and constant-folded into an integer literal expression, keeping the current interface of 'EnumElementDecl' consistent for clients.
Previously, 'EnumRawValuesRequest' had two different "modes" which were discerned based on typechecking stage (structural | interface), where the former had the request compute all raw values, both user-specified literal expressions and computing increment-derived values as well; the latter would also type-check the user-specified expressions and compute their types.
- With the need to have enum case raw values support arbitrary integer expressions, the request ('EnumRawValuesRequest') has been refactored and simplified to *always* both compute all case raw values and perform type-checking of user-specified raw value expressions. This is done in order to allow the AST-based constant-folding infrastructure ('ConstantFoldExpression' request) to run on the expressions. Constant folding is invoked during the evaluation of 'EnumRawValuesRequest' on all user-specified raw value expressions, in order to be able to compute subsequent increment values and ensure the expressions are foldable. If they are not, i.e. if constant folding fails, a relevant diagnostic will be emitted.
- 'EnumElementDecl' continues to store the raw value expression, which is no longer a 'LiteralExpr' but rather an 'Expr'; however, the getter ('getRawValueExpr') continues to return a 'LiteralExpr' by invoking the constant-folding request on the stored value, which is guaranteed to return a cached result from a prior invocation in 'EnumRawValuesRequest', assuming it succeeded.
- Furthermore, the 'structural' request kind was previously not cached, whereas now because the request must always do the complete type-checking work, it is always cached.
Resolves rdar://168005520
This change adds an experimental feature 'LiteralExpressions` which allows for use of simple binary expressions of integer type composed of literal value operands.
For now, such literal expressions are only supported in initializers of '@section` values.
Slava Pestov
Itai Ferber
Doug Gregor
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