Updates the message to use the type or ValueDecl instead of this on previous 'Found this candidate' messages
Note: doees not yet change all test cases so more tests are failing
Improve Diagnostic message on overload ambiguitiy
Remove messages that say 'found this candidate' in favour of providing the type for the candidate to aid in selection when the candidates are presented in a dialogue window.
Fix more tests
As with SIL functions, track the parent module where a SIL global
variable was originally defined so that we can determine whether we
are outside of its original module for linkage purposes. Use this to
make sure we emit via a weak definition when emitting to a module
other than the originating module.
Fixes rdar://160153163.
Delay the emission of SIL global variables that aren't externally
visible until they are actually used. This is the same lazy emission
approach that we use for a number of other entities, such as SIL
functions.
Part of rdar://158363967.
Introduce an experimental feature DeferredCodeGen, that defers the
generation of LLVM IR (and therefore object code) for all entities
within an Embedded Swift module unless they have explicitly requested
to not be emitted into the client (e.g., with
`@_neverEmitIntoClient`).
This feature is meant to generalize and subsume
-emit-empty-object-file, relying on lazy emission of entities rather
than abruptly ending the compilation pipeline before emitting any IR.
Part of rdar://158363967.
* When constructing instructions which have substitution maps: initialize those with the canonical SubstitutionMap
* Also initialize SILFunction::ForwardingSubMap with the canonical one
Non-canonical substitution maps may prevent generic specializations.
This fixes a problem in Embedded Swift where an error is given because a function cannot be specialized, although it should.
https://github.com/swiftlang/swift/issues/83895
rdar://159065157
Non-embedded Darwin targets reserve the first 4GB of address space. All
other targets reserve 4KB of address space. Make Embedded Darwin
targets only reserve the first 4KB (as with other targets), since they
aren't in userspace.
Fixes rdar://158981013.
When outlining a destroy operation, we form direct calls to the deinit
of noncopyable types. For generic types, this was always calling into
unspecialized generics, which is... deeply unfortunate.
Look for a specialized deinit and call that instead. This eliminates a
compiler assertion in Embedded Swift, and should improve performance
with noncopyable generics elsewhere.
Fixes rdar://159054138 and #72627 / rdar://157131184.
In Desktop Swift, @_implementationOnly imports allow one to hide the
implementation so long as you're careful to only reference entities
from the imported modules in code that gets compiled into the object
file and *not* referenced by the corresponding Swift module file.
Until very recently, there was no such affordance for Embedded Swift,
because all functions would have their SIL serialized to the Swift
module file. Using them from a client module would then attempt to
deserialize the SIL, loading the @_implementationOnly-imported module
and causing the compiler to abort. With the introduction of
@_neverEmitIntoClient, we now have a way to say "only in the object
file, never in the module file" for the definition of functions.
Introduce a test that makes sure @_implementationOnly +
@_neverEmitIntoClient has the desired effect of hiding the imported
modules from clients. It's still brittle and hard to use, just like
the existing @_implementationOnly, but this shows that it's at least
possible to do this implementation hiding in Embedded Swift.
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.
Resolves https://github.com/swiftlang/swift/issues/83513
rdar://157467412
Part of the Embedded Swift linkage model, this attribute ensures that
the function it applies to has a strong definition in its owning
module, and that its SIL is never serialized. That way, other modules
will not have access to its definition.
Implements rdar://158364184.
When Embedded Swift emits a symbol that was imported from another
module, ensure that the symbol is emitted as a weak definition. This
way, importing the same module (and using its symbol) into several
different modules doesn't cause duplicate-symbol errors at link time.
Rather, the linker will merge the different symbol definitions. This
makes Embedded Swift libraries work without resorting to
`-mergeable-symbols` or `-emit-empty-object-file`.
Correct several behaviors of availability checking in unavailable contexts that
were inconsistent with the checking model:
- Avoid diagnosing unintroduced and obsolted declarations in contexts that are
unavailable in the same domain.
- Diagnose unavailability normally in type signature contexts.
This is a follow up to https://github.com/swiftlang/swift/pull/80862, where `storeEnumTagSinglePayload` in a special implementation of `ResultTypeInfo` for Embedded Swift had a mismatching number of arguments. The actual declaration of it in `ABI/ValueWitness.def` clearly includes one more argument.
```
/// void (*storeEnumTagSinglePayload)(T* enum, UINT_TYPE whichCase,
/// UINT_TYPE emptyCases, M *self);
/// Given uninitialized memory for an instance of a single payload enum with a
/// payload of this witness table's type (e.g Optional<ThisType>), store the
/// tag.
FUNCTION_VALUE_WITNESS(storeEnumTagSinglePayload,
StoreEnumTagSinglePayload,
VOID_TYPE,
(MUTABLE_VALUE_TYPE, UINT_TYPE, UINT_TYPE, TYPE_TYPE))
```
This function type mismatch is illegal when targeting Wasm and traps at run time.
Similarly to #80862, we're passing `nullptr` as the newly added argument, which is equivalent to the existing behavior on other platforms.
rdar://157219474
The test was crashing due to `swift_unreachable("custom executors not supported in embedded Swift")` line in `swift_task_enqueueImpl`, as the corresponding non-embedded codepath was relying on an unspecialized generic function `_swift_task_enqueueOnExecutor` defined in `Executor.swift`. Unspecialized generics are unavailable in Embedded Swift, and such `@silgen_name` function can't be specialized when used from concurrency runtime code written in C/C++. We can redefine this function for Embedded Swift as using a class-bound existential instead, and re-enable this codepath with a slightly different call that avoids the use of unavailable `swift_getObjectType` function from the non-embedded runtime.
If the conformance is abstract the witness table is specialized elsewhere - at the place where the concrete conformance is referenced.
Fixes a compiler crash.
Since this is a source breaking change, downgrade the diagnostic to a warning
until the next language version unless library evolution is enabled, in which
case this would have resulted in a broken `.swiftinterface` and it therefore
makes sense to diagnose eagerly.
Resolves rdar://156919010.
The test is only partially enabled: we only check for IR correctness and correct linking. We don't run the tests on WASI yet due to unrelated issues that are going to be resolved separately.
It seems that the restriction preventing these from working was
lifted.
The behavioral difference is that in Swift 5 mode, we don't
actually open AnyObject like this, so the old operator could
not be used with class-bound existentials.
I added a trivial test case just to ensure that calls to ===
type check correctly in both language modes.
Fixes rdar://156095800.
Run new `check-swift-embedded-wasi` target from `test/CMakeLists.txt`, tweak `lit.cfg` to support both `-wasi` and `-wasip1` triples, exclude unsupported tests based on `CPU=wasm32` instead of `OS=wasi`.
