Previously we were creating a SILProfiler for
such functions, but weren't actually emitting the
increment, leading to missed coverage.
Part of the fix for rdar://99931619
We don't need to perform coverage mapping for any
Clang decls we've synthesized, as they have no
user-written code. This is also needed to avoid a
Clang crash when attempting to emit coverage for
decls without source locations (rdar://100172217).
rdar://82820628
We previously eagerly emitted such functions to
ensure that their name data is emitted through the
profiler increment. Now that are able to emit the
profile name data separately, this is unnecessary,
and we can avoid emitting their definitions.
Previously, if all the coverage counters for a
given SIL function were optimized out, we would
have dropped the coverage map on the floor,
leading to inaccurate coverage reports in `-O`.
However LLVM allows us to emit the name data for
the coverage maps separately by defining an
`__llvm_coverage_names` global with the name data,
which is picked up by its instrumentation lowering
pass. Use this to continue to emit coverage maps
for functions that do not get emitted.
rdar://99813754
Unify the mapped behavior with the unmapped
behavior and only ever walk into a pattern binding
decls, top-level code decls, and non-nested
functions. This avoids walking into e.g nested
types, leading to duplicate coverage.
We don't need to handle the unmapped behavior
separately, as top-level code decls are always
explicit, and non-nested functions are always
checked when we create the profiler.
rdar://99963912
This is the only implicit getter case we care
about, the rest do not contain user-written code.
This means that we now otherwise only ever map
explicit decls, which we need to SILGen anyway. As
such I believe this should fix rdar://39332957.
We do still potentially map implicit expressions,
but should only do so for explicit property
initializers. There is one remaining bug where we
can map an implicit property wrapper backing
initalizer, which I'm tracking in rdar://99931619.
Use the new explicit ASTWalker actions to factor
out the skipping logic, ensuring to apply it in
post-visitation too, which fixes a PCMacro crash
(though I don't believe this is a configuration
that ever actually comes up). Also tighten up
invariants such that an `IfExpr` must appear
within an existing region.
This is a dedicated instruction for incrementing a
profiler counter, which lowers to the
`llvm.instrprof.increment` intrinsic. This
replaces the builtin instruction that was
previously used, and ensures that its arguments
are statically known. This ensures that SIL
optimization passes do not invalidate the
instruction, fixing some code coverage cases in
`-O`.
rdar://39146527
Previously we assumed the exit counter was the
same as the entry counter. Update the logic such
that we track break statements (including
implicitly at the end of a case), as well as
early returns and jumps to parent statements. This
follows a similar logic to what we do for if
statements.
rdar://99141044
Previously we weren't compensating for label
jumps and returns, i.e we assumed the exit count
is the same as the entry count. Ensure we follow
the same logic that other labeled statements
follow such that control flow is accounted for.
rdar://98881045
Start visiting LazyInitializerExpr for profiling,
such that we emit a profile counter when
initializing the initial value for the first time.
rdar://43393937
When computing the counter for the region
following a labeled statement such as `if`, avoid
adding a new empty region if the counter for such
a region is known to be zero, i.e unreachable.
This avoids adding spurious unreachable regions
after an if statements where each branch returns,
throws, or otherwise jumps to a parent statement.
We will however still add the region if any code
follows such a statement, making it non-empty.
rdar://29390569
Stop profiling the deallocating deinitializer
function for non-ObjC classes, and instead profile
the destructor, which is where we emit the user's
code written in a `deinit`.
rdar://54443107
Closure literals are sometimes type-checked as one type then immediately converted to another
type in the AST. One particular case of this is when a closure body never throws, but the closure
is used as an argument to a function that takes a parameter that `throws`. Emitting this naively,
by emitting the closure as its original type, then converting to throws, can be expensive for
async closures, since that takes a reabstraction thunk. Even for non-async functions, we still want
to get the benefit of reabstraction optimization for the closure literal through the conversion too.
So if the function conversion just add `throws`, emit the closure as throwing, and pass down the
context abstraction pattern when emitting the closure as well.
"Function builders" are being renamed to "result builders". Add the
corresponding `@resultBuilder` attribute, with `@_functionBuilder` as
an alias for it, Update test cases to use @resultBuilder.
This fixes a 'SILBuilder has no valid insertion point' assertion failure
seen when compiling various projects from the source compat suite.
rdar://68759819
The two sides of an if-expr can't have counts that add up to more than
the count of the if-expr.
This was exposed by https://reviews.llvm.org/D85036.
rdar://66642166
