This is currently not wired up to anything. I am going to wire it up in
subsequent commits.
The reason why we are introducing this new Builtin type is to represent that we
are going to start stealing bits from the protocol witness table pointer of the
Optional<any Actor> that this type is bitwise compatible with. The type will
ensure that this value is only used in places where we know that it will be
properly masked out giving us certainty that this value will not be used in any
manner without it first being bit cleared and transformed back to Optional<any
Actor>.
Follow up to https://github.com/swiftlang/swift/pull/84635/.
The metadata accessor for a variadic generic type takes as arguments
packs of metadata records and witness tables, and each such pack is
passed in a buffer. So the call to any such accessor is not correctly
annotated memory(none).
rdar://161606892
When building on Windows, if the nominal base type is in a non-static
library, we cannot reference the type descriptor directly. As a load is
required, we cannot statically initialise the pattern metadata. Account
for this in the addressability computation.
with sending results:
- The sending result mangling was added in the 6.0 runtime, so demangling
cannot be used to produce this metadata when targeting an earlier
runtime.
- The combination of a sending result with isolation requires the 6.1
runtime to successfully demangle, due to a bug in the 6.0 demangler.
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.
`Builtin.FixedArray<let N: Int, T: ~Copyable & ~Escapable>` has the layout of `N` elements of type `T` laid out
sequentially in memory (with the tail padding of every element occupied by the array). This provides a primitive
on which the standard library `Vector` type can be built.
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.
Some requirement machine work
Rename requirement to Value
Rename more things to Value
Fix integer checking for requirement
some docs and parser changes
Minor fixes
This change makes sure we correctly emit IR for type metadata accessors for C++ reference types.
This fixes linker errors when a type metadata of a C++ reference type is used in multiple object files that are later linked together, for instance, if a C++ reference type is conformed to different Swift protocols in different Swift source files:
```
duplicate symbol 'type metadata accessor for __C.SharedObject' in:
main.o
second.o
ld: 1 duplicate symbols
```
rdar://129027705
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
We still only parse transferring... but this sets us up for adding the new
'sending' syntax by first validating that this internal change does not mess up
the current transferring impl since we want both to keep working for now.
rdar://128216574
Form a set of suppressed protocols for a function type based on
the extended flags (where future compilers can start recording
suppressible protocols) and the existing "noescape" bit. Compare
that against the "ignored" suppressible protocol requirements, as we
do for other types.
This involves a behavior change if any client has managed to evade the
static checking for noescape function types, but it's unlikely that
existing code has done so (and it was unsafe anyway).
and implement it for @isolated(any) function types.
The existing testing was pretty broken: we were diagnosing all sorts
of things that don't require type metadata (like using a tuple with
an extended existential in a value position in an API signature)
and not diagnosing several things that do (like covariant function
conversions that erase types). There's therefore some risk to this
patch, but I'm not too worried because needing metadata like this is
pretty uncommon, and it's likely that programs won't build correctly
anyway --- it'll just get caught by the linker instead of the compiler.
The `ABI` headers had accidentally grown an `#include` into compiler headers,
allowing the enum constant values of the `ValueOwnership` enum to leak into
the runtime ABI. Sever this inappropriate relationship by declaring a separate
`ParameterOwnership` enum with ABI-stable values in the ABI headers, and
explicitly converting between the AST and ABI representation where needed.
Fixes rdar://122435628.
