Fixes a host of problems with stored type members with types dependent
on a type parameter pack; I ran into it specifically with vanishing
tuples.
Test to follow.
AbstractionPattern.
The old logic was wrong for vanishing tuples: a non-tuple substituted
type might correspond to multiple lowered parameters if it's the result
of substituting into a vanishing tuple that also contains empty pack
expansions.
Test to follow later in this PR.
Code can only locally interact with a mutable memory location within a
formal access, and is only responsible for maintaining its invariants
during that access, so the move-only address checker does not need to,
and should not, observe operations that occur outside of the access
marked with the `mark_must_check` instruction. And for immutable
memory locations, although there are no explicit formal accesses, that's
because every access must be read-only, so although individual
accesses are not delimited, they are all compatible as far as
move-only checking is concerned. So we can back out the changes to SILGen
to re-project a memory location from its origin on every access, a
change which breaks invariants assumed by other SIL passes.
Partially address the incorrect handling for the `#dsohandle` on
Windows.
We were previously emitting a local definition for this external
constant, and worse yet, not marking the definition for COMDAT. It is
unclear what definition would win ultimately (implementation defined),
as we had a definition as well as the linker synthesized value. We can
change the SIL linkage for this type to `DefaultForDeclaration` which
will give it `available_externally` and default visibility and storage
which is closer to what we desire. However, because we do not track the
LLVM variables and apply heuristics for lowering the
`SILGlobalVariable`, we would attribute it with imported DLL Storage.
This would then cause us to fail at link time (amusingly enough link.exe
will report a LNK1000). Special case the variable and track that we are
targeting a windows environment in the `UniversalLinkageInfo` so that we
do not special case this on other platforms.
This also has the nice side effect of allowing us to remove the special
case in the TBD handling.
Fixes: #64741
Previously, the location used for functions corresponding to @main was
just RegularLocation::getModuleLocation(). Make that more specific by
using the annotated type's location instead.
rdar://79508092
The verify-di-hole SILVerifier pass is very useful in catching incorrectly set
SILDebugScopes, but it can be very tedious to track down the root cause of a
verification failure. This patch replicates much of its functionality inside an
assertion in SILBuilder, which will result in a backtrace pointing directly to
where the offending scope is being set.
This adds an assertion that we're using all of the parameters, so
pass prolog emission the number of lowered parameters to ignore.
That's easy for the callers to provide, since they do actually
still need to add function arguments for those parameters.
This is largely a matter of changing the main loop over subst
params in TranslateArguments to use the generators I added,
then plugging back into the general reabstraction infrastructure.
Because we don't have pack coroutines, we're kind of stuck in
the code generation for pack reabstraction: we have to write
+1 r-values into a temporary tuple and then write those tuple
element addresses into the output pack. It's not great. We
also have lifetime problems with things like non-escaping
closures --- we have that problem outside of reabstraction
thunks, too.
Other than that glaring problem, I'm feeling relatively good
about the code here. It's missing some peepholes, but it should
work. But that that's not to say that arity reabstraction works
in general; my attempts to test it have been exposing some
problems elsewhere, and in particular the closure case crashes,
which is really bad. But this gets a few more things working,
and this PR is quite large already.
The `@MainActor` global actor constraint on a declaration does not carry an
inherent ABI impact and therefore use of this constraint should not be limited
to OS versions where Swift concurrency is available.
Resolves rdar://105610970
As I've been iterating on this work, I've been gradually mulling these
over, and I think this is the way to go for now. These should make it
a lot less cumbersome to write these kinds of traversals correctly.
The intent is to the sunset the existing expanded-components stuff
after I do a similar pass for function parameters.
* [Executors][Distributed] custom executors for distributed actor
* harden ordering guarantees of synthesised fields
* the issue was that a non-default actor must implement the is remote check differently
* NonDefaultDistributedActor to complete support and remote flag handling
* invoke nonDefaultDistributedActorInitialize when necessary in SILGen
* refactor inline assertion into method
* cleanup
* [Executors][Distributed] Update module version for NonDefaultDistributedActor
* Minor docs cleanup
* we solved those fixme's
* add mangling test for non-def-dist-actor
I also slightly changed the codegen around where we insert the mark_must_check.
Specifically, before we would emit the mark_must_check directly on the
ref_element_addr and then insert the access. This had the unfortunate effect
that we would hoist any destroy_addr that were actually needed out of the access
scope. Rather than do that, I now insert the mark_must_check on the access
itself. This results in the destroy_addr being within the scope (like the
mark_must_check itself).
rdar://105910066
Also removes some redundant checks in SILGen for
the flag in order to process `_move` and `_borrow`
that are already checked for in Sema. We will keep
those behind the feature flag for now.
The subexpression of a MaterializePackExpr (which is always a tuple value
currently) is emitted while preparing to emit a pack expansion expr, and its
elements are projected from within the dynamic pack loop. This means that a
materialized pack is only evaluated once, rather than being evaluated on
every iteration over the pack elements.
More missing infrastructure. In this case, it's really *existing*
missing infrastructure, though; we should have been imploding tuples
this way all along, given that we're doing it in the first place.
I don't like that we're doing all these extra tuple copies. I'm not
sure yet if they're just coming out of SILGen and eliminated immediately
after in practice; maybe so. Still, it should be obvious that they're
unnecessary.
Arguably, it would be more consistent with the current design to
figure out a representation for pack-expansion components so that
we can keep them around in whatever storage. But honestly, I
don't like the current design; I think the eager explosion is an
over-complicated mistake. So this is partly just me finding an
excuse to not extend that to more cases.
