This simplifies the logic in `ide::typeCheckContextAt` and fixes an issue that prevent code completion from working inside variables that are initialized by calling a closure.
Fixes rdar://90455154 [SR-16012]
Fixes rdar://85600167 [SR-15495]
SE-0343 is approved so it's time to pull the feature out from behind the
experimental feature flag. This patch pulls it out and deprecates
passing the flag to the frontend so that we can pull it out entirely
eventually.
To help maintain source-compatibility, the presence of an `await` in
top-level code to kick the top-level code over to being a concurrent
context.
This, of course, means that in the test cases that exist today, they
will go back to behaving identically to how they did before I added all
of this because they don't have any awaits in the top-level. I'll be
adding new tests to verify the differences in behavior between swift 5,
swift 6, with and without async top level enabled in the next commit.
It's possible to create an impossible set of constraints for
instance-member stored properties of a type. For example:
@MainActor func getStatus() -> Int { /* ... */ }
@PIDActor func genPID() -> ProcessID { /* ... */ }
class Process {
@MainActor var status: Int = getStatus()
@PIDActor var pid: ProcessID = genPID()
init() {} // Problem: what is the isolation of this init?
}
We cannot satisfy the isolation of the initilizing expressions,
which demand that genStatus and genPID are run with isolation
from a non-async designated initializer, which is not possible.
This patch changes the isolation for those initializer expressions
for instance members, saying that the isolation is unspecified.
fixes rdar://84225474
The first attempt to do this was in
https://github.com/apple/swift/pull/40652
But, I implemented that as a hard source break, since the isolation
was changed in a way that an error diagnostic would be emitted.
This commit reimplements the change more gently, as a warning for
Swift 5 users.
Querying the context for whether it is an async context is the easiest
way to detect if the context is async. Many decl contexts can be checked
at any point, but AbstractClosureExpr contexts must have been
typechecked. If this is called on an AbstractClosureExpr before the
types have been assigned, it may either crash or do bad things.
If possible, add imported members to the StructDecl's LookupTable rather than adding them directly as members. This will fix the issues with ordering that #39436 poorly attempted to solve during IRGen.
This also allows us to break out most of the test changes from #39436.
Returning a null GenericSignature is not the right way to break a cycle,
because then callers have to be careful to handle the case of a null
GenericSignature together with a non-null GenericParamList, for example
in applyGenericArguments().
An even worse problem can occur when a GenericSignatureRequest for a
nested generic declaration requests the signature of the parent context,
which hits a cycle. In this case, we would build a signature where
the first generic parameter did not have depth 0.
This makes the requirement machine upset, so this patch implements a new
strategy to break such cycles. Instead of returning a null
GenericSignature, we build a signature with the correct generic
parameters, but no requirements. The generic parameters can be computed
just by traversing GenericParamLists, which does not trigger more
GenericSignatureRequests, so this should be safe.
Many, many, many types in the Swift compiler are intended to only be allocated in the ASTContext. We have previously implemented this by writing several `operator new` and `operator delete` implementations into these types. Factor those out into a new base class instead.
Start treating the null {Can}GenericSignature as a regular signature
with no requirements and no parameters. This not only makes for a much
safer abstraction, but allows us to simplify a lot of the clients of
GenericSignature that would previously have to check for null before
using the abstraction.
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>.
getParsedMembers() on imported and deserialized contexts has to pull
in all the members. This is wasteful. Imported contexts do not have
fingerprints at all, and fingerprints of deserialized contexts are
serialized separately.
The fast path handles these cases, only calling down to
getParsedMembers() if the parent FileUnit is a SourceFile.
When an extension is nested inside of an invalid decl context, it is
going to pull the signature of its nearest enclosing context instead of
its extended type. This leads to a null signature since the nearest
enclosing context for an extension should always be its parent source
file.
rdar://76049852
Introduce an "all members" request to compute all of the members of a
given iterable declaration context in stable order. This builds on ABI
members so that it will also include, e.g., type aliases synthesized
for associated types.
The "semantic members" query produces the list of members that can
affect the ABI, e.g., of classes. It does not produce the complete
list of members suitable for semantic queries.
getFragileFunctionKind() would report that all initializers in
non-resilient public types were inlinable, including static
properties.
This was later patched by VarDecl::isInitExposedToClients(),
which was checked in diagnoseInlinableDeclRefAccess().
However, the latter function only looked at the innermost
DeclContexts, not all parent contexts, so it would incorrectly
diagnose code with a nested DeclContext inside of a static
property initializer.
Fix this by changing getFragileFunctionKind() to call
isInitExposedToClients() and simplifying
diagnoseInlinableDeclRefAccess().
This commit also introduces a new isLayoutExposedToClients()
method, which is similar to isInitExposedToClients(), except
it also returns 'true' if the property does not have an
initializer (and in fact the latter is implemented in terms
of the former).
This attribute allows to define a pre-specialized entry point of a
generic function in a library.
The following definition provides a pre-specialized entry point for
`genericFunc(_:)` for the parameter type `Int` that clients of the
library can call.
```
@_specialize(exported: true, where T == Int)
public func genericFunc<T>(_ t: T) { ... }
```
Pre-specializations of internal `@inlinable` functions are allowed.
```
@usableFromInline
internal struct GenericThing<T> {
@_specialize(exported: true, where T == Int)
@inlinable
internal func genericMethod(_ t: T) {
}
}
```
There is syntax to pre-specialize a method from a different module.
```
import ModuleDefiningGenericFunc
@_specialize(exported: true, target: genericFunc(_:), where T == Double)
func prespecialize_genericFunc(_ t: T) { fatalError("dont call") }
```
Specially marked extensions allow for pre-specialization of internal
methods accross module boundries (respecting `@inlinable` and
`@usableFromInline`).
```
import ModuleDefiningGenericThing
public struct Something {}
@_specializeExtension
extension GenericThing {
@_specialize(exported: true, target: genericMethod(_:), where T == Something)
func prespecialize_genericMethod(_ t: T) { fatalError("dont call") }
}
```
rdar://64993425
Provide an accessor for retrieving the parsed members, generalizing
`ParseMembersRequest` so it can provide the parsed members for
deserialized/synthesized declarations as well. This is the counterpart
to the recently-generalized `getSemanticMembers()`; together, these
should suffice for most (all?) clients of `getMembers()`.
Generalize `ClassDecl::getEmittedMembers()` to operate on an
`IterableDeclContext`, so that it can be for other nominal types,
extensions, etc. Rename to `getSemanticMembers()` to indicate that
these are all of the members that are semantically part of that
context.
Clean up the implementation slightly so it only forces type checking
for the conformances within that particular context (using
`getLocalConformances()`) and doesn't need to list out each of the
protocols it cares about.
Make sure we consistently use getParentForLookup() and not getParent()
when looking at generic DeclContexts. This is because an extension or
protocol that is nested inside of another generic context must never
inherit generic parameters from the parent context.
We already had this invariant enforced in some places, but now that we
do it more consistently we can fix more crashes of this kind.
Fixes <rdar://problem/58813746>, <https://bugs.swift.org/browse/SR-13004>.
