This function is clearly returning the opposite of what its name says:
```
const SILDebugScope *SILBasicBlock::getScopeOfFirstNonMetaInstruction() {
for (auto &Inst : *this)
if (Inst.isMetaInstruction())
return Inst.getDebugScope();
return begin()->getDebugScope();
}
```
Looking at the PR history (sadly GH doesn't preserve old versions of the patch...)
https://github.com/apple/swift/pull/15575
There was this snippet of code:
```
// Find the correct debug scope for alloc stack. We want to give to the
// expanded sequence the correct debug scope so we skip over instructions
// that aren't lowered to anything real (e.g. debug_value).
static const SILDebugScope *findAllocStackDebugScope(SILBasicBlock &BB) {
auto It = BB.begin();
while (It != BB.end()) {
if (!isMaintenanceInst(&*It))
```
We don't know what used to be after that line but, based on the comments, it
must have been a `return It->getDebugScope()`.
Adrian then asked the author to make this a different helper function
`getScopeOfFirstNonMetaInstruction`, and the subsequence force-push had the code
we see today. So maybe it was in this conversion that the author made the
mistake?
Fixing the implementation doesn't cause any tests to fail (sadly the original PR
did not add any SIL->SIL tests, which would have been ideal).
This allows calling a C++ function with default arguments from Swift without having to explicitly specify the values of all arguments.
rdar://103975014
```
let c = SomeClass()
```
is turned into
```
private let outlinedVariable = SomeClass() // statically initialized and allocated in the data section
let c = outlinedVariable
```
rdar://111021230
rdar://115502043
Also, make the ObjectOutliner work for OSSA. Though, it currently doesn't run in the OSSA pipeline.
Optionally, the dependency to the initialization of the global can be specified with a dependency token `depends_on <token>`.
This is usually a `builtin "once"` which calls the initializer for the global variable.
Concurrency runtime expects discarding task operation entrypoint
function not to have result type, but the current SILGen
implementation generates reabstraction thunk to convert `() -> Void`
to `() -> T` for the operation function.
Since the `T` is always `Void` for DiscardingTG, the mismatch of result
type expectation does not cause any problem on most platforms, but the
signature mismatch causes a problem on WebAssembly.
This patch introduces new builtin operations for creating discarding
task, which always takes `() -> Void` as the operation function type.
We need the self metatype parameter to correctly lower
DynamicSelfType in IRGen, so plumb this through to all
calls of init accessors, and inside the prolog of an
init accessor definition.
This does not break the public ABI, because init
accessors are never public. Also for value types, the
metatype is thin, so it should not change generated
code.
For classes we need the metatype in the general case
because of `Self`, but hopefully in most cases the
init accessor can be inlined away and the value_metatype
instruction subject to dead code elimination.
Fixes rdar://problem/119822466.
An instruction is a deinit barrier whenever one of three component
predicates is true for it. In the case of applies, it is true whenever
one of those three predicates is true for any of the instructions in any
of its callees; that fact is cached in the side-effect analysis of every
function.
If side-effect analysis or callee analysis is unavailable, in order to
define each of those three component predicates on a
`FullApplySite`/`EndApplyInst`/`AbortApplyInst`, it would be necessary
to define them to conservatively return true: it isn't known whether any
of the instructions in any of the callees were deinit barriers.
Refactored the two versions of the deinit barrier predicate (namely
`Instruction.isDeinitBarrier(_:) and
`swift::mayBeDeinitBarrierNotConsideringSideEffects`) to handle
`FullApplySite`/`EndApplyInst`/`AbortApplyInst`s specially first (to
look up the callees' side-effect and to conservatively bail,
respectively). Asserted that the three component predicates are not
called with `FullApplySite`/`EndApplyInst`/`AbortApplyInst`s. Callers
should instead use the `isDeinitBarrier` APIs.
An alternative would be to conservatively return true from the three
components. That seems more likely to result in direct calls to these
member predicates, however, and at the moment at least there is no
reason for such calls to exist. If some other caller besides the
deinit-barrier predicates needs to call this function, side-effect
analysis should be updated to cache these three properties separately at
that point.
When an instruction `mayReadOrWriteMemory`, the `mayAccessPointer`
predicate relies on the `visitAccessedAddress` utility to determine
whether an instruction may access a pointer. That utility doesn't (and
can't, without changing the representation of the builtin) visit
`RawPointer` operands as used by memmove/memcpy builtins.
Previously, this resulted `mayAccessPointer` returning `false` for such
builtins. Here, this is fixed by making the predicate handle
`BuiltinInsts` separately. Instead of just always returning `true` in
the face of a builtin, rely on the BuiltinInfo associated with a
BuiltinInst and use `mayReadOrWriteMemory`.
rdar://120656227
The instruction exists to express the atomic initialization of a
tuple-typed address in address-lowered mode. In opaque-values mode,
this is expressed as an assign/store.
When @_objcImplementation is used to implement a C function marked with __asm__, take the attribute into account when mangling SIL references.
In theory this change should also make `clang::OverloadableAttr` functions mangle correctly, but in practice the matching logic for @_cdecl @_objcImplementation doesn’t currently support overloadable functions (and it’s not wise to try anyway, since clang doesn’t promise that their ABI won’t change).
Fixes rdar://120503717.
The dependent 'value' may be marked 'nonescaping', which guarantees that the
lifetime dependence is statically enforceable. In this case, the compiler
must be able to follow all values forwarded from the dependent 'value', and
recognize all final (non-forwarded, non-escaping) use points. This implies
that `findPointerEscape` is false. A diagnostic pass checks that the
incoming SIL to verify that these use points are all initially within the
'base' lifetime. Regular 'mark_dependence' semantics ensure that
optimizations cannot violate the lifetime dependence after diagnostics.
Previously, mayRequirePackMetadata only considered whether a type
involved a pack. That failed to account for the case of outlined value
functions that require pack metadata when the type involves a pack in
its layout. Here, mayRequirePackMetadata now considers also whether the
layout corresponding to a type involves a pack.
rdar://119829826
partial_apply cannot be cloned, even in OSSA. OSSA lowering does
not know how to allocate for multiple partial applies.
Fixes rdar://119768691 (OwnershipModelEliminator triggers assertion
when lowering certain [on_stack] partial_applys in certain
circumstances)
I am doing this in preparation for adding options to SILParameterInfo/
SILResultInfo that state that a parameter/result is transferring. Even though I
could have just introduced a new bit here, I instead streamlined the interface
of SILParameterInfo/SILResultInfo to use an OptionSet instead of individual bits
to make it easier to add new flags here. The reason why it is easier is that
along API (e.x.: function argument) boundaries one does not have to marshal each
field or pass each field. Instead one can just pass the whole OptionSet as an
opaque thing. Using this I was able to change serialization/deserialization of
SILParameterInfo/SILResultInfo so that one does not need to update them if one
adds new fields!
The reason why I am doing this for both SILParameterInfo/SILResultInfo in the
same commit is because they share code in the demangler that I did not want to
have to duplicate in an intervening commit. By changing them both at the same
type, I didn't have to change anything without an actual need to.
I am doing this in a separate commit from adding transferring support so I can
validate correctness using the tests for the options already supported
(currently only differentiability).
While printing them as `some P` makes sense in the AST since they
only ever appear at their definition point, in the body of a SIL
function, opaque parameter types can be referenced by various
instructions, like any other generic parameter type.
Instead of printing out `some P` or `<anonymous>` depending on
context, neither of which actually parsed, instead print them
with the canonical type `τ_d_i` notation. Since it's printed this
way in the generic parameter list as well, it parses back in.
Fixes rdar://problem/119823811.
https://github.com/apple/swift/pull/70100 prohibited `package` declarations from
ever being serialized in order to solve a problem in which the declarations
were being serialized inappropriately. That's too heavy handed, though, because
an `@_alwaysEmitIntoClient` function with `package` access *must* be serialized
because it has public non-abi linkage.
Resolves rdar://104711625
