This is an archive of the discontinued LLVM Phabricator instance.

[clang][dataflow] Allow analyzing multiple functions in unit tests
ClosedPublic

Authored by gribozavr on Jan 2 2023, 4:33 PM.

Details

Summary

In unit tests for concrete dataflow analyses we typically use the
testonly checkDataflow() helper to analyse a free function called
"target". This pattern allows our tests to be uniform and focused on
specific statement- or expression-level C++ features.

As we expand our feature coverage, we want to analyze functions whose
names we don't fully control, like constructors, destructors, operators
etc. In such tests it is often convenient to analyze all functions
defined in the input code, to avoid having to carefully craft an AST
matcher that finds the exact function we're interested in. That can be
easily done by providing checkDataflow() with a catch-all matcher like
functionDecl().

It is also often convenient to define multiple special member functions
in a single unit test, for example, multiple constructors, and share the
rest of the class definition code between constructors. As a result, it
makes sense to analyze multiple functions in one unit test.

This change allows checkDataflow() to correctly handle AST matchers
that match more than one function. Previously, it would only ever
analyze the first matched function, and silently ignore the rest. Now it
runs dataflow analysis in a loop, and calls VerifyResults for each
function that was found in the input and analyzed.

Diff Detail

Event Timeline

gribozavr created this revision.Jan 2 2023, 4:33 PM
Herald added a project: Restricted Project. · View Herald TranscriptJan 2 2023, 4:33 PM
gribozavr requested review of this revision.Jan 2 2023, 4:33 PM
Herald added a project: Restricted Project. · View Herald TranscriptJan 2 2023, 4:33 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript
sgatev accepted this revision.Jan 3 2023, 12:55 AM
sgatev added inline comments.
clang/unittests/Analysis/FlowSensitive/TestingSupport.cpp
92–107
clang/unittests/Analysis/FlowSensitive/TestingSupport.h
184–185

"bodies of all functions that match"

277–278

"bodies of all functions that match"

304–305

"bodies of all functions that match"

378

Can you please add a comment to describe why this needs to be cleared?

This revision is now accepted and ready to land.Jan 3 2023, 12:55 AM
ymandel accepted this revision.Jan 3 2023, 3:58 AM
ymandel added inline comments.
clang/unittests/Analysis/FlowSensitive/TestingSupport.cpp
62

This seems subtly wrong if BoundingRange is a TokenRange. It might be ok, if a comment can't be part of a token (at least, as a prefix), but still seems conceptually wrong in that it's not quite doing what it appears. So, if token ranges are ok, I'd recommend at least explaining that in the comments.

clang/unittests/Analysis/FlowSensitive/TestingSupport.h
178–179

please specify (in the comments) the intended interpretation of SourceRange -- CharRange or TokenRange -- or use CharSourceRange.

gribozavr updated this revision to Diff 491003.Jan 20 2023, 4:18 PM

Address review comments

gribozavr2 added inline comments.
clang/unittests/Analysis/FlowSensitive/TestingSupport.cpp
62

I think it does not matter what kind of range the input range is. The difference is whether the end location is pointing at the beginning or at the end of a token. This span can't contain comments.

Nevertheless, that seemed like subtle reasoning, so I documented the input as a token range, and added a conversion to character range to remove the need for such a subtle justification.

92–107

Applied.

clang/unittests/Analysis/FlowSensitive/TestingSupport.h
178–179

Documented as a token range, since that's what callers will most likely have.

184–185

Done.

277–278

Done.

378

Added.

This revision was landed with ongoing or failed builds.Jan 20 2023, 4:28 PM
This revision was automatically updated to reflect the committed changes.