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.
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.
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)".
Reland with update on test case ContinuousSyncmode/basic.c. This reverts commit fe5c2c3ca682b140dd5e640e75948363b6b25ef9.
This reverts commit 2d7374a0c680f96bdcdb3d05034a93bf145d140f. Breaks ContinuousSyncMode/basic.c in check-profile on macOS.
Differential Revision: https://reviews.llvm.org/D97101
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
Differential Revision: https://reviews.llvm.org/D84988
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
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.