I was originally hoping to reuse mark_must_check for multiple types of checkers.
In practice, this is not what happened... so giving it a name specifically to do
with non copyable types makes more sense and makes the code clearer.
Just a pure rename.
We do this in `GetterSetterComponent` but overlooked it for default initialization
expressions. If init/setter require `newValue` to be passed indirectly we have to
make sure to materialize it before handing to `assign_or_init` instruction.
Resolves: rdar://114350227
`nonmutating set` gets a copy of "self" in `GetterSetterComponent`
which is expected for partial application of the setter but doesn't
work for "self" reference that `assign_or_init` instruction needs
to emit references to stored properties during lowering. We need to
make sure that "self" is always a reference to rootself of the
constructor before passing it to `assign_or_init`.
Resolves: https://github.com/apple/swift/issues/67827
Resolves: rdar://114433261
Back in 33f4f57cc4 of
https://github.com/apple/swift/pull/28044 fame,
non-`CaptureKind::Constant:` uses of `Entry.val` in
`SILGenFunction::emitCaptures` were replaced with a use of the newly
added lambda `getAddressValue` applied at `Entry.val`.
The replacement of `Entry.value` with `getAddressValue(Entry.value)` in
the case of `CaptureKind::Box` had no effect.
Back then, the reason was that the condition
SGM.Types
.getTypeLowering(
valueType,
TypeExpansionContext::noOpaqueTypeArchetypesSubstitution(
expansion.getResilienceExpansion()))
.isAddressOnly() &&
!entryValue->getType().isAddress()
under which something other than the input was returned would never
hold: CaptureKind::Box is used for LValues and those never satisfy
`!entryValue->getType().isAddress()`.
Since that PR, the getAddressValue lambda has grown. There are two
additional aspects to consider: (1) forceCopy, (2) isPack. (1) is not
relevant because `false` was being passed for the `CaptureKind::Box`
case. (2) can not currently happen because pack lvalues haven't been
implemented. But even if they were implemented, the argument passed to
the lambda would still need to be an address.
The same all holds for the `CaptureKind::ImmutableBox` case which only
differs from the `CaptureKind::Box` by a couple of lines.
Way back in
commit d0bb0274e9
Author: Joe Groff <jgroff@apple.com>
Date: Mon Nov 23 11:47:09 2015 -0800
the convention was changed such that LValues were passed only by box
rather than by box and address. Delete the comment that says that both
are passed.
Moving the query implementation up to the AST library from SIL will allow
conveniences to be written on specific AST element classes. For instance, this
will allow `EnumDecl` to expose a convenience that enumerates element decls
that are available during lowering.
Also, improve naming and documentation for these queries.
This is a futile attempt to discourage future use of getType() by
giving it a "scary" name.
We want people to use getInterfaceType() like with the other decl kinds.
Instead of taking a setter type, let's switch over to a more general
`AccessorKind` which allows us to cover init accessors and simplify
`emitApplySetterToBase`.
This is a preliminary step towards enabling default initialization of
init accessor properties in user-defined initializers because this logic
would have to be shared by multiple places during SILGen.
`Initialization` is stateful and not meant to be emitted into multiple times across different contexts.
If emitting into an initialization causes it to be split or aborted, that will carry over into
further uses of the initialization. This was happening during `if` and `switch` expression
emission, leading to miscompiles or compiler crashes. Fix this by saving only the buffer when
we prepare emission for a statement expression, and creating the initialization in the scope
where the expression for a branch actually gets emitted. Fixes rdar://112213253.
Attribute @_silgen_name is today only allowed to be used on functions, this change allows usage on globals as well. The motivation for that is to be able to "forward declare" globals just like it's today possible to do with functions (for the cases where it's not practical or convenient to use a bridging header).
Separately, this change also adds a @_silgen_name(raw: ...) syntax, which simply avoids mangling the name (by using the \01 name prefix that LLVM uses). The motivation for that is to be able to reference the "magic Darwin linker symbols" that can be used to look up section bounds (in the current dylib/module) -- those symbols don't use the underscore prefix in their mangled names.
Reformatting everything now that we have `llvm` namespaces. I've
separated this from the main commit to help manage merge-conflicts and
for making it a bit easier to read the mega-patch.
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
The previous lazy discovery did not always work because sometimes a debug_value
is emitted before the first SIL instruction in the variable's scope.
rdar://110841130
This source location will be used to determine whether to add a name lookup
option to exclude macro expansions when the name lookup request is constructed.
Currently, the source location argument is unused.
The previous code made the assumption that the ASTScope for a variable
declaration should be the one of the declaration's source location. That is not
necessarily the case, in some cases it should be an ancestor scope. This patch
introduces a map from ValueDecl -> ASTScope that is derived from querying each
ASTScope for its locals, which matches also what happens in name lookup. This
patch also fixes the nesting of SILDebugScopes created for guard statement
bodies, which are incorrectly nested in the ASTScope hierarchy.
rdar://108940570
An expression macro can expand not just to code inside the function, but also to
a closure. Such a closure needs to be treated similar to any functions generated
from a freestanding macro: Its instructions should have locations that point
straight into the macro buffer. Instructions that are expanded into the same
function as the macro expansion can be represented using inline locations
pointing back to the macro expansion, but this is not an option for top-level
function declaration.
https://github.com/apple/swift/issues/65484
rdar://108618562
When `-unavailable-decl-optimization=stub` is specified, insert a call to
`_diagnoseUnavailableCodeReached()` at the beginning of the function to cause
it to trap if executed at run time.
Part of rdar://107388493
In an earlier version of the ASTScope -> SILdebugScope translation a workaround
was put into place that would select the current debug scope if an ASTScope was
marked as ignoreInDebugInfo. Removing this workaround makes the translation more
predictable as it eliminated the dependency on the current SILBuilder state. The
property wrapper tests still pass without this.
This uncovers a situations with let bindings where the SIL instructions are
emitted RHS before LHS, which does violate the di-hole verifier. This is
addressed by relaxing the verifier for now.
rdar://108736443
Before this patch the parents of SILDebugScopes representing macro expansions
were missing the inlinedAt field, which resulted in incorrent LLVM IR being
produced. This is fixed by first computing the inlined call site for a macro
expansion and then computing the nested SILDebugScope for the ASTScope of the
expanded nodes; adding the inlinedAt field to all of levels of parent scopes.
rdar://108323748
This patch replaces the stateful generation of SILScope information in
SILGenFunction with data derived from the ASTScope hierarchy, which should be
100% in sync with the scopes needed for local variables. The goal is to
eliminate the surprising effects that the stack of cleanup operations can have
on the current state of SILBuilder leading to a fully deterministic (in the
sense of: predictible by a human) association of SILDebugScopes with
SILInstructions. The patch also eliminates the need to many workarounds. There
are still some accomodations for several Sema transformation passes such as
ResultBuilders, which don't correctly update the source locations when moving
around nodes. If these were implemented as macros, this problem would disappear.
This necessary rewrite of the macro scope handling included in this patch also
adds proper support nested macro expansions.
This fixes
rdar://88274783
and either fixes or at least partially addresses the following:
rdar://89252827
rdar://105186946
rdar://105757810
rdar://105997826
rdar://105102288
