[Clang] [NFC] Fix unintended `-Wreturn-type` warnings everywhere in the test suite (#123464)

In preparation of making `-Wreturn-type` default to an error (as there
is virtually no situation where yo

[Clang] [NFC] Fix unintended `-Wreturn-type` warnings everywhere in the test suite (#123464)

In preparation of making `-Wreturn-type` default to an error (as there
is virtually no situation where you’d *want* to fall off the end of a
function that is supposed to return a value), this patch fixes tests
that have relied on this being only a warning, of which there seem
to be 3 kinds:

1. Tests which for no apparent reason have a function that triggers the
warning.

I suspect that a lot of these were on accident (or from before the
warning was introduced), since a lot of people will open issues w/ their
problematic code in the `main` function (which is the one case where you
don’t need to return from a non-void function, after all...), which
someone will then copy, possibly into a namespace, possibly renaming it,
the end result of that being that you end up w/ something that
definitely is not `main` anymore, but which still is declared as
returning `int`, and which still has no return statement (another reason
why I think this might apply to a lot of these is because usually the
actual return type of such problematic functions is quite literally
`int`).

A lot of these are really old tests that don’t use `-verify`, which is
why no-one noticed or had to care about the extra warning that was
already being emitted by them until now.

2. Tests which test either `-Wreturn-type`, `[[noreturn]]`, or what
codegen and sanitisers do whenever you do fall off the end of a
function.

3. Tests where I struggle to figure out what is even being tested
(usually because they’re Objective-C tests, and I don’t know
Objective-C), whether falling off the end of a function matters in the
first place, and tests where actually spelling out an expression to
return would be rather cumbersome (e.g. matrix types currently don’t
support list initialisation, so I can’t write e.g. `return {}`).

For tests that fall into categories 2 and 3, I just added
`-Wno-error=return-type` to the `RUN` lines and called it a day. This
was especially necessary for the former since `-Wreturn-type` is an
analysis-based warning, meaning that it is currently impossible to test
for more than one occurrence of it in the same compilation if it
defaults to an error since the analysis pass is skipped for subsequent
functions as soon as an error is emitted.

I’ve also added `-Werror=return-type` to a few tests that I had already
updated as this patch was previously already making the warning an error
by default, but we’ve decided to split that into two patches instead.

show more ...

[Coverage] Resurrect Branch:FalseCnt in SwitchStmt that was pruned in #112694 (#120418)

I missed that FalseCnt for each Case was used to calculate percentage in
the SwitchStmt. At the moment I resu

[Coverage] Resurrect Branch:FalseCnt in SwitchStmt that was pruned in #112694 (#120418)

I missed that FalseCnt for each Case was used to calculate percentage in
the SwitchStmt. At the moment I resurrect them.

In `!HasDefaultCase`, the pair of Counters shall be `[CaseCountSum,
FalseCnt]`. (Reversal of before #112694)
I think it can be considered as the False count on SwitchStmt.

FalseCnt shall be folded (same as current impl) in the coming
SingleByteCoverage changes, since percentage would not make sense.

show more ...

[Coverage] Introduce "partial fold" on BranchRegion (#112694)

Currently both True/False counts were folded. It lost the information,
"It is True or False before folding." It prevented recalling bra

[Coverage] Introduce "partial fold" on BranchRegion (#112694)

Currently both True/False counts were folded. It lost the information,
"It is True or False before folding." It prevented recalling branch
counts in merging template instantiations.

In `llvm-cov`, a folded branch is shown as:

- `[True: n, Folded]`
- `[Folded, False n]`

In the case If `n` is zero, a branch is reported as "uncovered". This is
distinguished from "folded" branch. When folded branches are merged,
`Folded` may be dissolved.

In the coverage map, either `Counter` is `Zero`. Currently both were
`Zero`.

Since "partial fold" has been introduced, either case in `switch` is
omitted as `Folded`.

Each `case:` in `switch` is reported as `[True: n, Folded]`, since
`False` count doesn't show meaningful value.

When `switch` doesn't have `default:`, `switch (Cond)` is reported as
`[Folded, False: n]`, since `True` count was just the sum of `case`(s).
`switch` with `default` can be considered as "the statement that doesn't
have any `False`(s)".

show more ...

Revert "Revert "[Coverage] Emit gap region between statements if first statements contains terminate statements.""

Reland with update on test case ContinuousSyncmode/basic.c.

This reverts commit fe

Revert "Revert "[Coverage] Emit gap region between statements if first statements contains terminate statements.""

Reland with update on test case ContinuousSyncmode/basic.c.

This reverts commit fe5c2c3ca682b140dd5e640e75948363b6b25ef9.

show more ...

Revert "[Coverage] Emit gap region between statements if first statements contains terminate statements."

This reverts commit 2d7374a0c680f96bdcdb3d05034a93bf145d140f.
Breaks ContinuousSyncMode/basi

Revert "[Coverage] Emit gap region between statements if first statements contains terminate statements."

This reverts commit 2d7374a0c680f96bdcdb3d05034a93bf145d140f.
Breaks ContinuousSyncMode/basic.c in check-profile on macOS.

show more ...

[Coverage] Emit gap region between statements if first statements contains terminate statements.

Differential Revision: https://reviews.llvm.org/D97101

[Coverage] Add support for Branch Coverage in LLVM Source-Based Code Coverage

This is an enhancement to LLVM Source-Based Code Coverage in clang to track how
many times individual branch-generating

[Coverage] Add support for Branch Coverage in LLVM Source-Based Code Coverage

This is an enhancement to LLVM Source-Based Code Coverage in clang to track how
many times individual branch-generating conditions are taken (evaluate to TRUE)
and not taken (evaluate to FALSE). Individual conditions may comprise larger
boolean expressions using boolean logical operators. This functionality is
very similar to what is supported by GCOV except that it is very closely
anchored to the ASTs.

Differential Revision: https://reviews.llvm.org/D84467

show more ...

[Coverage] Add empty line regions to SkippedRegions

Differential Revision: https://reviews.llvm.org/D84988

Reland [Coverage] Add comment to skipped regions

Bug filled here: https://bugs.llvm.org/show_bug.cgi?id=45757.
Add comment to skipped regions so we don't track execution count for lines containing o

Reland [Coverage] Add comment to skipped regions

Bug filled here: https://bugs.llvm.org/show_bug.cgi?id=45757.
Add comment to skipped regions so we don't track execution count for lines containing only comments.

Differential Revision: https://reviews.llvm.org/D83592

show more ...

Revert abd45154b "[Coverage] Add comment to skipped regions"

This casued assertions during Chromium builds. See comment on the code review

> Bug filled here: https://bugs.llvm.org/show_bug.cgi?id=4

Revert abd45154b "[Coverage] Add comment to skipped regions"

This casued assertions during Chromium builds. See comment on the code review

> Bug filled here: https://bugs.llvm.org/show_bug.cgi?id=45757.
> Add comment to skipped regions so we don't track execution count for lines containing only comments.
>
> Differential Revision: https://reviews.llvm.org/D84208

This reverts commit abd45154bdb6b76c5b480455eacc8c75b08242aa and the
follow-up 87d725473380652bbe845fd2fbd9c0507a55172f.

show more ...

[Coverage] Add comment to skipped regions

Bug filled here: https://bugs.llvm.org/show_bug.cgi?id=45757.
Add comment to skipped regions so we don't track execution count for lines containing only com

[Coverage] Add comment to skipped regions

Bug filled here: https://bugs.llvm.org/show_bug.cgi?id=45757.
Add comment to skipped regions so we don't track execution count for lines containing only comments.

Differential Revision: https://reviews.llvm.org/D84208

show more ...

[Coverage] Emit a gap region to cover switch bodies

Emit a gap region beginning where the switch body begins. This sets line
execution counts in the areas between non-overlapping cases to 0.

This a

[Coverage] Emit a gap region to cover switch bodies

Emit a gap region beginning where the switch body begins. This sets line
execution counts in the areas between non-overlapping cases to 0.

This also removes some special handling of the first case in a switch:
these are now treated like any other case.

This does not resolve an outstanding issue with case statement regions
that do not end when a region is terminated. But it should address
llvm.org/PR44011.

Differential Revision: https://reviews.llvm.org/D70571

show more ...

[Coverage] Emit a gap area after if conditions

The area immediately after the closing right-paren of an if condition
should have a count equal to the 'then' block's count. Use a gap region
to set th

[Coverage] Emit a gap area after if conditions

The area immediately after the closing right-paren of an if condition
should have a count equal to the 'then' block's count. Use a gap region
to set this count, so that region highlighting for the 'then' block
remains precise.

This solves a problem we have with wrapped segments. Consider:

1| if (false)
2| foo();

Without a gap area starting after the condition, the wrapped segment
from line 1 would make it look like line 2 is executed, when it's not.

rdar://35373009

llvm-svn: 317758

show more ...

[Coverage] Precise region termination with deferred regions (reapply)

The current coverage implementation doesn't handle region termination
very precisely. Take for example an `if' statement with a

[Coverage] Precise region termination with deferred regions (reapply)

The current coverage implementation doesn't handle region termination
very precisely. Take for example an `if' statement with a `return':

void f() {
if (true) {
return; // The `if' body's region is terminated here.
}
// This line gets the same coverage as the `if' condition.
}

If the function `f' is called, the line containing the comment will be
marked as having executed once, which is not correct.

The solution here is to create a deferred region after terminating a
region. The deferred region is completed once the start location of the
next statement is known, and is then pushed onto the region stack.
In the cases where it's not possible to complete a deferred region, it
can safely be dropped.

Testing: lit test updates, a stage2 coverage-enabled build of clang

This is a reapplication but there are no changes from the original commit.
With D36813, the segment builder in llvm will be able to handle deferred
regions correctly.

llvm-svn: 312818

show more ...

[coverage] Special-case calls to noreturn functions.

The code after a noreturn call doesn't execute.

The pattern in the testcase is pretty common in LLVM (a switch with
a default case that calls ll

[coverage] Special-case calls to noreturn functions.

The code after a noreturn call doesn't execute.

The pattern in the testcase is pretty common in LLVM (a switch with
a default case that calls llvm_unreachable).

The original version of this patch was reverted in r309995 due to a
crash. This version includes a fix for that crash (testcase in
test/CoverageMapping/md.cpp).

Differential Revision: https://reviews.llvm.org/D36250

llvm-svn: 310406

show more ...

Revert "[Coverage] Precise region termination with deferred regions"

This reverts commit r310010. I don't think there's anything wrong with
this commit, but it's causing clang to generate output tha

Revert "[Coverage] Precise region termination with deferred regions"

This reverts commit r310010. I don't think there's anything wrong with
this commit, but it's causing clang to generate output that llvm-cov
doesn't do a good job with and the fix isn't immediately clear.

See Eli's comment in D36250 for more context.

I'm reverting the clang change so the coverage bot can revert back to
producing sensible output, and to give myself some time to investigate
what went wrong in llvm.

llvm-svn: 310154

show more ...

Revert "[coverage] Special-case calls to noreturn functions."

This reverts commit r309995. It looks like it's responsible for breaking
the stage2 coverage build:

http://green.lab.llvm.org/green/job

Revert "[coverage] Special-case calls to noreturn functions."

This reverts commit r309995. It looks like it's responsible for breaking
the stage2 coverage build:

http://green.lab.llvm.org/green/job/clang-stage2-coverage-R_build/1402

The cfe-commits discussion re: r309995 has more context.

llvm-svn: 310019

show more ...

[Coverage] Precise region termination with deferred regions

The current coverage implementation doesn't handle region termination
very precisely. Take for example an `if' statement with a `return':

[Coverage] Precise region termination with deferred regions

The current coverage implementation doesn't handle region termination
very precisely. Take for example an `if' statement with a `return':

void f() {
if (true) {
return; // The `if' body's region is terminated here.
}
// This line gets the same coverage as the `if' condition.
}

If the function `f' is called, the line containing the comment will be
marked as having executed once, which is not correct.

The solution here is to create a deferred region after terminating a
region. The deferred region is completed once the start location of the
next statement is known, and is then pushed onto the region stack.
In the cases where it's not possible to complete a deferred region, it
can safely be dropped.

Testing: lit test updates, a stage2 coverage-enabled build of clang
llvm-svn: 310010

show more ...

[coverage] Special-case calls to noreturn functions.

The code after a noreturn call doesn't execute.

The pattern in the testcase is pretty common in LLVM (a switch with
a default case that calls ll

[coverage] Special-case calls to noreturn functions.

The code after a noreturn call doesn't execute.

The pattern in the testcase is pretty common in LLVM (a switch with
a default case that calls llvm_unreachable).

Differential Revision: https://reviews.llvm.org/D36250

llvm-svn: 309995

show more ...

[coverage] Make smaller regions for the first case of a switch.

We never overwrite the end location of a region, so we would end up with
an overly large region when we reused the switch's region.

I

[coverage] Make smaller regions for the first case of a switch.

We never overwrite the end location of a region, so we would end up with
an overly large region when we reused the switch's region.

It's possible this code will be substantially rewritten in the near
future to deal with fallthrough more accurately, but this seems like
an improvement on its own for now.

Differential Revision: https://reviews.llvm.org/D34801

llvm-svn: 309901

show more ...

[Coverage] Support for C++17 switch initializers

Differential Revision: https://reviews.llvm.org/D25539

llvm-svn: 284292