It is necessary for opaque values where for casts that will newly start
out as checked_cast_brs and be lowered to checked_cast_addr_brs, since
the latter has the source formal type, IRGen relies on being able to
access it, and there's no way in general to obtain the source formal
type from the source lowered type.
The coverage format version we use is automatically
set to whatever the latest version LLVM has. This
resulting in us outputting version 6 as our
format without having made the changes necessary
to reflect the new format. Update the emission
logic to take account for [the new changes in
version 6][1] (we need to include the current
working directory as the first element of the list
of files we output). Additionally, add a
`static_assert` so we don't get caught out by
version bumps in the future. Note we can't pin our
version, as it must stay in sync with the version
Clang is using.
[1]: https://llvm.org/docs/CoverageMappingFormat.html#llvm-ir-representation
We may want to revisit this in the future, but for
now let's avoid profiling code in generated
buffers. To make this work we'll need to come up
with a scheme for writing out the generated buffers
such that tools like `llvm-cov` can reference them.
rdar://109562235
Introduce SingleValueStmtExpr, which allows the
embedding of a statement in an expression context.
This then allows us to parse and type-check `if`
and `switch` statements as expressions, gated
behind the `IfSwitchExpression` experimental
feature for now. In the future,
SingleValueStmtExpr could also be used for e.g
`do` expressions.
For now, only single expression branches are
supported for producing a value from an
`if`/`switch` expression, and each branch is
type-checked independently. A multi-statement
branch may only appear if it ends with a `throw`,
and it may not `break`, `continue`, or `return`.
The placement of `if`/`switch` expressions is also
currently limited by a syntactic use diagnostic.
Currently they're only allowed in bindings,
assignments, throws, and returns. But this could
be lifted in the future if desired.
Iterating over the IRGenModules and emitting every
SILCoverageMap in the SILModule meant that we
were emitting N copies of the coverage maps for
parallel IRGen, where N is the number of output
object files.
This has always been wrong, but was previously
saved by the fact that we would drop the coverage
map on the floor if we didn't have the name data
available. This would only be the case for the
IRGenModule that had the emitted entity to
profile, in addition to any IRGenModules that
had inlined the body of a profiled enitity. As
such, this prevented the duplication from being
too egregious. However with the recent change to
emit unused name data in the case where we don't
already have name data available, we're now fully
duplicating every coverage mapping, and emitting a
ton of redundant name data.
Fix things such that we only emit coverage mapping
records for the IRGenModule that corresponds to
the entity being profiled.
rdar://102905496
We may have a skipped function body when walking
over a SourceFile to profile top-level code,
adjust the assertion so we ignore cases that we
don't want to profile anyway.
rdar://102405053
Instead of creating and destroying a SILProfiler
per TopLevelCodeDecl, setup a single profiler
for the top-level entry point function, and visit
all the TopLevelCodeDecls when mapping regions.
Remove a case where we know we don't have a
profiler, and avoid incrementing for a distributed
factory method. Otherwise such cases could pass
a null ASTNode, which will become an assertion
failure in a future commit.
While we're here, let's standardize on emitting
the profiler increment for function entry after
the prolog, as if there's e.g an unreachable
parameter, the increment can be safely elided
anyway.
This replaces some of the existing checks, and
ensures that we don't emit coverage maps for
property wrapper backing initializers that don't
contain user code.
rdar://99931619
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.
