* [IRGen] Fix layout string generation for pre-specialized metadata
rdar://108012057
Pre-specialized metadata has to be specifically handled by using the bound generic type instead of the unbound one. All the necessary information is already being passed down as BoundGenericTypeCharacteristics, we just need to apply them when present.
* Add tests and a few fixes
* Fixes after rebase
* Attempt to fix Windows linker issue in test
This removes the "optimization" where a function type, metatype or
tuple type was split up into structural components, because it seems
that in general we need this structural type metadata again.
Similarly, this no longer tries to split up dependent concrete
conformances and instead passes the witness table in the context.
This makes the context larger potentially, but it avoids calls to
metadata access functions and swift_getWitnessTable() every time the
closure is invoked.
* [IRGen] Use ConditionalDominanceScope in AbstractMetadataAccessor::emit
rdar://103179745
Under certain conditions the missing dominance scope caused a cached witness table ref to be used in a block that it was not available in.
* Fix target in test
* [IRGen] Make pointers to accessor functions in layout strings relative
rdar://106319336
Pointers embedded in static layout strings should always be relative, so layout strings can reside in read-only memory.
* Properly handle reference storage ownership
* Pass layout tag and metadata / type layout ppointers separately
* Layout string instantiation fully working
* Fix cases where hasLayoutString flag was not set when it should have
* Update include/swift/ABI/Metadata.h
* [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
A lot of the fixes here are adjustments to compensate in the
fulfillment and metadata-path subsystems for the recent pack
substitutions representation change. I think these adjustments
really make the case for why the change was the right one to make:
the code was clearly not considering the possibility of packs
in these positions, and the need to handle packs makes everything
work out much more cleanly.
There's still some work that needs to happen around type packs;
in particular, we're not caching them or fulfilling them as a
whole, and we do have the setup to do that properly now.
CF_OPTIONS is defined differently in the SDK based on
a __cplusplus preprocessor branch. As a result, declarations
referencing CF_OPTIONS are mangled differently depending
on if C++ interop is enabled.
This meant a module compiled with cxx interop on could
not be linked with a module compiled without and vice versa.
This patch modifies the mangler such that the mangled names
are consistent. This is achieved by feeding the mangler a modified
AST node that looks like the Objective-C definition of CF_OPTIONS,
even when we have cxx interop enabled.
* [IRGen] Add layout strings for generic and resilient types
rdar://105837048
* Add some corner cases
* Add flag to enable generic instantiation and some fixes
* Fix resilient types
* Fix metadata accessor function pointers in combined layout strings
This adds a protocol to the C++ standard library overlay which will improve the ergonomics of `std::optional` when used from Swift code.
As of now, the overlay adds an initializer of `Swift.Optional` that takes an instance of `CxxOptional` as a parameter.
Fixes a usability problem with implicit inout conversion to raw pointers.
For example, supporting this conversion turns out to be bad:
void read_void(const void *input);
func foo(data: inout Data) {
read_void(&data)
}
People understandably expect Foundation.Data to have the same sort of
implicit conversion as Array. But it does something very wrong
instead.
We could have added an an attribute to Data and other copy-on-write
containers to selectively suppress implicit conversion. But there is
no good reason to allow implicit conversion from any non-trivial
type. It is extremely dangerous, and almost always accidental. Note
that this problem becomes worse now that the compiler views imported
`char *` arguments as raw pointers. For example:
void read_char(const char *input);
var object: AnyObject = ...
read_void(&object1)
This seems like a good time to correct this old Swift 3 behavior.
Plan: Add a warning now. Convert it to an error in Swift 6 language
mode based on feedback.
Fixes rdar://97963116 (It's really easy to accidentally corrupt a Data
object with the & operator)
rdar://105837040
* WIP: Store layout string in type metadata
* WIP: More cases working
* WIP: Layout strings almost working
* Add layout string pointer to struct metadata
* Fetch bytecode layout strings from metadata in runtime
* More efficient bytecode layout
* Add support for interpreted generics in layout strings
* Layout string instantiation, take and more
* Remove duplicate information from layout strings
* Include size of previous object in next objects offset to reduce number of increments at runtime
* Add support for existentials
* Build type layout strings with StructBuilder to support target sizes and metadata pointers
* Add support for resilient types
* Properly cache layout strings in compiler
* Generic resilient types working
* Non-generic resilient types working
* Instantiate resilient type in layout when possible
* Fix a few issues around alignment and signing
* Disable generics, fix static alignment
* Fix MultiPayloadEnum size when no extra tag is necessary
* Fixes after rebase
* Cleanup
* Fix most tests
* Fix objcImplementattion and non-Darwin builds
* Fix BytecodeLayouts on non-Darwin
* Fix Linux build
* Fix sizes in linux tests
* Sign layout string pointers
* Use nullptr instead of debug value
This adds a protocol to the C++ standard library overlay which will improve the ergonomics of `std::map` and `std::unordered_map` when used from Swift code.
As of now, `CxxDictionary` adds a subscript with an optional return type that mimics the subscript of `Swift.Dictionary`.
Similar to https://github.com/apple/swift/pull/63244.
Added pack flavors of requirement kinds for metadata and witness tables.
Fixes the function signatures for variadic generic functions which
previously used %swift.type* for variadic generic parameters--those are
lists of metadata and should actually be %swift.type**.
Since values of generic type are currently assumed to always
support copying, we need to prevent move-only types from
being substituted for generic type parameters.
This approach leans on a `_Copyable` marker protocol to which
all generic type parameters implicitly must conform.
A few other changes in this initial implementation:
- Now every concrete type that can conform to Copyable will do so. This fixes issues with conforming to a protocol that requires Copyable.
- Narrowly ban writing a concrete type `[T]` when `T` is move-only.
This adds a protocol to the C++ standard library overlay which will improve the ergonomics of `std::set`, `std::unordered_set` and `std::multiset` when used from Swift code.
As of now, `CxxSet` adds a `contains` function to C++ sets.
C++ stdlib set types are automatically conformed to `CxxSet`: `std::set`, `unordered_set`, `std::multiset`. Custom user types are not conformed to `CxxSet` automatically: while a custom type might have an interface similar to `std::set`, the semantics might differ, and adding a conformance would cause confusion.
For spatial locality on startup.
Hide collocating metadata functions in a separate section behind a flag.
The default is not to collocate functions.
rdar://101593202
This reverts commit 3617b7603c, reversing
changes made to 58a519a5c1.
This causes issues for the linker and branches accross sections if
addresses are too far apart.
This extends the existing auto-conformance mechanism to synthesize the conformances to `CxxConvertibleToCollection` protocol for C++ sequence types.
This means that the developer can now call `Array(myCxxSequence)` or `Set(myCxxSequence)` without adding any extensions manually.
This reverts commit 1f3e159cfe, reversing
changes made to 103b4a89c2.
Re-applies "IRGen: Co-locate metadata instatiation/completions/accessor
functions in a special section" for MachO only. The original change broke lldb
on aarch64 linux.
rdar://102481054
`getValue` -> `value`
`getValueOr` -> `value_or`
`hasValue` -> `has_value`
`map` -> `transform`
The old API will be deprecated in the rebranch.
To avoid merge conflicts, use the new API already in the main branch.
rdar://102362022
This makes ClangImporter automatically conform C++ collection types to `Cxx.CxxRandomAccessCollection` protocol.
We consider a C++ sequence type to be a random access collection type its iterator conforms to `UnsafeCxxRandomAccessIterator`.
Allow user-defined macros to be loaded from dynamic libraries and evaluated.
- Introduce a _CompilerPluginSupport module installed into the toolchain. Its `_CompilerPlugin` protocol acts as a stable interface between the compiler and user-defined macros.
- Introduce a `-load-plugin-library <path>` attribute which allows users to specify dynamic libraries to be loaded into the compiler.
A macro library must declare a public top-level computed property `public var allMacros: [Any.Type]` and be compiled to a dynamic library. The compiler will call the getter of this property to obtain and register all macros.
Known issues:
- We current do not have a way to strip out unnecessary symbols from the plugin dylib, i.e. produce a plugin library that does not contain SwiftSyntax symbols that will collide with the compiler itself.
- `MacroExpansionExpr`'s type is hard-coded as `(Int, String)`. It should instead be specified by the macro via protocol requirements such as `signature` and `genericSignature`. We need more protocol requirements in `_CompilerPlugin` to handle this.
- `dlopen` is not secure and is only for prototyping use here.
Friend PR: apple/swift-syntax#1022
This makes ClangImporter automatically conform C++ sequence types to `Cxx.UnsafeCxxInputIterator` protocol.
We consider a C++ type to be a random access iterator type if conforms to `UnsafeCxxInputIterator`, and additionally defines `operator-` and `operator+=`.
