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.
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
Provide ASTWalker with a customization point to specify whether to
check macro arguments (which are type checked but never emitted), the
macro expansion (which is the result of applying the macro and is
actually emitted into the source), or both. Provide answers for the
~115 different ASTWalker visitors throughout the code base.
Fixes rdar://104042945, which concerns checking of effects in
macro arguments---which we shouldn't do.
`getValue` -> `value`
`getValueOr` -> `value_or`
`hasValue` -> `has_value`
`map` -> `transform`
The old API will be deprecated in the rebranch.
To avoid merge conflicts, use the new API already in the main branch.
rdar://102362022
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.
Preserve the assertions to make sure functions
and closures have bodies, but the other checks
seem redundant. SILGen already asserts that we
have a type-checked SourceFile, and we already
control what nodes we call `createProfiler` for.
For now this just wraps an ASTNode, but in the
future it will allow us to model counters
that cannot simply hang off ASTNodes, e.g
error branch counters.
Use a main entry-point instead of a null
SILDeclRef. Eventually we'll want to unify the
emission here such that we visit all the
TopLevelDecls in one shot (and just use a single
profiler), but for now we can just hand the
SILProfiler the expected SILDeclRef.
Use a BumpPtrAllocator instead of a linked list,
and allocate internally within the CounterExpr so
we can just pass about values instead of pointers
and references. This allows us to eliminate
`CounterExpr::Ref`.
Unfortunately this means we can no longer store
CounterExprs in the SourceMappingRegions for
nodes, as we were previously using pointers to
propagate updates the counters made after the
region was popped. Instead we now have to query
the `CounterMap`. But IMO this is a worthwhile
tradeoff for code that's easier to reason about.
It seems like this defensive logic was written
back when we could create SILProfilers for
declarations in addition to definitions. Now we
should only ever create SILProfilers for
definitions, so we can assert that we always have
a function body available.
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
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.
Replace the use of bool and pointer returns for
`walkToXXXPre`/`walkToXXXPost`, and instead use
explicit actions such as `Action::Continue(E)`,
`Action::SkipChildren(E)`, and `Action::Stop()`.
There are also conditional variants, e.g
`Action::SkipChildrenIf`, `Action::VisitChildrenIf`,
and `Action::StopIf`.
There is still more work that can be done here, in
particular:
- SourceEntityWalker still needs to be migrated.
- Some uses of `return false` in pre-visitation
methods can likely now be replaced by
`Action::Stop`.
- We still use bool and pointer returns internally
within the ASTWalker traversal, which could likely
be improved.
But I'm leaving those as future work for now as
this patch is already large enough.
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
Rather than re-computing the counter indices as we
walk, use the indices that we've already computed
as a part of MapRegionCounters. This should be
NFC.
Eventually we should also stop duplicating the
counter arithmetic, and instead rely on the
CounterExprs computed by CoverageMapping. For now
I'm leaving that as follow-up work.
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
Refactor `CounterExpr::expand` to accept a function
lookup for the counter indices, and add
`isSemanticallyZero` to allow for checking whether
a simplified counter is 0.
MSVC does not realize that the switch is exhaustive and requires that
the path is explicitly marked as unreachable. This silences the C4715
warning ("not all control paths return a value").
Like switch cases, a catch clause may now include a comma-
separated list of patterns. The body will be executed if any
one of those patterns is matched.
This patch replaces `CatchStmt` with `CaseStmt` as the children
of `DoCatchStmt` in the AST. This necessitates a number of changes
throughout the compiler, including:
- Parser & libsyntax support for the new syntax and AST structure
- Typechecking of multi-pattern catches, including those which
contain bindings.
- SILGen support
- Code completion updates
- Profiler updates
- Name lookup changes
