It had a bug that would cause it to return incorrect results for some decls
with invalid source locations. Since not all declarations introduce a new
`DeclContext`, it's not sufficient to walk the decl context hiearchy when
computing availability for a decl.
We started building iOS sanitizers when switching to
`LLVM_ENABLE_RUNTIMES` to build compiler-rt, and turns out they
currently provide only the arm64 slice.
Addresses rdar://151782340
Type annotations for instruction operands are omitted, e.g.
```
%3 = struct $S(%1, %2)
```
Operand types are redundant anyway and were only used for sanity checking in the SIL parser.
But: operand types _are_ printed if the definition of the operand value was not printed yet.
This happens:
* if the block with the definition appears after the block where the operand's instruction is located
* if a block or instruction is printed in isolation, e.g. in a debugger
The old behavior can be restored with `-Xllvm -sil-print-types`.
This option is added to many existing test files which check for operand types in their check-lines.
ClangImporter synthesized declarations inherently do not have user written
code. Unfortunately, despite that they are not always marked implicit as they
should be. This was causing a crash when attempting to generate profile
coverage maps for synthesized constructors for imported structs.
I tried marking the constructors implicit, but that had too many knock-on
effects in tests. This more targeted fix unblocks compatibility suite testing
without trying to grapple with the implications of that more fundamental fix.
Resolves rdar://139486938.
Allow detecting the compiler runtime libraries for
non-Darwin platforms, allowing us to test that
programs relying on these libraries link successfully.
Make sure we walk macro expansion decls to handle
cases where e.g a binding introduces control flow.
This should be a pretty uncommon case since bindings
introduced by macros aren't actually usable when
expanded in local contexts, but handle it all the
same.
Ignore any regions recorded while inside a macro
expansion, but account for any control flow that
may have happened such that the exit count is
correctly adjusted. This allows e.g throwing function
calls to behave correctly within the expansion.
rdar://129081384
Fix counters for regions following `else if`s, fix
the counters for `else if` conditions, and fix
handling of `break` statements. Also while here,
clean up the handling of branch exit regions such
that we don't generate multiple overlapping
regions for each branch, but a single region at
the end of the entire `if` statement that accounts
for all exiting control flow.
rdar://104078910
rdar://104079242
Previously we were walking into the
PropertyWrapperValuePlaceholderExpr when generating
coverage for a property wrapper backing initializer.
This meant that we were duplicating the coverage of
the initializer expression, and it could cause
crashes if a refined counter was introduced within
the top-most expression region, such as with a
throwing expression in a `try!`.
rdar://118939162
Previously we would ignore the effect that an if
statement or ternary's condition exit counter might
have on its branches, as we assumed a condition
can't do any control flow. However, in the case
where the condition throws an error, we need to
account for the error branch.
Ensure that `try?` expressions appropriately
scope the regions generated by child
error-throwing expressions, such that the
non-error branch does not extend beyond the region
of the `try?`.
Previously the branches of a ternary would cut off
the coverage after a throwing expression, since
they have their own region, and we pop child
regions when leaving. Update the logic to use the
existing counter adjustment logic when we leave
the scope, ensuring that we push a new counter to
reflect the exit count of the scope.
The logic here previously worked by computing the
exit count by taking the parent count and
subtracting any control flow that jumped out of the
clauses. With `try` handling fixed, this no longer
works correctly, since a `try` shouldn't be
subtracted if the error is caught be one of the
catches, as that's not actually leaving the
statement. We could write the logic to determine
where a `try` is jumping to, but the logic here is
already pretty brittle, relying on being sprinkled
in various different places.
For now, let's take the more straightforward
approach and handle do-catches the same way we
handle switches, we initialize the exit counter to
0, and add on each exit count of each branch. This
lets us re-use the existing CaseStmt handling
logic. This doesn't necessarily produce the most
optimal counter expressions, but I want to replace
this all with a SILOptimizer pass anyway, which
will be able to much more easily compute optimal
counter expressions.
rdar://100470244
We can terminate all the regions up to the last
AST node in the stack, since regions without AST
nodes are refinements of the region with the AST
node, and should be terminated the same. This
avoids leaving some regions that extend past e.g
the `return` of a function.
The region in the test case that changes here is:
```
[[@LINE+9]]:28 -> [[@LINE+12]]:4 : (0 - 1)
```
this was extending past the return. Now it is:
```
[[@LINE]]:6 -> [[@LINE+4]]:11 : (0 - 1)
```
Apologies, I also refactored the test case at the
same time which makes the difference harder to see,
but the main point is that this region now terminates
at the return, the same as the others.
For any `#if` blocks in the function we're emitting,
emit skipped ranges for the inactive clauses, including
the syntax for the `#if` itself, since that should
not be considered executable code.
rdar://116860865
Now that we keep many more functions on unoptimized builds, many tests
need to be changed to either:
- Account for function that wasn't being emitted before to being emitted
now.
- Account for functions that previously were being emitted lazily to
being emitted eagerly now.
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
