Exclude properties with initial values from the memberwise initializer
if they are less accessible than the most accessible property, up to
`internal`. Introduce a compatibility overload that continues to
include the same properties as before until the next language mode.
This is gated behind the `ExcludePrivateFromMemberwiseInit` feature.
rdar://122416579
If the property isn't memberwise initializable we need to emit its
initial value and call the init accessor. This currently isn't necessary
since all init accessor properties are included in the memberwise
initializer, but the following commit will change this.
This ensures that a `borrow` accessor doesn't introduce temporary bitwise copies of the
representation that could foreshorten the lifetime of memory-dependent references.
In consuming switch when emitting case block that destructures a tuple payload,
it was unconditionally issuing load [take] even if the element was a trivial type.
Later code assumes loads for trivial types have trivial ownership.
The fix uses TypeLowering::emitLoad() instead of directly creating the
load, which handles setting ownership to trivial if the type is trivial.
Fixes#85743
This is an "off-by-one" error because the code to emit bridged
arguments didn't account for the fact that "native" function
type can have a leading implicit isolation parameter if declaration
is `nonisolated(nonsending)`.
Resolves: rdar://164561176
This code was not consulting SILFunctionConventions, so it was
passing things indirect when they are not in sil-opaque-values.
This fixes callers as well to ensure they pass arguments and
results correctly in both modes.
This function will give the wrong convention in SILGen when
using -enable-sil-opaque-values. In particular, it will say
arguments are indirect when they are not.
With multi-threaded IRGen, the global variables associated with "once"
initialization tokens were not getting colocated with their actual
global variables, which caused the initialization code to get split
across different files. This issue manifest as autolinking errors in
some projects.
Fixes rdar://162400654.
We were creating the JumpDests too early, so lowering a 'break' or 'continue'
statement would perform cleanups that were recorded while evaluating the
pack expansion expression, which would cause SIL verifier errors and
runtime crashes.
- Fixes https://github.com/swiftlang/swift/issues/78598
- Fixes rdar://131847933
Implement the @export(implementation) and @export(interface) attributes
to replace @_alwaysEmitIntoClient and @_neverEmitIntoClient. Provide a
warning + Fix-It to start staging out the very-new
@_neverEmitIntoClient. We'll hold off on pushing folks toward
@_alwaysEmitIntoClient for a little longer.
This adds initial support for differentiation of functions that may produce `Error` result.
Essentially we wrap the pullback into `Optional` and emit a diamond-shape control flow pattern depending on whether the pullback value is available or not. VJP emission was modified to accommodate for this. In addition to this, some additional tricks are required as `try_apply` result is not available in the instruction parent block, it is available in normal successor basic block.
As a result we can now:
- differentiate an active `try_apply` result (that would be produced from `do ... try .. catch` constructions)
- `try_apply` when error result is unreachable (usually `try!` and similar source code constructs)
- Support (some) throwing functions with builtin differentiation operators. stdlib change will follow. Though we cannot support typed throws here (yet)
- Correctly propagate error types during currying around differentiable functions as well as type-checking for `@derivative(of:)` attribute, so we can register custom derivatives for functions producing error result
- Added custom derivative for `Optional.??` operator (note that support here is not yet complete as we cannot differentiate through autoclosures, so `x ?? y` works only if `y` is not active, e.g. a constant value).
Some fixes here and there
Allow external declaration of global variables via `@_extern(c)`. Such
variables need to have types represented in C (of course), have only
storage (no accessors), and cannot have initializers. At the SIL
level, we use the SIL asmname attribute to get the appropriate C name.
While here, slightly shore up the `@_extern(c)` checking, which should
fix issue #70776 / rdar://153515764.
Before this patch we referred to builtin names in SILGenBuiltin using raw c
strings. This can lead to potential spelling mistakes yielding bugs. Rather than
doing this, I stole a technique that we use in other parts of the compiler:
constexpr StringLiteral generation using CPP macros. Specifically, I defined in
Builtins.h a new namespace called BuiltinNames and inside of BuiltinNames I used
CPP macros to define a StringLiteral for each Builtin. Thus one can get the
appropriate name for a Builtin by writing:
```
BuiltinNames::Sizeof
```
instead of writing "Sizeof". I also cleaned up the code a little by adding for
functions that take identifiers an additional overload that takes a StringRef
and converts the StringRef to an identifier internally. This just eliminates
unnecessary code from call sites by moving them into the callee.
This is necessary because we need to model its stack-allocation
behavior, although I'm not yet doing that in this patch because
StackNesting first needs to be taught to not try to move the
deallocation.
I'm not convinced that `async let` *should* be doing a stack allocation,
but it undoubtedly *is* doing a stack allocation, and until we have an
alternative to that, we will need to model it properly.
