[clang][test] add testing for the AST matcher reference #110258

5chmidti · 2024-09-27T12:55:41Z

Problem Statement

Previously, the examples in the AST matcher reference, which gets generated by the Doxygen comments in ASTMatchers.h, were untested and best effort.
Some of the matchers had no or wrong examples of how to use the matcher.

Solution

This patch introduces a simple DSL around Doxygen commands to enable testing the AST matcher documentation in a way that should be relatively easy to use.
In ASTMatchers.h, most matchers are documented with a Doxygen comment. Most of these also have a code example that aims to show what the matcher will match, given a matcher somewhere in the documentation text. The way that the documentation is tested, is by using Doxygen's alias feature to declare custom aliases. These aliases forward to <tt>text</tt> (which is what Doxygen's \c does, but for multiple words). Using the Doxygen aliases is the obvious choice, because there are (now) four consumers:

people reading the header/using signature help
the Doxygen generated documentation
the generated HTML AST matcher reference
(new) the generated matcher tests

This patch rewrites/extends the documentation such that all matchers have a documented example.
The new generate_ast_matcher_doc_tests.py script will warn on any undocumented matchers (but not on matchers without a Doxygen comment) and provides diagnostics and statistics about the matchers.

The current statistics emitted by the parser are:

Statistics:
        doxygen_blocks                :   519
        missing_tests                 :    10
        skipped_objc                  :    42
        code_snippets                 :   503
        matches                       :   820
        matchers                      :   580
        tested_matchers               :   574
        none_type_matchers            :     6

The tests are generated during building, and the script will only print something if it found an issue with the specified tests (e.g., missing tests).

Description

DSL for generating the tests from documentation.

TLDR:

  \header{a.h}
  \endheader     <- zero or more header

  \code
    int a = 42;
  \endcode
  \compile_args{-std=c++,c23-or-later} <- optional, the std flag supports std ranges and
                                          whole languages

  \matcher{expr()} <- one or more matchers in succession
  \match{42}   <- one or more matches in succession

  \matcher{varDecl()} <- new matcher resets the context, the above
                         \match will not count for this new
                         matcher(-group)
  \match{int a  = 42} <- only applies to the previous matcher (not to the
                         previous case)

The above block can be repeated inside a Doxygen command for multiple code examples for a single matcher.
The test generation script will only look for these annotations and ignore anything else like \c or the sentences where these annotations are embedded into: The matcher \matcher{expr()} matches the number \match{42}..

Language Grammar

[] denotes an optional, and <> denotes user-input

  compile_args j:= \compile_args{[<compile_arg>;]<compile_arg>}
  matcher_tag_key ::= type
  match_tag_key ::= type || std || count || sub
  matcher_tags ::= [matcher_tag_key=<value>;]matcher_tag_key=<value>
  match_tags ::= [match_tag_key=<value>;]match_tag_key=<value>
  matcher ::= \matcher{[matcher_tags$]<matcher>}
  matchers ::= [matcher] matcher
  match ::= \match{[match_tags$]<match>}
  matches ::= [match] match
  case ::= matchers matches
  cases ::= [case] case
  header-block ::= \header{<name>} <code> \endheader
  code-block ::= \code <code> \endcode
  testcase ::= code-block [compile_args] cases

Language Standard Versions

The 'std' tag and '\compile_args' support specifying a specific language version, a whole language and all of its versions, and thresholds (implies ranges). Multiple arguments are passed with a ',' separator. For a language and version to execute a tested matcher, it has to match the specified '\compile_args' for the code, and the 'std' tag for the matcher. Predicates for the 'std' compiler flag are used with disjunction between languages (e.g. 'c || c++') and conjunction for all predicates specific to each language (e.g. 'c++11-or-later && c++23-or-earlier').

Examples:

c all available versions of C
c++11 only C++11
c++11-or-later C++11 or later
c++11-or-earlier C++11 or earlier
c++11-or-later,c++23-or-earlier,c all of C and C++ between 11 and
23 (inclusive)
c++11-23,c same as above

What if ...?

... I want to add a matcher?

Add a Doxygen comment to the matcher with a code example, corresponding matchers and matches, that shows what the matcher is supposed to do. Specify the compile arguments/supported languages if required, and run ninja check-clang-unit to test the documentation.

... the example I wrote is wrong?

The test-failure output of the generated test file will provide information about

where the generated test file is located
which line in ASTMatcher.h the example is from
which matches were: found, not-(yet)-found, expected
in case of an unexpected match: what the node looks like using the different types
the language version and if the test ran with a windows -target flag (also in failure summary)

... I don't adhere to the required order of the syntax?

The script will diagnose any found issues, such as matcher is missing an example with a file:line: prefix,
which should provide enough information about the issue.

... the script diagnoses a false-positive issue with a Doxygen comment?

It hopefully shouldn't, but if you, e.g., added some non-matcher code and documented it with Doxygen, then the script will consider that as a matcher documentation. As a result, the script will print that it detected a mismatch between the actual and the expected number of failures. If the diagnostic truly is a false-positive, change the expected_failure_statistics at the top of the generate_ast_matcher_doc_tests.py file.

Fixes #57607
Fixes #63748

Previously, the examples in the AST matcher reference, which gets generated by the doxygen comments in `ASTMatchers.h`, were untested and best effort. Some of the matchers had no or wrong examples of how to use the matcher. This patch introduces a simple DSL around doxygen commands to enable testing the AST matcher documentation in a way that should be relatively easy. In `ASTMatchers.h`, most matchers are documented with a doxygen comment. Most of these also have a code example that aims to show what the matcher will match, given a matcher somewhere in the documentation text. The way that testing the documentation is done, is by using doxygens alias feature to declare custom aliases. These aliases forward to `<tt>text</tt>` (which is what doxygens \c does, but for multiple words). Using the doxygen aliases was the obvious choice, because there are (now) four consumers: - people reading the header/using signature help - the doxygen generated documentation - the generated html AST matcher reference - (new) the generated matcher tests This patch rewrites/extends the documentation such that all matchers have a documented example. The new `generate_ast_matcher_doc_tests.py` script will warn on any undocumented matchers (but not on matchers without a doxygen comment) and provides diagnostics and statistics about the matchers. Below is a file-level comment from the test generation script that describes how documenting matchers to be tested works on a slightly more technical level. In general, the new comments can be used as a reference for how to implement a tested documentation. The current statistics emitted by the parser are: ```text Statistics: doxygen_blocks : 519 missing_tests : 10 skipped_objc : 42 code_snippets : 503 matches : 820 matchers : 580 tested_matchers : 574 none_type_matchers : 6 ``` The tests are generated during building and the script will only print something if it found an issue (compile failure, parsing issues, the expected and actual number of failures differs). DSL for generating the tests from documentation. TLDR: The order for a single code snippet example is: \header{a.h} \endheader <- zero or more header \code int a = 42; \endcode \compile_args{-std=c++,c23-or-later} <- optional, supports std ranges and whole languages \matcher{expr()} <- one or more matchers in succession \match{42} <- one ore more matches in succession \matcher{varDecl()} <- new matcher resets the context, the above \match will not count for this new matcher(-group) \match{int a = 42} <- only applies to the previous matcher (no the previous case) The above block can be repeated inside of a doxygen command for multiple code examples. Language Grammar: [] denotes an optional, and <> denotes user-input compile_args j:= \compile_args{[<compile_arg>;]<compile_arg>} matcher_tag_key ::= type match_tag_key ::= type || std || count matcher_tags ::= [matcher_tag_key=<value>;]matcher_tag_key=<value> match_tags ::= [match_tag_key=<value>;]match_tag_key=<value> matcher ::= \matcher{[matcher_tags$]<matcher>} matchers ::= [matcher] matcher match ::= \match{[match_tags$]<match>} matches ::= [match] match case ::= matchers matches cases ::= [case] case header-block ::= \header{<name>} <code> \endheader code-block ::= \code <code> \endcode testcase ::= code-block [compile_args] cases The 'std' tag and '\compile_args' support specifying a specific language version, a whole language and all of it's versions, and thresholds (implies ranges). Multiple arguments are passed with a ',' seperator. For a language and version to execute a tested matcher, it has to match the specified '\compile_args' for the code, and the 'std' tag for the matcher. Predicates for the 'std' compiler flag are used with disjunction between languages (e.g. 'c || c++') and conjunction for all predicates specific to each language (e.g. 'c++11-or-later && c++23-or-earlier'). Examples: - c all available versions of C - c++11 only C++11 - c++11-or-later C++11 or later - c++11-or-earlier C++11 or earlier - c++11-or-later,c++23-or-earlier,c all of C and C++ between 11 and 23 (inclusive) - c++11-23,c same as above Tags: Type: Match types are used to select where the string that is used to check if a node matches comes from. Available: code, name, typestr, typeofstr. The default is 'code'. Matcher types are used to mark matchers as submatchers with 'sub' or as deactivated using 'none'. Testing submatchers is not implemented. Count: Specifying a 'count=n' on a match will result in a test that requires that the specified match will be matched n times. Default is 1. Std: A match allows specifying if it matches only in specific language versions. This may be needed when the AST differs between language versions. Fixes #57607 Fixes #63748

…expressive

Fix for the buildbot failure due to lower python versions not supporting some types to be subscripted. Tested with python3.8.

5chmidti · 2024-09-27T13:00:16Z

This is an attempt to reland this PR, which created buildbot failures because of the python version not supporting subscripted types, and because previously, the test generation script would try to compile the code with a clang from PATH.

Removed the type-hints that didn't work, and testing that the examples work has been removed from the test generation script. That part will also be tested when running the unit test, and was only added to catch compile failures of the examples earlier.

5chmidti · 2024-09-27T13:00:43Z

Original PR: #94248

5chmidti · 2024-09-27T16:47:29Z

The buildkite failure is unrelated

## Problem Statement Previously, the examples in the AST matcher reference, which gets generated by the Doxygen comments in `ASTMatchers.h`, were untested and best effort. Some of the matchers had no or wrong examples of how to use the matcher. ## Solution This patch introduces a simple DSL around Doxygen commands to enable testing the AST matcher documentation in a way that should be relatively easy to use. In `ASTMatchers.h`, most matchers are documented with a Doxygen comment. Most of these also have a code example that aims to show what the matcher will match, given a matcher somewhere in the documentation text. The way that the documentation is tested, is by using Doxygen's alias feature to declare custom aliases. These aliases forward to `<tt>text</tt>` (which is what Doxygen's `\c` does, but for multiple words). Using the Doxygen aliases is the obvious choice, because there are (now) four consumers: - people reading the header/using signature help - the Doxygen generated documentation - the generated HTML AST matcher reference - (new) the generated matcher tests This patch rewrites/extends the documentation such that all matchers have a documented example. The new `generate_ast_matcher_doc_tests.py` script will warn on any undocumented matchers (but not on matchers without a Doxygen comment) and provides diagnostics and statistics about the matchers. The current statistics emitted by the parser are: ```text Statistics: doxygen_blocks : 519 missing_tests : 10 skipped_objc : 42 code_snippets : 503 matches : 820 matchers : 580 tested_matchers : 574 none_type_matchers : 6 ``` The tests are generated during building, and the script will only print something if it found an issue with the specified tests (e.g., missing tests). ## Description DSL for generating the tests from documentation. TLDR: ``` \header{a.h} \endheader <- zero or more header \code int a = 42; \endcode \compile_args{-std=c++,c23-or-later} <- optional, the std flag supports std ranges and whole languages \matcher{expr()} <- one or more matchers in succession \match{42} <- one or more matches in succession \matcher{varDecl()} <- new matcher resets the context, the above \match will not count for this new matcher(-group) \match{int a = 42} <- only applies to the previous matcher (not to the previous case) ``` The above block can be repeated inside a Doxygen command for multiple code examples for a single matcher. The test generation script will only look for these annotations and ignore anything else like `\c` or the sentences where these annotations are embedded into: `The matcher \matcher{expr()} matches the number \match{42}.`. ### Language Grammar [] denotes an optional, and <> denotes user-input ``` compile_args j:= \compile_args{[<compile_arg>;]<compile_arg>} matcher_tag_key ::= type match_tag_key ::= type || std || count || sub matcher_tags ::= [matcher_tag_key=<value>;]matcher_tag_key=<value> match_tags ::= [match_tag_key=<value>;]match_tag_key=<value> matcher ::= \matcher{[matcher_tags$]<matcher>} matchers ::= [matcher] matcher match ::= \match{[match_tags$]<match>} matches ::= [match] match case ::= matchers matches cases ::= [case] case header-block ::= \header{<name>} <code> \endheader code-block ::= \code <code> \endcode testcase ::= code-block [compile_args] cases ``` ### Language Standard Versions The 'std' tag and '\compile_args' support specifying a specific language version, a whole language and all of its versions, and thresholds (implies ranges). Multiple arguments are passed with a ',' separator. For a language and version to execute a tested matcher, it has to match the specified '\compile_args' for the code, and the 'std' tag for the matcher. Predicates for the 'std' compiler flag are used with disjunction between languages (e.g. 'c || c++') and conjunction for all predicates specific to each language (e.g. 'c++11-or-later && c++23-or-earlier'). Examples: - `c` all available versions of C - `c++11` only C++11 - `c++11-or-later` C++11 or later - `c++11-or-earlier` C++11 or earlier - `c++11-or-later,c++23-or-earlier,c` all of C and C++ between 11 and 23 (inclusive) - `c++11-23,c` same as above ### Tags #### `type`: **Match types** are used to select where the string that is used to check if a node matches comes from. Available: `code`, `name`, `typestr`, `typeofstr`. The default is `code`. - `code`: Forwards to `tooling::fixit::getText(...)` and should be the preferred way to show what matches. - `name`: Casts the match to a `NamedDecl` and returns the result of `getNameAsString`. Useful when the matched AST node is not easy to spell out (`code` type), e.g., namespaces or classes with many members. - `typestr`: Returns the result of `QualType::getAsString` for the type derived from `Type` (otherwise, if it is derived from `Decl`, recurses with `Node->getTypeForDecl()`) **Matcher types** are used to mark matchers as sub-matcher with 'sub' or as deactivated using 'none'. Testing sub-matcher is not implemented. #### `count`: Specifying a 'count=n' on a match will result in a test that requires that the specified match will be matched n times. Default is 1. #### `std`: A match allows specifying if it matches only in specific language versions. This may be needed when the AST differs between language versions. #### `sub`: The `sub` tag on a `\match` will indicate that the match is for a node of a bound sub-matcher. E.g., `\matcher{expr(expr().bind("inner"))}` has a sub-matcher that binds to `inner`, which is the value for the `sub` tag of the expected match for the sub-matcher `\match{sub=inner$...}`. Currently, sub-matchers are not tested in any way. ### What if ...? #### ... I want to add a matcher? Add a Doxygen comment to the matcher with a code example, corresponding matchers and matches, that shows what the matcher is supposed to do. Specify the compile arguments/supported languages if required, and run `ninja check-clang-unit` to test the documentation. #### ... the example I wrote is wrong? The test-failure output of the generated test file will provide information about - where the generated test file is located - which line in `ASTMatcher.h` the example is from - which matches were: found, not-(yet)-found, expected - in case of an unexpected match: what the node looks like using the different `type`s - the language version and if the test ran with a windows `-target` flag (also in failure summary) #### ... I don't adhere to the required order of the syntax? The script will diagnose any found issues, such as `matcher is missing an example` with a `file:line:` prefix, which should provide enough information about the issue. #### ... the script diagnoses a false-positive issue with a Doxygen comment? It hopefully shouldn't, but if you, e.g., added some non-matcher code and documented it with Doxygen, then the script will consider that as a matcher documentation. As a result, the script will print that it detected a mismatch between the actual and the expected number of failures. If the diagnostic truly is a false-positive, change the `expected_failure_statistics` at the top of the `generate_ast_matcher_doc_tests.py` file. Fixes llvm#57607 Fixes llvm#63748

llvm-ci · 2024-09-28T01:17:32Z

LLVM Buildbot has detected a new failure on builder clang-arm64-windows-msvc running on linaro-armv8-windows-msvc-04 while building clang at step 5 "ninja check 1".

Full details are available at: https://lab.llvm.org/buildbot/#/builders/161/builds/2385

Here is the relevant piece of the build log for the reference

Step 5 (ninja check 1) failure: 1200 seconds without output running [b'ninja', b'check-all'], attempting to kill
...
[1429/1448] Linking CXX executable unittests\Transforms\Vectorize\VectorizeTests.exe
[1430/1448] Linking CXX executable unittests\XRay\XRayTests.exe
[1431/1448] Linking CXX executable unittests\Transforms\Utils\UtilsTests.exe
[1432/1448] Linking CXX executable unittests\Transforms\Scalar\ScalarTests.exe
[1433/1448] Linking CXX executable unittests\tools\llvm-profgen\LLVMProfgenTests.exe
[1434/1448] Linking CXX executable unittests\tools\llvm-mca\LLVMMCATests.exe
[1435/1448] Linking CXX executable unittests\tools\llvm-profdata\LLVMProfdataTests.exe
[1436/1448] Linking CXX executable unittests\tools\llvm-exegesis\LLVMExegesisTests.exe
[1437/1448] Building CXX object tools\clang\unittests\Tooling\CMakeFiles\ToolingTests.dir\SourceCodeTest.cpp.obj
[1438/1448] Linking CXX executable tools\clang\unittests\Tooling\ToolingTests.exe
command timed out: 1200 seconds without output running [b'ninja', b'check-all'], attempting to kill
program finished with exit code 1
elapsedTime=1579.318403

)" This reverts commit e42cc3f.

…0354) Reverts #110258 The commit caused a timeout for clang-arm64-windows-msvc: https://lab.llvm.org/buildbot/#/builders/161/builds/2385 and it looks like my commit is at fault.

…0354) Reverts llvm/llvm-project#110258 The commit caused a timeout for clang-arm64-windows-msvc: https://lab.llvm.org/buildbot/#/builders/161/builds/2385 and it looks like my commit is at fault.

llvm-ci · 2024-10-14T04:55:05Z

LLVM Buildbot has detected a new failure on builder clang-m68k-linux-cross running on suse-gary-m68k-cross while building clang at step 5 "ninja check 1".

Full details are available at: https://lab.llvm.org/buildbot/#/builders/27/builds/554

Here is the relevant piece of the build log for the reference

Step 5 (ninja check 1) failure: stage 1 checked (failure)
...
                 from /var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/include/clang/Tooling/DependencyScanning/DependencyScanningTool.h:13,
                 from /var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/unittests/Tooling/DependencyScanning/DependencyScannerTest.cpp:17:
/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/include/clang/Sema/Sema.h:511:7: warning: ‘clang::Sema’ declared with greater visibility than the type of its field ‘clang::Sema::UnusedFileScopedDecls’ [-Wattributes]
  511 | class Sema final : public SemaBase {
      |       ^~~~
/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/include/clang/Sema/Sema.h:511:7: warning: ‘clang::Sema’ declared with greater visibility than the type of its field ‘clang::Sema::TentativeDefinitions’ [-Wattributes]
/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/include/clang/Sema/Sema.h:511:7: warning: ‘clang::Sema’ declared with greater visibility than the type of its field ‘clang::Sema::ExtVectorDecls’ [-Wattributes]
/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/include/clang/Sema/Sema.h:511:7: warning: ‘clang::Sema’ declared with greater visibility than the type of its field ‘clang::Sema::DelegatingCtorDecls’ [-Wattributes]
[293/1122] Building CXX object tools/clang/unittests/AST/CMakeFiles/ASTTests.dir/StructuralEquivalenceTest.cpp.o
[294/1122] Building CXX object tools/clang/unittests/ASTMatchers/CMakeFiles/ASTMatchersTests.dir/ASTMatchersDocTests.cpp.o
FAILED: tools/clang/unittests/ASTMatchers/CMakeFiles/ASTMatchersTests.dir/ASTMatchersDocTests.cpp.o 
/usr/bin/c++ -DGTEST_HAS_RTTI=0 -DLLVM_BUILD_STATIC -D_DEBUG -D_GLIBCXX_ASSERTIONS -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/stage1/tools/clang/unittests/ASTMatchers -I/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/unittests/ASTMatchers -I/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/include -I/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/stage1/tools/clang/include -I/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/stage1/include -I/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/llvm/include -I/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/third-party/unittest/googletest/include -I/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/third-party/unittest/googlemock/include -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -fno-lifetime-dse -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-nonnull -Wno-class-memaccess -Wno-redundant-move -Wno-pessimizing-move -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment -Wno-misleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -ffunction-sections -fdata-sections -fno-common -Woverloaded-virtual -fno-strict-aliasing -O3 -DNDEBUG -std=c++17  -Wno-variadic-macros -fno-exceptions -funwind-tables -fno-rtti -UNDEBUG -Wno-suggest-override -MD -MT tools/clang/unittests/ASTMatchers/CMakeFiles/ASTMatchersTests.dir/ASTMatchersDocTests.cpp.o -MF tools/clang/unittests/ASTMatchers/CMakeFiles/ASTMatchersTests.dir/ASTMatchersDocTests.cpp.o.d -o tools/clang/unittests/ASTMatchers/CMakeFiles/ASTMatchersTests.dir/ASTMatchersDocTests.cpp.o -c /var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/stage1/tools/clang/unittests/ASTMatchers/ASTMatchersDocTests.cpp
In file included from /var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/stage1/tools/clang/unittests/ASTMatchers/ASTMatchersDocTests.cpp:10:
/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/unittests/ASTMatchers/ASTMatchersTest.h: In static member function ‘static std::optional<std::__cxx11::basic_string<char> > clang::ast_matchers::VerifyBoundNodeMatch<T>::Match::getMatchText(const U*, const clang::ASTContext&, clang::ast_matchers::MatchKind, bool) [with U = clang::Decl; T = clang::Decl]’:
/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/unittests/ASTMatchers/ASTMatchersTest.h:652:5: warning: control reaches end of non-void function [-Wreturn-type]
  652 |     }
      |     ^
/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/unittests/ASTMatchers/ASTMatchersTest.h: In static member function ‘static std::optional<std::__cxx11::basic_string<char> > clang::ast_matchers::VerifyBoundNodeMatch<T>::Match::getMatchText(const U*, const clang::ASTContext&, clang::ast_matchers::MatchKind, bool) [with U = clang::OMPExecutableDirective; T = clang::OMPExecutableDirective]’:
/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/unittests/ASTMatchers/ASTMatchersTest.h:652:5: warning: control reaches end of non-void function [-Wreturn-type]
/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/unittests/ASTMatchers/ASTMatchersTest.h: In static member function ‘static std::optional<std::__cxx11::basic_string<char> > clang::ast_matchers::VerifyBoundNodeMatch<T>::Match::getMatchText(const U*, const clang::ASTContext&, clang::ast_matchers::MatchKind, bool) [with U = clang::Attr; T = clang::Attr]’:
/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/unittests/ASTMatchers/ASTMatchersTest.h:652:5: warning: control reaches end of non-void function [-Wreturn-type]
/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/unittests/ASTMatchers/ASTMatchersTest.h: In static member function ‘static std::optional<std::__cxx11::basic_string<char> > clang::ast_matchers::VerifyBoundNodeMatch<T>::Match::getMatchText(const U*, const clang::ASTContext&, clang::ast_matchers::MatchKind, bool) [with U = clang::NestedNameSpecifierLoc; T = clang::NestedNameSpecifierLoc]’:
/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/unittests/ASTMatchers/ASTMatchersTest.h:652:5: warning: control reaches end of non-void function [-Wreturn-type]
/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/unittests/ASTMatchers/ASTMatchersTest.h: In static member function ‘static std::optional<std::__cxx11::basic_string<char> > clang::ast_matchers::VerifyBoundNodeMatch<T>::Match::getMatchText(const U*, const clang::ASTContext&, clang::ast_matchers::MatchKind, bool) [with U = clang::NestedNameSpecifier; T = clang::NestedNameSpecifier]’:
/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/unittests/ASTMatchers/ASTMatchersTest.h:652:5: warning: control reaches end of non-void function [-Wreturn-type]
/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/unittests/ASTMatchers/ASTMatchersTest.h: In static member function ‘static std::optional<std::__cxx11::basic_string<char> > clang::ast_matchers::VerifyBoundNodeMatch<T>::Match::getMatchText(const U*, const clang::ASTContext&, clang::ast_matchers::MatchKind, bool) [with U = clang::NamespaceDecl; T = clang::NestedNameSpecifier]’:
/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/unittests/ASTMatchers/ASTMatchersTest.h:652:5: warning: control reaches end of non-void function [-Wreturn-type]
/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/unittests/ASTMatchers/ASTMatchersTest.h: In static member function ‘static std::optional<std::__cxx11::basic_string<char> > clang::ast_matchers::VerifyBoundNodeMatch<T>::Match::getMatchText(const U*, const clang::ASTContext&, clang::ast_matchers::MatchKind, bool) [with U = clang::NamespaceAliasDecl; T = clang::NestedNameSpecifier]’:
/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/unittests/ASTMatchers/ASTMatchersTest.h:652:5: warning: control reaches end of non-void function [-Wreturn-type]
/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/unittests/ASTMatchers/ASTMatchersTest.h: In static member function ‘static std::optional<std::__cxx11::basic_string<char> > clang::ast_matchers::VerifyBoundNodeMatch<T>::Match::getMatchText(const U*, const clang::ASTContext&, clang::ast_matchers::MatchKind, bool) [with U = clang::CXXRecordDecl; T = clang::NestedNameSpecifier]’:
/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/unittests/ASTMatchers/ASTMatchersTest.h:652:5: warning: control reaches end of non-void function [-Wreturn-type]
/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/unittests/ASTMatchers/ASTMatchersTest.h: In static member function ‘static std::optional<std::__cxx11::basic_string<char> > clang::ast_matchers::VerifyBoundNodeMatch<T>::Match::getMatchText(const U*, const clang::ASTContext&, clang::ast_matchers::MatchKind, bool) [with U = clang::Type; T = clang::NestedNameSpecifier]’:
/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/unittests/ASTMatchers/ASTMatchersTest.h:652:5: warning: control reaches end of non-void function [-Wreturn-type]
/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/unittests/ASTMatchers/ASTMatchersTest.h: In static member function ‘static std::optional<std::__cxx11::basic_string<char> > clang::ast_matchers::VerifyBoundNodeMatch<T>::Match::getMatchText(const U*, const clang::ASTContext&, clang::ast_matchers::MatchKind, bool) [with U = clang::TemplateTypeParmType; T = clang::TemplateTypeParmType]’:
/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/unittests/ASTMatchers/ASTMatchersTest.h:652:5: warning: control reaches end of non-void function [-Wreturn-type]
/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/unittests/ASTMatchers/ASTMatchersTest.h: In static member function ‘static std::optional<std::__cxx11::basic_string<char> > clang::ast_matchers::VerifyBoundNodeMatch<T>::Match::getMatchText(const U*, const clang::ASTContext&, clang::ast_matchers::MatchKind, bool) [with U = clang::SubstTemplateTypeParmType; T = clang::SubstTemplateTypeParmType]’:
/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/unittests/ASTMatchers/ASTMatchersTest.h:652:5: warning: control reaches end of non-void function [-Wreturn-type]
/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/unittests/ASTMatchers/ASTMatchersTest.h: In static member function ‘static std::optional<std::__cxx11::basic_string<char> > clang::ast_matchers::VerifyBoundNodeMatch<T>::Match::getMatchText(const U*, const clang::ASTContext&, clang::ast_matchers::MatchKind, bool) [with U = clang::UsingType; T = clang::UsingType]’:
/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/unittests/ASTMatchers/ASTMatchersTest.h:652:5: warning: control reaches end of non-void function [-Wreturn-type]
/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/unittests/ASTMatchers/ASTMatchersTest.h: In static member function ‘static std::optional<std::__cxx11::basic_string<char> > clang::ast_matchers::VerifyBoundNodeMatch<T>::Match::getMatchText(const U*, const clang::ASTContext&, clang::ast_matchers::MatchKind, bool) [with U = clang::ElaboratedType; T = clang::ElaboratedType]’:
/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/unittests/ASTMatchers/ASTMatchersTest.h:652:5: warning: control reaches end of non-void function [-Wreturn-type]
/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/unittests/ASTMatchers/ASTMatchersTest.h: In static member function ‘static std::optional<std::__cxx11::basic_string<char> > clang::ast_matchers::VerifyBoundNodeMatch<T>::Match::getMatchText(const U*, const clang::ASTContext&, clang::ast_matchers::MatchKind, bool) [with U = clang::TagType; T = clang::TagType]’:
/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/unittests/ASTMatchers/ASTMatchersTest.h:652:5: warning: control reaches end of non-void function [-Wreturn-type]
/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/unittests/ASTMatchers/ASTMatchersTest.h: In static member function ‘static std::optional<std::__cxx11::basic_string<char> > clang::ast_matchers::VerifyBoundNodeMatch<T>::Match::getMatchText(const U*, const clang::ASTContext&, clang::ast_matchers::MatchKind, bool) [with U = clang::RecordType; T = clang::RecordType]’:
/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/unittests/ASTMatchers/ASTMatchersTest.h:652:5: warning: control reaches end of non-void function [-Wreturn-type]
/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/unittests/ASTMatchers/ASTMatchersTest.h: In static member function ‘static std::optional<std::__cxx11::basic_string<char> > clang::ast_matchers::VerifyBoundNodeMatch<T>::Match::getMatchText(const U*, const clang::ASTContext&, clang::ast_matchers::MatchKind, bool) [with U = clang::UnaryTransformType; T = clang::UnaryTransformType]’:
/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/unittests/ASTMatchers/ASTMatchersTest.h:652:5: warning: control reaches end of non-void function [-Wreturn-type]
/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/unittests/ASTMatchers/ASTMatchersTest.h: In static member function ‘static std::optional<std::__cxx11::basic_string<char> > clang::ast_matchers::VerifyBoundNodeMatch<T>::Match::getMatchText(const U*, const clang::ASTContext&, clang::ast_matchers::MatchKind, bool) [with U = clang::DeducedTemplateSpecializationType; T = clang::DeducedTemplateSpecializationType]’:
/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/unittests/ASTMatchers/ASTMatchersTest.h:652:5: warning: control reaches end of non-void function [-Wreturn-type]

5chmidti added 15 commits September 27, 2024 13:26

fix cuda tests

fb4ad18

fix cuda tests

fe524b7

fix f-string containing backslash

8f09178

rm not needed typeofstr match kind

62e08f1

move some FIXME's to the main function

f3c83e8

replace some type=name matches with explicit code matches to be more …

c42669c

…expressive

add missing comments on some matchers on the number of matches generated

ae7e0c9

add documentation (pr desc) to ASTMatchers.h's file comment

96e6184

fix empty enum decl

9ef9cb0

fix formatting

0e0c24f

fix formatting

9ce6290

[clang][test][NFC] fix for python version requirements

673f78f

Fix for the buildbot failure due to lower python versions not supporting some types to be subscripted. Tested with python3.8.

remove testing if the examples compile in the test gen script

dc020ad

update header comment

992cd8c

5chmidti merged commit e42cc3f into main Sep 27, 2024
8 of 10 checks passed

5chmidti deleted the users/5chmidti/add_testing_for_the_AST_matcher_reference branch September 27, 2024 16:47

5chmidti added a commit that referenced this pull request Sep 28, 2024

Revert "[clang][test] add testing for the AST matcher reference (#110258

cdfcbfd

)" This reverts commit e42cc3f.

5chmidti mentioned this pull request Sep 28, 2024

Revert "[clang][test] add testing for the AST matcher reference" #110354

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[clang][test] add testing for the AST matcher reference #110258

[clang][test] add testing for the AST matcher reference #110258

Uh oh!

5chmidti commented Sep 27, 2024

Uh oh!

5chmidti commented Sep 27, 2024

Uh oh!

5chmidti commented Sep 27, 2024

Uh oh!

5chmidti commented Sep 27, 2024

Uh oh!

Uh oh!

llvm-ci commented Sep 28, 2024

Uh oh!

llvm-ci commented Oct 14, 2024

Uh oh!

Uh oh!

[clang][test] add testing for the AST matcher reference #110258

[clang][test] add testing for the AST matcher reference #110258

Uh oh!

Conversation

5chmidti commented Sep 27, 2024

Problem Statement

Solution

Description

Language Grammar

Language Standard Versions

Tags

type:

count:

std:

sub:

What if ...?

... I want to add a matcher?

... the example I wrote is wrong?

... I don't adhere to the required order of the syntax?

... the script diagnoses a false-positive issue with a Doxygen comment?

Uh oh!

5chmidti commented Sep 27, 2024

Uh oh!

5chmidti commented Sep 27, 2024

Uh oh!

5chmidti commented Sep 27, 2024

Uh oh!

Uh oh!

llvm-ci commented Sep 28, 2024

Uh oh!

llvm-ci commented Oct 14, 2024

Uh oh!

Uh oh!

`type`:

`count`:

`std`:

`sub`: