PointerIntPair shouldn't be used with 4 low bits, because the
allocator won't necessarily provide enough padding. Move the
recently-added IsCompileTimeConst bit into a separate field.
Fixes rdar://87614547.
Address small gaps in several places to make named opaque result types
partially work:
* Augment name lookup to look into the generic parameters when inside the
result type, which is used both to create structure and add requirements
via a `where` clause.
* Resolve opaque generic type parameter references to
OpaqueTypeArchetypeType instances, as we do for the "some" types
* Customize some opaque-type-specific diagnostics and type printing to
refer to the opaque generic parameter names specifically
* Fix some minor issues with the constraint system not finding
already-opened opaque generic type parameters and with the handling of
the opaque result type candidate set.
The major limitation on opaque types, where we cannot add requirements
that aren't strictly protocol or superclass requirements on the
generic parameters, remains. Until then, named opaque result types are
no more expressive than structural opaque result types.
The first generic parameter of an `OpaqueTypeDecl` was still being used
as the "underlying" interface type of the opaque type, which is
incorrect for both structural and named opaque result types. Eliminate
this notion, because the (declared) interface type already has the
correct structure.
Only ABI checking depended on the old "underlying" type, so rework it to
instead substitute into properly for structural opaque result types as
well.
Deserialization required a small adjustment to eliminate a cycle
because the interface type of an `OpaqueTypeDecl` involves opaque
archetype types, which reference the declaration itself... so
deserialize the interface type later, now that it's correct.
Remove the error that prevented the use of multiple opaque result types,
which was the remaining blocker for SE-0328's structural opaque result
types. Add some type checking tests for this feature, and customize
the diagnostics so they describe *which* opaque result type failed to
match when indeed there is a failure.
Generalize the implementation of opaque type declarations to maintain
the "ordinal", which represents a particular "some" utterance in a
structural opaque type, throughout more of the compiler.
The ordinal value for a given "some" matches with the index of the
corresponding generic parameter in the opaque type declaration's
generic signature. To properly be able to determine the ordinal for a
given "some" type representation, retain all of the "some" type
representations in the `OpaqueTypeDecl` (using trailing storage), so
we can map them to the proper generic parameter and ordinal later on.
* [Distributed] towards DistributedActorSystem; synthesize the id earlier, since Identifiable.id
* Fix execute signature to what Pavel is working with
* funcs are ok in sil
* fixed lifetime of id in inits
* fix distributed_actor_deinit
* distributed_actor_local
* update more tests
fixing tests
fix TBD test
fix Serialization/distributed
fix irgen test
Fix null pointer crashes
* prevent issues with null func ptrs and fix Distributed prorotocol test
* fix deinit sil test
* Enforce using headers from Swift's LLVMSupport fork and not llvm-project when building stdlib
* [LLVMSupport] Re-import LLVMSupport .cpp and .h files from 9ff3a9759b7c2f146e7f46e4aebc60453c577c5a from apple/llvm-project
Done via the following commands, while having llvm-project checked out at 9ff3a9759b7c2f146e7f46e4aebc60453c577c5a, a
commit on the stable/20210726 branch of apple/llvm-project, <9ff3a9759b>:
for i in swift/stdlib/public/LLVMSupport/*.cpp ; do cp llvm-project/llvm/lib/Support/$(basename $i) $i ; done
for i in swift/stdlib/include/llvm/ADT/*.h; do cp llvm-project/llvm/include/llvm/ADT/$(basename $i) $i ; done
for i in swift/stdlib/include/llvm/Support/*.h; do cp llvm-project/llvm/include/llvm/Support/$(basename $i) $i ; done
cp llvm-project/llvm/include/llvm/ADT/ScopeExit.h swift/stdlib/include/llvm/ADT/ScopeExit.h
cp llvm-project/llvm/include/llvm/ADT/Twine.h swift/stdlib/include/llvm/ADT/Twine.h
cp llvm-project/llvm/include/llvm/Support/raw_ostream.h swift/stdlib/include/llvm/Support/raw_ostream.h
* [LLVMSupport] Re-namespace the LLVMSupport fork after re-forking by re-applying b72788c27a
More precisely:
1) git cherry-pick b72788c27a
2) manually resolve the conflict in AlignOf.h by keeping the HEAD's version of the chunk and discarding the cherry-pick's change
3) git add AlignOf.h
4) git status | grep "deleted by us" | awk '{print($4)}' | xargs git rm
5) git cherry-pick --continue
Original namespacing commit message:
> This adds the `__swift::__runtime` inline namespace to the LLVMSupport
> interfaces. This avoids an ODR violation when LLVM and Swift are in the
> same address space. It also will aid in the process of pruning the
> LLVMSupport library by ensuring that accidental leakage of the llvm
> namespace does not allow us to remove symbols which we rely on.
* [LLVMSupport] Re-apply "pruning" on re-forked LLVMSupport from bb102707ed
This re-applies the "pruning" commit from bb102707ed, which did the following:
- Remove many whole files,
- Remove "epoch tracking" and "reverse iteration" support from ADT containers
- Remove "ABI break checking" support from STLExtras
- Remove float parsing functions from StringExtras.h
- Remove APInt/APSInt dependencies from StringRef.h + StringRef.cpp (edit distance, int parsing)
- Remove some variants of error handling and dependency of dbgs() from ErrorHandling.h and ErrorHandling.cpp
We don't need to do the whole-file-removal step, because that's already done, but the rest is re-applied by doing:
1) git cherry-pick bb102707ed
2) manually resolving conflict in ADT/DenseMap.h by keeping HEAD's version of the chunk and removing epoch tracking from it
3) manually resolving conflict in ADT/STLExtras.h by keeping HEAD's version of the chunk and removing ABI check checking from it
4) manually resolving conflict in ADT/StringExtras.h by deleting the whole chunk (removing APInt/APSInt dependent functions)
5) manually resolving conflict in ErrorHandling.cpp by force-applying the cherry-pick's version (removing write() calls and OOM callback)
6) manually resolving the three conflicts in CMakeLists.txt files by keeping HEAD's version completely
7) git add stdlib/include/llvm/{ADT/StringSwitch.h,ADT/Twine.h,Support/raw_ostream.h}
Original commit description:
> Reduce LLVMSupport to the subset required for the runtime. This reduces
> the TCB and the overheads of the runtime. The inline namespace's
> preservation ensures that ODR violations do not occur.
* [LLVMSupport] Re-apply all post-import modifications on LLVMSupport that the Swift's fork has
Since the previous commits re-imported "vanilla" versions of LLVMSupport, we need to re-apply all modifications that the Swift's fork has made since the last import. More precisely:
1) git diff 7b70120440cd39d67a595a7d0ea4e828ecc6ee44..origin/main -- stdlib/include/llvm stdlib/public/LLVMSupport | git apply -3 --exclude "stdlib/include/llvm/Support/DataTypes.h" --exclude "stdlib/include/llvm/Config/llvm-config.h.cmake"
2) manually resolve conflict in STLExtras.h by applying the "__swift::__runtime" prefix to HEAD's version
3) manually resolve conflicts in StringSwitch.h by keeping HEAD's version (removing the Unicode BOM marker at the beginning of the file, keeping LLVM's version of the string functions)
4) manually resolve conflict in SwapByteOrder.h by adding the `defined(__wasi__)` part into the #if
* [LLVMSupport] Drop remaining dependencies on APSInt.h, Error.h, DataTypes.h and STLForwardCompat.h
Most cases can drop the #includes without any changes, in some cases there are
straighforward replacements (climits, cstdint). For STLForwardCompat.h, we need
to bring in parts of STLForwardCompat.h from llvm-project.
* [LLVMSupport] Remove raw_ostream.h and drop dependencies to it from the runtime
* [LLVMSupport] Simplify error reporting in SmallVector and avoid using std::string when producing fatal errors messages
Co-authored-by: Saleem Abdulrasool <compnerd@compnerd.org>
We've recently added the -experimental-hermetic-seal-at-link compiler flag,
which turns on aggressive dead-stripping optimizations and assumes that library
code can be optimized against client code because all users of the library
code/types are present at link/LTO time. This means that any module that's
built with -experimental-hermetic-seal-at-link requires all clients of this
module to also use -experimental-hermetic-seal-at-link. This PR enforces that
by storing a bit in the serialized module, and checking the bit when importing
modules.
This is a verbatim copy of the GenericSignatureBuilder's somewhat
questionable (but necessary for source compatibility) logic where
protocol typealiases with the same name as some other associated
type imply a same-type requirement.
The related diagnostics are there too, but only emitted when
-requirement-machine-protocol-signatures=on; in 'verify' mode,
the GSB will emit the same diagnostics.
Introduce the `@_predatesConcurrency` attribute, which specifies that a
given declaration existed prior to the introduction of Swift
Concurrency, has been updated to use concurrency features (global
actors, Sendable, etc.), but should retain its pre-concurrency behavior
for clients that have not yet opted into concurrency.
Implement type and actor-isolation adjustments to
`@_predatesConcurrency` declarations to subsume the `@_unsafeMainActor`,
`@_unsafeSendable`, and `@MainActor(unsafe)` use cases. This is the
bulk of the semantic transformations needed for this new attribute,
but is not yet complete.
Part of rdar://84448438.
This is a refactoring needed to implement 'verify' mode. The
RequirementMachine computes the requirement signature for an
entire connected component of protocols at once, whereas the
GenericSignatureBuilder only does one protocol at a time.
Using the same request for both in 'verify' mode meant that
we would only call the GSB for the first protocol in a
connected component, and then the RequirementMachine would
fill in the rest.
To fix this, split it up into two requests. The original
RequirementSignatureRequest calls into the GSB, and then
kicks off a RequirementSignatureRequestRQM to get the
requirement signature computed by the RequirementMachine
(possibly cached, if this protocol is part of a connected
component with more than one protocol in it).
I am purposely doing this in SILGen rather than at the type system level to
avoid having to have to add a bunch of boilerplate to the type system. Instead
of doing that, I am in SILGen checking for the isNoImplicitCopy bit on the
ParamDecl when we emit arguments. At that point, I set on the specific
SILArgument being emitted the bit that it is no implicit copy. In terms of
printing at the SIL level, I just printed it in front of the function argument
type like @owned, e.x.:
func myFunc(_ x: @_noImplicitCopy T) -> T {
...
}
becomes:
bb0(%0 : @noImplicitCopy @owned $T):
Some notes:
* Just to be explicit, I am making it so that no implicit copy parameters by
default are always passed at +1. The reason why I think this makes sense is
that this is the natural way of working with a move only value.
* As always, one can not write no implicit copy the attribute without passing
the flag -enable-experimental-move-only so this is NFC.
rdar://83957088
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.
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.
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.
