Otherwise the "nonisolated nonsending by default" mode blows up as
distributed thunk signatures dont match expectations.
This undoes the fix from https://github.com/swiftlang/swift/pull/83940
and applies the fix on the synthesis side of the distributed thunks,
such that they are @concurrent always -- which keeps their old semantics
basically, regardless of what "default" mode we have.
the new NonisolatedNonsendingByDefault upcoming feature breaks remote
calls in distributed actors, because the expected isolation doesn't
match and the runtime swift_distributed_execute_target_resume will
crash.
This is a short term fix to unblock adopters, however preferably we
should mark the thunks as nonisolated(nonsending), though that seems to
be more involved.
resolves rdar://159247975
It is valid to leak a value on paths into dead-end regions.
Specifically, it is valid to leak an `alloc_box`. Thus, "final
releases" in dead-end regions may not destroy the box and consequently
may not release its contents. Therefore it's invalid to lower such final
releases to `dealloc_stack`s, let alone `destroy_addr`s. The in-general
invalidity of that transformation results in miscompiling whenever a box
is leaked and its projected address is used after such final releases.
Fix this by not treating final releases as boundary markers of the
`alloc_box` and not lowering them to `destroy_addr`s and
`dealloc_stack`s.
rdar://158149082
Something has changed about the CoreData module and caused the declarations in
this test interface to now be printed with `nonisolated` modifiers.
Resolves rdar://159293226.
When replacing an opened existential type with the concrete type, we didn't consider that the existential archetype can also be a "dependent" type of the root archetype.
For now, just bail in this case. In future we can support dependent archetypes as well.
Fixes a compiler crash.
rdar://158594365
[6.2][build] Make it possible to build a cross-compilation toolchain for Android, including Testing
Add a linker flag for the upcoming 16 KB page support in Android, generate an Android CMake toolchain file that can be used to cross-compile repos like cmark and Testing, and add a build flag that makes it easy to build cross-compilation toolchains, by disabling the cross-compilation of all host tools and macros for listed --cross-compile-hosts, leaving only the Swift runtime libraries in a cross-compilation SDK.
**Explanation**: Cherry-pick of #83792, merged as 450cb14597
WASILibc wasn't built for the embedded stdlib in `stdlib/public/Platform/CMakeLists.txt`. New `copy_wasilibc_modulemap_embedded_resource` and `embedded-stdlib-platform-${triple}` targets are added, the latter for `wasm32-unknown-wasip1` only for now. Also added a `wasilibc_functions.swift` test to verify the result.
**Scope**: limited to Embedded Swift for Wasm;
**Risk**: low due to limited scope;
**Testing**: added new lit test to the existing Embedded Swift test suite;
**Issue**: rdar://157467412
**Reviewer**: @bnbarham
If the argument type is an array and it's passed to an imported declaration
that accepts a raw pointer, the solver should use an "array-to-c-pointer"
conversion instead of the one for pointers.
Resolves: rdar://158629300
(cherry picked from commit 29b04f4a63)
This enables the use of reference-counted foreign reference types on Windows. As it turns out, the assertion that was failing on Windows previously was unnecessary. This also enabled many of the tests on Windows.
rdar://154694125 / resolves https://github.com/swiftlang/swift/issues/82643
(cherry picked from commit b440c4ff70)
Release/retain functions for C++ foreign reference types might return a reference count as an integer value.
Swift previously emitted an error for such functions, saying that the retain/release functions need to return void or a reference to the value.
rdar://157853183
(cherry picked from commit 3887ed0637)
Swift validates the retain/release operations for foreign reference types to check for obvious errors, e.g. a wrong parameter type or return type.
That logic was only running for C++ foreign reference types. This patch enables it for C foreign reference types as well.
rdar://158609723
(cherry picked from commit c73f528b82)
This fixes a runtime crash when a `weak` reference to a C++ foreign reference type is used.
Instead of a runtime crash, Swift would now emit a compiler error saying that `weak` keyword is incompatible with foreign reference types.
rdar://124040825 / resolves https://github.com/swiftlang/swift/issues/83080
(cherry picked from commit 9abadf5483)
This is an accepted spelling for the attribute. This commit
also renames the feature flag from `ExtensibleAttribute` to
`NonexhaustiveAttribute` to match the spelling of the attribute.
(cherry picked from commit fe1ae75711)
Just like `@preconcurrency` for concurrency, this attribute is going
to allow exhaustiveness error downgrades for enums that were retroactively
marked as `@extensible`.
(cherry picked from commit 498430afaf)
Guard against condfails when older compilers get a swift interface
that uses `@extensible` attribute. The attribute itself doesn't
have any effect in swift interfaces yet since all of the public
enums are already resilient in that mode.
(cherry picked from commit 6d89bca765)
For now the semantics provided by `@extensible` keyword on per-enum
basis. We might return this as an upcoming feature in the future with
a way to opt-out.
(cherry picked from commit bf19481ab6)
This attribute controls whether cross-module access to the declaration
needs `@unknown default:` because it's allowed to gain new cases even
if the module is non-resilient.
(cherry picked from commit a0ae93d3a8)
`end_borrow` instructions may end the scopes introduced by `load_borrow`
or `store_borrow` instructions, or those introduced by `begin_borrow`
whose operand's guaranteed root includes a `load_borrow`.
Previously, such scope ending instructions which end the scope
associated with a borrowing load or store were not regarded as accessing
the loaded-from or stored-to address. One consequence of this is that
they were not regarded as accessing pointers and thus not as deinit
barriers; that in turn resulted in `destroy_addr`s being hoisted into
such borrow scopes.
Here this is fixed by regarding such `end_borrow`s to access the
loaded-from or stored-to address of the scope-introducing `load_borrow`
or `store_borrow` respectively.
rdar://157772187
Parameter type could be represented by an associated type which is
bound to a concrete type by an extension, `AbstractFunction::getType()`
should map it into context before returning because the construct is
that it always produces a function type.
Resolves: rdar://156955193
(cherry picked from commit 32b97d0e2a)
