This would be used by closures because they handle patterns
and initializers via solver and set them back to the pattern
binding decl as fully type-checked.
The `@__distributedActorIndependent` attribute is effectively the same
as nonisolated, so start treating it that way by making actor-isolation
checking look for it specifically and conclude "nonisolated". Remove
various special cases for this attribute that don't need to exist.
These will be used by the RequirementMachine to compute requirement
signatures. For now, they're not hooked up.
ProtocolDecl::getStructuralRequirements() produces a list of Requirements
with SourceLocs from the structural types written in the protocol's
inheritance clause and 'where' clauses.
ProtocolDecl::getProtocolDependencies() produces a list of protocols which
appear on the right hand side of the protocol's conformance requirements.
Note: we only lazily load the result if it's a record, because otherwise it's trivial to load when importing the function. Also, we still eagerly import operator's results types.
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.
The MemoryBuffer loader is used by LLDB during debugging to import binary Swift
modules from .swift_ast sections. Modules imported from .swift_ast sections are
never produced from textual interfaces. By disabling resilience the expression
evaluator in the debugger can directly access private members.
rdar://79462915
The following regression test added for this feature is not passing:
Swift(linux-x86_64) :: decl/protocol/protocols_with_self_or_assoc_reqs_executable.swift
with a compiler crash happening during SILFunctionTransform "Devirtualizer".
Reverting to unblock CI.
This reverts commit f96057e260, reversing
changes made to 3fc18f3603.
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.
We'd like to support factor initializers
for distributed actor types that are
synthesized by SILGen.
We already do something similar for
memberwise initializers for structs.
Thus, this patch generalizes that
concept into a new BodyKind for
AbstractFunctionDecls called
BodyKind::SILSynthesize.
In addition, to help differentiate the
kinds of AFDs that are SILSynthesized
into different families for SILGen to
recognize, we also have a new enum
SILSynthesizeKind to indicate whether it
is a memberwise init, etc.
1. We're no longer synthesizing the local
init. All designated inits of a dist actor
must have exactly one ActorTransport parameter.
This parameter is used in the init's prologue
to initialize some of its members.
2. We're synthesizing a factory function for
the resolve initialization, instead of an
actor-member named `init` to serve that
purpose.
As such, much of the earlier infrastructure
is no longer needed, etc.
Previously, there was a divergence in behavior between marking an actor as:
- objc: This would lead to usage of Swift reference counting.
- subclass of NSObject but not objc: This would lead to usage of ObjC
reference counting.
By itself, this might seem OK, after all, the two reference counting
schemes are compatible (you can pass things from one language to another).
However, there is a difference here because actors have a multi-step
deinitialization process due to the way the reference accounting works
with tasks. When the last reference is released, the destroy() method is
called which only puts the actor into a Zombie_Latching state and deallocation
happens later on.
In contrast, when the ObjC runtime releases the last reference, it
immediately deallocates the actor, without calling the destroy() method
or having any awareness about actors.
This mismatch leads to a use-after-free in the Swift runtime; normally,
the actor would be in the Zombie_Latching state and when the final running
task finishes, it would end up deallocating the actor. This expectation
is not met when the memory is freed by the ObjC runtime, hence the UAF.
Normally, I would find it a bit odd to see a commit come with acknowledgements
but in this case I think maybe it's okay, given that this took me 2+ weeks to
investigate and fix. Thanks to:
- Dani C. in helping reproduce the issue with a large and small test case.
- John for answering questions about the actor and job lifecycle.
- Mike Ash for providing generous help with debugging.
Fixes rdar://80863853.
We used to represent the interface type of variadic parameters directly
with ArraySliceType. This was awfully convenient for the constraint
solver since it could just canonicalize and open [T] to Array<$T>
wherever it saw a variadic parameter. However, this both destroys the
sugaring of T... and locks the representation to Array<T>. In the
interest of generalizing this in the future, introduce
VariadicSequenceType. For now, it canonicalizes to Array<T> just like
the old representation. But, as you can guess, this is a new staging
point for teaching the solver how to munge variadic generic type bindings.
rdar://81628287
It's been quite a long time since this unused parameter was introduced.
The intent is to produce the module as a root for the search - that is,
computing the set of conformances visible from that module, not the set
of conformances inside of that module. Callers have since been providing
all manner of module-scoped contexts to it.
Let's just get rid of it. When we want to teach protocol conformance
lookup to do this, we can revert this commit as a starting point and try
again.
* [TypeResolver][TypeChecker] Add support for structural opaque result types
* [TypeResolver][TypeChecker] Clean up changes that add structural opaque result types
Update the async refactorings to use the name from the async alternative
if one is known, rather than always assuming the name matches the
synchronous function.
Note that this could also be used to determine whether results remain
optional or not, but that has been left for a future patch.
Resolves rdar://80612521
A lookup on the name provided by `renamed` in `@available` returns the
VarDecl. If the name specified a getter or setter, make sure to grab the
corresponding accessor when comparing candidates.
We currently ignore the basename and parameters specified in the name
for accessors. Checking them would only cause a getter/setter not to
match, there can never be a conflict. Since this is a best effort match
anyway, this seems fine.
Instead of a new attribute `@completionHandlerAsync`, allow the use of
the existing `renamed` parameter of `@available` to specify the
asynchronous alternative of a synchronous function.
No errors will be output from invalid names as `@completionHandlerAsync`
had, but if a function is correctly matched then it will be used to
output warnings when using the synchronous function in an asynchronous
context (as before).
Resolves rdar://80612731
This flag was always a hack to get clients that were not properly
handling circular constructions (module loading, associated type
inference) to stop crashing. Technically, it is unsound, but by sheer
coinicidence of the structure of the name lookup requests and the cache
faulting here we have never observed that unsoundness in the wild.
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.
Deserializing a source location will compute the declaration's USR, which
might trigger another request cycle, etc.
Tentative fix for rdar://problem/80546848, but I don't have a test case.
