[Clang][ASTMatcher] Extend `hasDependentName` to match DependentNameType name (#121975)

Extend `hasDependentName` to be a polymorphic matcher that
matches the name of either `DependentNameType` or
`

[Clang][ASTMatcher] Extend `hasDependentName` to match DependentNameType name (#121975)

Extend `hasDependentName` to be a polymorphic matcher that
matches the name of either `DependentNameType` or
`DependentScopeDeclRefExpr`

show more ...

[Clang][ASTMatcher] Add a matcher for the name of a DependentScopeDeclRefExpr (#121656)

Add the `hasDependentName` matcher to match the name of
`DependentScopeDeclRefExpr`

Fixes https://github.com/

[Clang][ASTMatcher] Add a matcher for the name of a DependentScopeDeclRefExpr (#121656)

Add the `hasDependentName` matcher to match the name of
`DependentScopeDeclRefExpr`

Fixes https://github.com/llvm/llvm-project/issues/121610

show more ...

[Clang][ASTMatcher] Add `dependentTemplateSpecializationType` matcher (#121435)

Fixes https://github.com/llvm/llvm-project/issues/121307

[Clang][ASTMatcher] Add `dependentNameType` AST matcher (#121263)

Fixes: https://github.com/llvm/llvm-project/issues/121240

[Clang][ASTMatcher] Add `dependentScopeDeclRefExpr` matcher (#120996)

Fixes https://github.com/llvm/llvm-project/issues/120937

[clang-tidy][use-internal-linkage]fix false positives for ExportDecl (#117901)

Fixed: #97190

Revert "Reland: [clang][test] add testing for the AST matcher reference" (#116477)

Reverts llvm/llvm-project#112168

Reland: [clang][test] add testing for the AST matcher reference (#112168)

## Problem Statement
Previously, the examples in the AST matcher reference, which gets
generated by the Doxygen comments in

Reland: [clang][test] add testing for the AST matcher reference (#112168)

## 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 #57607
Fixes #63748

show more ...

Different info in docs in AST methods (#112190)

[Here](https://github.com/llvm/llvm-project/blob/6a98c4a1602591c942f01dceb3aa29ffd4cf1e5b/clang/include/clang/ASTMatchers/ASTMatchers.h#L4188-L4203)

Different info in docs in AST methods (#112190)

[Here](https://github.com/llvm/llvm-project/blob/6a98c4a1602591c942f01dceb3aa29ffd4cf1e5b/clang/include/clang/ASTMatchers/ASTMatchers.h#L4188-L4203)
and
[here](https://github.com/llvm/llvm-project/blob/6a98c4a1602591c942f01dceb3aa29ffd4cf1e5b/clang/include/clang/ASTMatchers/ASTMatchers.h#L3679-L3695)
we can see similar code samples and same examples:
```
cxxMemberCallExpr(on(callExpr()))
```

In the first case, it is
[written](https://github.com/llvm/llvm-project/blob/6a98c4a1602591c942f01dceb3aa29ffd4cf1e5b/clang/include/clang/ASTMatchers/ASTMatchers.h#L4201)
that the object must not be matched:
```
/// cxxMemberCallExpr(on(callExpr()))
/// does not match `(g()).m()`, because the parens are not ignored.
```
In the second case, it is
[written](https://github.com/llvm/llvm-project/blob/6a98c4a1602591c942f01dceb3aa29ffd4cf1e5b/clang/include/clang/ASTMatchers/ASTMatchers.h#L3693)
that the object must be matched:
```
/// cxxMemberCallExpr(on(callExpr()))
/// matches `(g()).m()`.
```

I think that parens are ignored

show more ...

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

Reverts llvm/llvm-project#110258

The commit caused a timeout for clang-arm64-windows-msvc:
https://lab.llvm.org/buildbo

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

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.

show more ...

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

## Problem Statement
Previously, the examples in the AST matcher reference, which gets
generated by the Doxygen comments in `ASTMa

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

## 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 #57607
Fixes #63748

show more ...

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

This reverts commit 097ada2fcb607be09da94a0d11f627a3759a10de.

[clang][test] add testing for the AST matcher reference (#94248)

## Problem Statement
Previously, the examples in the AST matcher reference, which gets
generated by the doxygen comments in `ASTMat

[clang][test] add testing for the AST matcher reference (#94248)

## 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 (compile failure, parsing issues, the
expected and actual number of failures differs).

## 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-generation script will try to compile your example code before
it continues. This makes finding issues with your example code easier
because the test-failures are much more verbose.

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 #57607
Fixes #63748

show more ...

Reapply "[Clang] Unify interface for accessing template arguments as written for class/variable template specializations (#81642)" (#91393)

Reapplies #81642, fixing the crash which occurs when runni

Reapply "[Clang] Unify interface for accessing template arguments as written for class/variable template specializations (#81642)" (#91393)

Reapplies #81642, fixing the crash which occurs when running the lldb test suite.

show more ...

Revert "[Clang] Unify interface for accessing template arguments as written for class/variable template specializations (#81642)"

This reverts commit 7115ed0fff027b65fa76fdfae215ed1382ed1473.

This

Revert "[Clang] Unify interface for accessing template arguments as written for class/variable template specializations (#81642)"

This reverts commit 7115ed0fff027b65fa76fdfae215ed1382ed1473.

This commit broke several LLDB tests.

https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/as-lldb-cmake/3480/

show more ...

[Clang] Unify interface for accessing template arguments as written for class/variable template specializations (#81642)

Our current method of storing the template arguments as written for
`(Class/

[Clang] Unify interface for accessing template arguments as written for class/variable template specializations (#81642)

Our current method of storing the template arguments as written for
`(Class/Var)Template(Partial)SpecializationDecl` suffers from a number
of flaws:
- We use `TypeSourceInfo` to store `TemplateArgumentLocs` for class
template/variable template partial/explicit specializations. For
variable template specializations, this is a rather unintuitive hack (as
we store a non-type specialization as a type). Moreover, we don't ever
*need* the type as written -- in almost all cases, we only want the
template arguments (e.g. in tooling use-cases).
- The template arguments as written are stored in a number of redundant
data members. For example, `(Class/Var)TemplatePartialSpecialization`
have their own `ArgsAsWritten` member that stores an
`ASTTemplateArgumentListInfo` (the template arguments).
`VarTemplateSpecializationDecl` has yet _another_ redundant member
"`TemplateArgsInfo`" that also stores an `ASTTemplateArgumentListInfo`.

This patch eliminates all
`(Class/Var)Template(Partial)SpecializationDecl` members which store the
template arguments as written, and turns the `ExplicitInfo` member into
a `llvm::PointerUnion<const ASTTemplateArgumentListInfo*,
ExplicitInstantiationInfo*>` (to avoid unnecessary allocations when the
declaration isn't an explicit instantiation). The template arguments as
written are now accessed via `getTemplateArgsWritten` in all cases.

The "most breaking" change is to AST Matchers, insofar that `hasTypeLoc`
will no longer match class template specializations (since they no
longer store the type as written).

show more ...

[clang][ASTMatcher] Add matchers for isExplicitObjectMemberFunction() (#84446)

Note that this patch will be necessary to fix
`forEachArgumentWithParam()` and `forEachArgumentWithParamType()`
match

[clang][ASTMatcher] Add matchers for isExplicitObjectMemberFunction() (#84446)

Note that this patch will be necessary to fix
`forEachArgumentWithParam()` and `forEachArgumentWithParamType()`
matchers for deducing "this"; which is my true motivation. There the bug
is that with explicit obj params, one should not adjust the number of
arguments in presence of `CXXMethodDecls`, and this causes a mismatch
there mapping the argument to the wrong param. But, I'll come back there
once we have this matcher.

show more ...

[clang] remove (clang::)ast_matchers:: namespace from AST matcher args for docs (#81437)

When parsing the ASTMatchers.h file, a matcher could specify an argument
that is a matcher using the not nee

[clang] remove (clang::)ast_matchers:: namespace from AST matcher args for docs (#81437)

When parsing the ASTMatchers.h file, a matcher could specify an argument
that is a matcher using the not needed namespace
`(clang::)ast_matchers::`.
Change the argument parsing in dump_ast_matchers.py to remove those
namespaces such that when parameters with these namespaces slip through,
the namespaces will be not be shown in the matchers reference, like it
is done with the `internal` namespace.
Additionally, remove the not needed namespaces from arguments in
ASTMatchers.h.

show more ...

[clang][ASTMatcher] Add matchers for CXXFoldExpr (#71245)

Adds support for the following matchers related to `CXXFoldExpr`:
`cxxFoldExpr`, `callee`,
`hasInit`, `hasPattern`, `isRightFold`, `isLe

[clang][ASTMatcher] Add matchers for CXXFoldExpr (#71245)

Adds support for the following matchers related to `CXXFoldExpr`:
`cxxFoldExpr`, `callee`,
`hasInit`, `hasPattern`, `isRightFold`, `isLeftFold`,
`isUnaryFold`, `isBinaryFold`, `hasOperator`, `hasLHS`, `hasRHS`.

show more ...

[ASTMatchers] Bring comments & docs back in sync

415d9e8ca39c0b42f351cc532ccfb48b6ac97f7f edited the generated html
directly without updating the source of truth.

[clang][ASTMatcher] Add matcher for 'MacroQualifiedType'

Add matcher for 'MacroQualifiedType'

Reviewed By: aaron.ballman

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

[ASTMatcher] Fix typos in LibASTMatchersReference.html

[clang][ASTMatcher] Add Matcher 'convertVectorExpr'

Add Matcher convertVectorExpr.

Reviewed By: aaron.ballman

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

[clang][ASTMatcher] Add Matcher 'dependentSizedExtVectorType'

Add Matcher dependentSizedExtVectorType for DependentSizedExtVectorType.

Reviewed By: aaron.ballman

Differential Revision: https://rev

[clang][ASTMatcher] Add Matcher 'dependentSizedExtVectorType'

Add Matcher dependentSizedExtVectorType for DependentSizedExtVectorType.

Reviewed By: aaron.ballman

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

show more ...

[clang] adds `conceptDecl` as an ASTMatcher

Closes #63934

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