Raw identifiers are backtick-delimited identifiers that can contain any
non-identifier character other than the backtick itself, CR, LF, or other
non-printable ASCII code units, and which are also not composed entirely
of operator characters.
When it's available, use an open-coded allocator function that returns
an alloca without popping if the allocator is nullptr and otherwise
calls swift_coro_alloc. When it's not available, use the malloc
allocator in the synchronous context.
The well known builtin and structural types are strongly defined in the
runtime which is compacted into the standard library. Given that the VWT
is defined in the runtime, it is not visible to the Swift compilation
process and as we do not provide a Swift definition, we would previously
compute the linkage as being module external (`dllimport` for shared
library builds). This formed incorrect references to these variables and
would require thunking to adjust the references.
One special case that we add here is the "any function" type
representation (`@escaping () -> ()`) as we do use the VWT for this type
in the standard library but do not consider it part of the well known
builtin or structural type enumeration.
These errors were previously being swallowed by the build system and
thus escaped from being fixed when the other cases of incorrect DLL
storage were.
Remove `IRGenModule::useDllStorage()` as there is a standalone version
that is available and the necessary information is public from the
`IRGenModule` type. Additionally, avoid the wrapped `isStandardLibrary`
preferring to use the same method off of the public accessors. This
works towards removing some of the standard library special casing so
that it is possible to support both static and dynamic standard
libraries on Windows.
In C++, a primary base class that is placed in the beginning of the type's memory layout isn't always the type that is the first in the list of bases – the base types might be laid out in memory in a different order.
This makes sure that IRGen handles base types of C++ structs in the correct order.
This fixes an assertion in asserts-enabled compilers, and an out-of-memory error in asserts-disabled compilers. The issue was happening for both value types and foreign reference types. This change also includes a small refactoring to reuse the logic between the two code paths.
rdar://140848603
When compiling with library evolution and a pre-Swift 6.0 deployment
target, a mismatch between the notion of resilience used for determining
whether a protocol that inherits Sendable might need to be treated as
"dependent" differed from how other parts of IR generation decided
whether to conformance should be considered as resilient. The
difference came when both the protocol and its conforming type are in
the same module as the user.
Switch over to the "is this conformance resilient?" query that takes
into account such conformances.
Fixes rdar://136586922.
The main change here is to associate a witness table with a `ProtocolConformance` instead of a `RootProtocolConformance`.
A `ProtocolConformance` is the base class and can be a `RootProtocolConformance` or a `SpecializedProtocolConformance`.
For types like `Atomic` and `Mutex`, we want to know that even though they are
technically bitwise-takable, they differ from other bitwise-takable types until
this point because they are not also "bitwise-borrowable"; while borrowed,
they are pinned in memory, so they cannot be passed by value as a borrowed
parameter, unlike copyable bitwise-takable types. Add a bit to the value witness
table flags to record this.
Note that this patch does not include any accompanying runtime support for
propagating the flag into runtime-instantiated type metadata. There isn't yet
any runtime functionality that varies based on this flag, so that can
be implemented separately.
rdar://136396806
The generality of the `AvailabilityContext` name made it seem like it
encapsulates more than it does. Really it just augments `VersionRange` with
additional set algebra operations that are useful for availability
computations. The `AvailabilityContext` name should be reserved for something
pulls together more than just a single version.
Typed pointers are slowly being removed. There's a lot more cleanup to
do here, since really all `IRGenModule::.*PtrTy` should just be `PtrTy`,
but this at least gets us compiling for now.
We add the `memory(argmem: readwrite)` attribute to swift_task_create,
which means that the call is only allowed to read or write "pointer
operands". LLVM is smart enough to look through obvious ptrtoint
casts, but not to look through integer selects and so on, which is what
we produce when there's an opaque optional operand that feeds into the
builtin. This was causing miscompiles under optimization when using
`@isolated(any)` function types for task creation, since we're not yet
clever enough to fold the function_extract_isolation for a known function
(and of course it's not necessarily a known function anyway).
Distributed protocol requirements don't have associated SILFunction,
let's introduce a more flexible way to define it that collects only
the information necessary for the function to become accessible.
Given the following protocol:
```
protocol Greeter : DistributedActor {
distributed func greet()
}
```
The changes make it possible to synthesize a distributed accessor
thunk for the requirement `greet` which would be dispatched to the
underlying concrete actor implementation at runtime.
Fix a bug in expandExternalSignatureTypes where it wasn't annotating a function call parameter type with sret when the result was being returned indirectly.
The bug was causing calls to ObjC methods that return their results indirectly to crash.
Additionally, fix the return type for C++ constructors computed in expandExternalSignatureTypes. Previously, the return type was always void even on targets that require constructors to return this (e.g., Apple arm64), which was causing C++ constructor thunks to be emitted needlessly.
Resolves rdar://121618707
