getVarInfo() now always returns a variable with a location and scope.
To opt out of this change, getVarInfo(false) returns an incomplete variable.
This can be used to work around bugs, but should only really be used for
printing.
The complete var info will also contain the type, except for debug_values,
as its type depends on another instruction, which may be inconsistent if
called mid-pass.
All locations in debug variables are now also stripped of flags, to avoid
issues when comparing or hashing debug variables.
The type bridging logic assumed that if a value of type `Swift.Bool` is passed to a Clang function as an argument, then the type of the parameter must be a Clang built-in type (usually `_Bool`). This is not always correct. For instance, the type might be a templated const reference.
rdar://125508505
* Implement Builtin.freeze for integer and integer-vector types.
https://llvm.org/docs/LangRef.html#freeze-instruction
> If the argument is undef or poison, ‘freeze’ returns an arbitrary, but fixed, value of type ‘ty’. Otherwise, this instruction is a no-op and returns the input argument. All uses of a value returned by the same ‘freeze’ instruction are guaranteed to always observe the same value, while different ‘freeze’ instructions may yield different values.
It's most importation for integer and integer-vector types because floating-point results are generally not poison (except in the case of conversion from poison integer values).
However, we might want to implement this for other types as well in the future.
* Make builtin.freeze TrivialUse
Also fix filecheck patterns for its test to work with asserts build.
The new boundary allows for invalid OSSA where values are not consumed
on paths leading to blocks that exit the function normally. In such
cases, the value is allowed to continue leaking as before.
This lambda has to do with availability or the lack thereof but
unreachable instructions are of interest in this context so using the
wrong name confuses things unnecessarily.
Like `?` or property access, `x!` can be borrowing, consuming, or mutated
through depending on the use site and the ownership of the base value.
Alter SILGen to emit `x!` as a borrowing operation when the result is only
used as a borrow. Fix the move-only checker not to treat the unreachable
branch as a dead path for values and try to destroy the value unnecessarily
and possibly out-of-order with cleanups on the value. Fixes rdar://127459955.
module when package serialization is enabled, return maximal resilience expansion
in SILFunction::getResilienceExpansion(). This allows aggregate types to be generated
as loadable SIL types which otherwise are address-only in a serialized function.
During type lowering, opaque flag setting is also skipped if package serialization
is enabled.
Resolves rdar://127400743
When a store is salvaged, its debug_value will have two locations:
the location of the store, attached to the debug_value instruction,
and the location of the variable, attached to the SILDebugVariable.
The getDecl function was using the location of the store, instead
of the location of the variable, and so was returning nullptr.
SIL cannot be assumed to be 100% valid if errors were detected in diagnostic passes. For example in DefiniteInitialization.
Fixes some false verifier errors in case -sil-verify-all is used.
rdar://127519229
rdar://127518886
The copy operator has been implemented and doesn't use it. Remove
`Builtin.copy` and `_copy` as much as currently possible.
Source compatibility requires that `_copy` remain in the stdlib. It is
deprecated here and just uses the copy operator.
Handling old swiftinterfaces requires that `Builtin.copy` be defined.
Redefine it here as a passthrough--SILGen machinery will produce the
necessary copy_addr.
rdar://127502242
I suspect there are latent bugs here with generic-class-constrained existentials,
same-element requirements involving packs, etc. We can't assume that the
local archetypes don't have "hidden" dependencies on the outer parameters
that are not encoded in the thunk's interface type.
The option -disable-sil-ownership-verifier should almost never be used.
But if it is, it should result in ownership verification being disabled,
even when done via direct calls to `SILFunction::verifyOwnership`.
There are still a couple of test cases that use
-disable-sil-ownership-verifier.
