Teach SILGen to emit a separate SIL function to capture the
initialization of the backing storage type for a wrapped property
based on the wrapped value. This eliminates manual code expansion at
every use site.
Unfortuantely this commit is bigger than I would like but I couldn't think
of any reasonable ways to split it up.
The general idea here is that capture computation is now done for a
SILDeclRef and not an AnyFunctionRef. This allows SIL to represent the
captures of a default argument generator.
Most of AST, Parse, and Sema deal with FileUnits regularly, but SIL
and IRGen certainly don't. Split FileUnit out into its own header to
cut down on recompilation times when something changes.
No functionality change.
This improves on the previous situation:
- The request ensures that the backing storage for lazy properties
and property wrappers gets synthesized first; previously it was
only somewhat guaranteed by callers.
- Instead of returning a range this just returns an ArrayRef,
which simplifies clients.
- Indexing into the ArrayRef is O(1), which addresses some FIXMEs
in the SIL optimizer.
The new analysis simply checks if the captured value has been defined
yet; instead of asserting if it hasn't, we can now emit a diagnostic
using the source location tracked in the capture list.
Fixes <https://bugs.swift.org/browse/SR-4812>, <rdar://problem/40600800>.
Assign separate SILProfiler instances to stored property initializers
and constructors.
Starting with rdar://39460313, coverage reporting for these constructs
was bundled up into a single SILProfiler uniqued by the NominalTypeDecl.
There are two problems with doing this.
First, the shared SILProfiler is given a fake name that can't be
demangled. That breaks Xcode's reports. Second, the relationship
between SILProfiler and SILFunction is supposed to be 1:1. Having a
shared SILProfiler muddies things a bit and requires extra bookkeeping.
rdar://47467864
This is a large patch; I couldn't split it up further while still
keeping things working. There are four things being changed at
once here:
- Places that call SILType::isAddressOnly()/isLoadable() now call
the SILFunction overload and not the SILModule one.
- SILFunction's overloads of getTypeLowering() and getLoweredType()
now pass the function's resilience expansion down, instead of
hardcoding ResilienceExpansion::Minimal.
- Various other places with '// FIXME: Expansion' now use a better
resilience expansion.
- A few tests were updated to reflect SILGen's improved code
generation, and some new tests are added to cover more code paths
that previously were uncovered and only manifested themselves as
standard library build failures while I was working on this change.
The initialization of an instance property that has an attached
property delegate involves the initial value written on the property
declaration, the implicit memberwise initializer, and the default
arguments to the implicit memberwise initializer. Implement SILGen
support for each of these cases.
There is a small semantic change to the creation of the implicit
memberwise initializer due to SE-0242 (default arguments for the
memberwise initializer). Specifically, the memberwise initializer will
use the original property type for the parameter to memberwise
initializer when either of the following is true:
- The corresponding property has an initial value specified with the
`=` syntax, e.g., `@Lazy var i = 17`, or
- The corresponding property has no initial value, but the property
delegate type has an `init(initialValue:)`.
The specific case that changed is when a property has an initial value
specified as a direct initialization of the delegate *and* the
property delegate type has an `init(initialValue:)`, e.g.,
```swift
struct X {
@Lazy(closure: { ... })
var i: Int
}
```
Previously, this would have synthesized an initializer:
```swift
init(i: Int = ???) { ... }
```
However, there is no way for the initialization specified within the
declaration of i to be expressed via the default argument. Now, it
synthesizes an initializer:
```swift
init(i: Lazy<Int> = Lazy(closure: { ... }))
```
The bulk of the changes are to SILGenApply. As we must now evaluate the
payload ArgumentSource to an RValue, we follow the example of subscripts
and lie to the argument emitter. This evaluates arguments at +1 which
can lead to slightly worse codegen at -Onone.
Removes the _getBuiltinLogicValue intrinsic in favor of an open-coded
struct_extract in SIL. This removes Sema's last non-literal use of builtin
integer types and unblocks a bunch of cleanup.
This patch would be NFC, but it improves line information for conditional expression codegen.
Avoid emitting unnecessary basic block for cleanup chains. This is a
general approach that handles all cases while simplifying SILGen
emission and keeping the CFG in a valid state during SILGen.
ASTWalker visits a lazy_initializer_expr once within its associated
var_decl (by way of the parent nominal type). However, SILGen visits the
lazy_initializer_expr while inside of the var_decl's getter. The result
is that there is no coverage mapping information for the contents of the
lazy init within the getter's SILProfiler.
Fixing this will require reworking how profile counters are assigned to
be more in line with what SILGen needs.
As a stop-gap, this patch prevents SILGen from asserting that coverage
mappings are complete with a defensive check which prevents a crash seen
in SR-8429.
rdar://42792053
This initial implementation just delegates from SILGenFunctionBuilder to
SILFunctionBuilder. I was going to start transforming verbose uses of
SILFunctionBuilder into higher level APIs on SILGenFunctionBuilder, but I have
run out of time.
This is a good incremental step forward that will let me hide the constructor of
SILFunctionBuilder after I update the optimizer and thus ensure that
SILFunctionBuilder is only used through appropriate composition APIs.
rdar://42301529
Introduce ExtensionDecl::getExtendedNominal() to provide the nominal
type declaration that the extension declaration extends. Move most
of the existing callers of the callers to getExtendedType() over to
getExtendedNominal(), because they don’t need the full type information.
ExtensionDecl::getExtendedNominal() is itself not very interesting yet,
because it depends on getExtendedType().
Switch a number of callers of the Type-based lookupQualified() over to
the newer (and preferred) declaration-based lookupQualified(). These are
the easy ones; NFC.
This commit does not modify those APIs or their usage. It just:
1. Moves the APIs onto SILFunctionBuilder and makes SILFunctionBuilder a friend
of SILModule.
2. Hides the APIs on SILModule so all users need to use SILFunctionBuilder to
create/destroy functions.
I am doing this in order to allow for adding/removing function notifications to
be enforced via the type system in the SILOptimizer. In the process of finishing
off CallerAnalysis for FSO, I discovered that we were not doing this everywhere
we need to. After considering various other options such as:
1. Verifying after all passes that the notifications were sent correctly and
asserting. Turned out to be expensive.
2. Putting a callback in SILModule. This would add an unnecessary virtual call.
I realized that by using a builder we can:
1. Enforce that users of SILFunctionBuilder can only construct composed function
builders by making the composed function builder's friends of
SILFunctionBuilder (notice I did not use the word subclass, I am talking
about a pure composition).
2. Refactor a huge amount of code in SILOpt/SILGen that involve function
creation onto a SILGenFunctionBuilder/SILOptFunctionBuilder struct. Many of
the SILFunction creation code in question are straight up copies of each
other with small variations. A builder would be a great way to simplify that
code.
3. Reduce the size of SILModule.cpp by 25% from ~30k -> ~23k making the whole
file easier to read.
NOTE: In this commit, I do not hide the constructor of SILFunctionBuilder since
I have not created the derived builder structs yet. Once I have created those in
a subsequent commit, I will hide that constructor.
rdar://42301529
This saves us from having to do overload resolution on the overlay module, which fails if an overlay declaration exactly matches the imported signature of the original ObjC declaration. Fixes rdar://problem/42352695 harder.
The overlay may add overloads for UIApplicationMain for various reasons. When we generate the special `main` implementation for a `@UIApplicationMain` class, we want to call the original function from Objective-C, so pick that one where there are multiple overloads to choose from. Fixes rdar://problem/42352695.
The storage kind has been replaced with three separate "impl kinds",
one for each of the basic access kinds (read, write, and read/write).
This makes it far easier to mix-and-match implementations of different
accessors, as well as subtleties like implementing both a setter
and an independent read/write operation.
AccessStrategy has become a bit more explicit about how exactly the
access should be implemented. For example, the accessor-based kinds
now carry the exact accessor intended to be used. Also, I've shifted
responsibilities slightly between AccessStrategy and AccessSemantics
so that AccessSemantics::Ordinary can be used except in the sorts of
semantic-bypasses that accessor synthesis wants. This requires
knowing the correct DC of the access when computing the access strategy;
the upshot is that SILGenFunction now needs a DC.
Accessor synthesis has been reworked so that only the declarations are
built immediately; body synthesis can be safely delayed out of the main
decl-checking path. This caused a large number of ramifications,
especially for lazy properties, and greatly inflated the size of this
patch. That is... really regrettable. The impetus for changing this
was necessity: I needed to rework accessor synthesis to end its reliance
on distinctions like Stored vs. StoredWithTrivialAccessors, and those
fixes were exposing serious re-entrancy problems, and fixing that... well.
Breaking the fixes apart at this point would be a serious endeavor.
SubstitutionMaps are now just a trivial pointer-sized value, so
pass them by value instead.
I did have to move a couple of functors from Type.h to SubstitutionMap.h
to resolve some issues with forward declarations.
SIL optimizations may rewrite profiling intrinsics in a way that IRGen
can't lower (r://39146527). Don't claim that a coverage mapping has a
guaranteed associated symbol table entry when this happens.
I have not added a test, as this is a defensive workaround until we can
land add a SIL verifier check that prevents profiling intrinsics from
being rewritten.
rdar://40133800
* [Coverage] Only instrument ClosureExprs once
ClosureExprs should only be visited for profiling purposes once, when
the SILFunction definition for the closure is being emitted.
This fixes an issue where the coverage tooling can't figure out how to
attribute the code coverage data of a closure to the right function.
rdar://39200851
* [Coverage] Assert that we don't emit duplicate coverage mappings
While generating SIL for a function with a default argument, we don't
need to emit two identical coverage mappings for the function body. The
same goes for functions which reference foreign functions.
This PR introduces an assertion which should catch similar problems in
the future.
rdar://39297172
* [Coverage] Only instrument nested functions once
Coverage counters for a nested function can be assigned once (in its
parent's scope), and then again (in its own scope). Nested functions
should only be visited for coverage mapping purposes once.
This is related to r://39200851, which is the same bug but for closures.
* [Coverage] Remove special handling of autoclosures
Treating AutoClosureExprs the same as ClosureExprs allows for some nice
code simplifications, and should be more robust.
* [Coverage] Only instrument curried instance methods once
Another fix related to r://39297172, in which we avoid instrumenting the
function associated with a curried thunk more than once.
There are a bunch of methods in this area that do not use ManagedValues, but
that should. This is another step towards unwinding the hairball.
rdar://34222540
