The source location for the variable should be the value in VarInfo if set,
otherwise it should use the location of the instruction. Both ways should
be consistent, and as we use column number if VarInfo is set, we have to do
it if isnt, too.
When Swift imports C structs, it synthesizes an initializer that takes no arguments and zero-initializes the C struct.
When C++ interop is enabled, Clang treats all C structs as if they were C++ structs. This means that some of the C structs will get a default constructor implicitly generated by Clang. This implicit default constructor will not zero-initialize trivial fields of the struct.
This is a common source of confusion and subtle bugs for developers who try to enable C++ interop in existing projects that use C interop and rely on zero-initialization of C structs.
rdar://115909532
This change introduces a new compilation target platform to the Swift compiler - visionOS.
- Changes to the compiler build infrastrucuture to support building compiler-adjacent artifacts and test suites for the new target.
- Addition of the new platform kind definition.
- Support for the new platform in language constructs such as compile-time availability annotations or runtime OS version queries.
- Utilities to read out Darwin platform SDK info containing platform mapping data.
- Utilities to support re-mapping availability annotations from iOS to visionOS (e.g. 'updateIntroducedPlatformForFallback', 'updateDeprecatedPlatformForFallback', 'updateObsoletedPlatformForFallback').
- Additional tests exercising platform-specific availability handling and availability re-mapping fallback code-path.
- Changes to existing test suite to accomodate the new platform.
Call `swift_clearSensitive` after destroying or taking "sensitive" struct types.
Also, support calling C-functions with "sensitive" parameters or return values. In SIL, sensitive types are address-only and so are sensitive parameters/return values.
Though, (small) sensitive C-structs are passed directly to/from C-functions. We need re-abstract such parameter and return values for C-functions.
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.
This fixes an assertion failure when building certain projects for arm64e with `-use-clang-function-types` Swift compiler flag:
```
Expected non-null Clang type for @convention(c)/@convention(block) function but found nullptr
```
rdar://121227452
Emit metadata for runtime checks of conformances of associated types to
invertible protocols, e.g., `T.Assoc: Copyable`. This allows us to
correctly handle, e.g., dynamic casting involving conditional
conformances that have such constraints.
The model we use here is to emit an invertible-protocol constraint
that leaves only the specific bit clear in the invertible protocol
set.
Only the non-zero-sized associated values of a type were considered
when determining whether an enum is copyable or was
trivially-destructible, meaning that a zero-sized, noncopyable type
with a `deinit` wouldn't get destroyed. Treat these associated values
as if they were a payload, and centralize the logic for figuring out
these overall aspects of the enum (copyable, trivially-destructible,
bitwise-takable) since the same checks were repeated.
Fixes rdar://118449507.
An empty struct that is noncopyable can nonetheless have a `deinit`, so
it is not trivially destructible. In such cases, embedded them in
another empty struct means that the outer struct should also not be
trivially destructible. Make it so.
They can lower to a set of i64 registers we consider small but exploded
to (manifested as SSA) registers they will cause significant code bloat.
rdar://125265576
