This will be used to provide a safe overload of `std::vector::erase` in Swift.
`std::vector::erase` is not currently imported into Swift because it returns a C++ iterator.
rdar://113704853
This makes it possible to initialize `std::vector` from a Swift Sequence. This also conforms C++ vectors to `ExpressibleByArrayLiteral`, making it possible, for instance, to pass a Swift array to a C++ function that takes a vector of strings as a parameter.
rdar://104826995
`ReadOnly`/`ArgMemOnly` were mostly moved over, but a few were missed.
Update them all. Also default to `unknown` for no memory effects rather
than none (ie. we should be conservative).
This is an inheritor of the existing `UnsafeCxxInputIterator` protocol, with the only difference being the ability to mutate `var pointee` via a non-const `operator*()`.
This is needed to support mutable subscripts for `std::map` via `CxxDictionary`.
rdar://105399019
Reformatting everything now that we have `llvm` namespaces. I've
separated this from the main commit to help manage merge-conflicts and
for making it a bit easier to read the mega-patch.
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
`std::set::insert` isn't exposed into Swift, because it returns an instance of an unsafe type.
This change adds a Swift overload of `insert` for `std::set` and `std::unordered_set` that has the return type identical to `Swift.Set.insert`: a tuple of `(inserted: Bool, memberAfterInsert: Element)`.
rdar://111036912
* [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.
