[clang][lex] Use preferred path separator in includer-relative lookup

There is a long-standing FIXME in `HeaderSearch.cpp` to use the path separator preferred by the platform instead of forward slas

[clang][lex] Use preferred path separator in includer-relative lookup

There is a long-standing FIXME in `HeaderSearch.cpp` to use the path separator preferred by the platform instead of forward slash. There was an attempt to fix that (1cf6c28a) which got reverted (cf385dc8). I couldn't find an explanation, but my guess is that some tests assuming forward slash started failing.

This commit fixes tests with that assumption.

This is intended to be NFC, but there are two exceptions to that:
* Some diagnostic messages might now contain backslash instead of forward slash.
* Arguments to the "-remap-file" option that use forward slash might stop kicking in. Separators between potential includer path and header name need to be replaced by backslash in that case.

show more ...

[clang] Use std::optional instead of llvm::Optional (NFC)

This patch replaces (llvm::|)Optional< with std::optional<. I'll post
a separate patch to remove #include "llvm/ADT/Optional.h".

This is p

[clang] Use std::optional instead of llvm::Optional (NFC)

This patch replaces (llvm::|)Optional< with std::optional<. I'll post
a separate patch to remove #include "llvm/ADT/Optional.h".

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...

[clang] Add #include <optional> (NFC)

This patch adds #include <optional> to those files containing
llvm::Optional<...> or Optional<...>.

I'll post a separate patch to actually replace llvm::Option

[clang] Add #include <optional> (NFC)

This patch adds #include <optional> to those files containing
llvm::Optional<...> or Optional<...>.

I'll post a separate patch to actually replace llvm::Optional with
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...

[llvm] Make llvm::Any similar to std::any

This facilitates replacing llvm::Any with std::any.
- Deprecate any_isa in favor of using any_cast(Any*) and checking for
nullptr because C++17 has no any

[llvm] Make llvm::Any similar to std::any

This facilitates replacing llvm::Any with std::any.
- Deprecate any_isa in favor of using any_cast(Any*) and checking for
nullptr because C++17 has no any_isa.
- Remove the assert from any_cast(Any*), so it returns nullptr if the
type is not correct. This aligns it with std::any_cast(any*).

Use any_cast(Any*) throughout LLVM instead of checks with any_isa.

This is the first part outlined in
https://discourse.llvm.org/t/rfc-switching-from-llvm-any-to-std-any/67176

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

show more ...

[clang/unittests] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the a

[clang/unittests] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...

Use llvm::sort instead of std::sort where possible

llvm::sort is beneficial even when we use the iterator-based overload,
since it can optionally shuffle the elements (to detect
non-determinism). Ho

Use llvm::sort instead of std::sort where possible

llvm::sort is beneficial even when we use the iterator-based overload,
since it can optionally shuffle the elements (to detect
non-determinism). However llvm::sort is not usable everywhere, for
example, in compiler-rt.

Reviewed By: nhaehnle

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

show more ...

[libTooling] Fix indentation. NFC.

[libTooling] Generalize string explanation as templated metadata

Change RewriteRule from holding an `Explanation` to being able to generate
arbitrary metadata. Where TransformerClangTidyCheck was in

[libTooling] Generalize string explanation as templated metadata

Change RewriteRule from holding an `Explanation` to being able to generate
arbitrary metadata. Where TransformerClangTidyCheck was interested in a string
description for the diagnostic, other tools may be interested in richer metadata
at a higher level of abstraction than at the edit level (which is currently
available as ASTEdit::Metadata).

Reviewed By: ymandel

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

show more ...

Revert "[libTooling] Generalize string explanation as templated metadata"

This reverts commit 18440547d3520b78c9ab929685309419fc1fbe95. Causing failures
in some build modes.

e.g. https://lab.llvm.o

Revert "[libTooling] Generalize string explanation as templated metadata"

This reverts commit 18440547d3520b78c9ab929685309419fc1fbe95. Causing failures
in some build modes.

e.g. https://lab.llvm.org/buildbot/#/builders/217/builds/1886

show more ...

[libTooling] Generalize string explanation as templated metadata

Change RewriteRule from holding an `Explanation` to being able to generate
arbitrary metadata. Where TransformerClangTidyCheck was in

[libTooling] Generalize string explanation as templated metadata

Change RewriteRule from holding an `Explanation` to being able to generate
arbitrary metadata. Where TransformerClangTidyCheck was interested in a string
description for the diagnostic, other tools may be interested in richer metadata
at a higher level of abstraction than at the edit level (which is currently
available as ASTEdit::Metadata).

Reviewed By: ymandel

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

show more ...

[libTooling] Change Tranformer's consumer to take multiple changes

Previously, Transformer would invoke the consumer once per file modified per
match, in addition to any errors encountered. The cons

[libTooling] Change Tranformer's consumer to take multiple changes

Previously, Transformer would invoke the consumer once per file modified per
match, in addition to any errors encountered. The consumer is not aware of which
AtomicChanges come from any particular match. It is unclear which sets of edits
may be related or whether an error invalidates any previously emitted changes.

Modify the signature of the consumer to accept a set of changes. This keeps
related changes (i.e. all edits from a single match) together, and clarifies
that errors don't produce partial changes.

Reviewed By: ymandel

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

show more ...

[libTooling] Remove deprecated Clang Transformer declarations

A number of declarations were leftover after the move from `clang::tooling` to
`clang::transformer`. This patch removes those declaratio

[libTooling] Remove deprecated Clang Transformer declarations

A number of declarations were leftover after the move from `clang::tooling` to
`clang::transformer`. This patch removes those declarations and upgrades the
handful of references to the deprecated declarations.

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

show more ...

[libTooling] Update Transformer's `node` combinator to include the trailing semicolon for decls.

Currently, `node` only includes the semicolon for (some) statements. However,
declarations have the s

[libTooling] Update Transformer's `node` combinator to include the trailing semicolon for decls.

Currently, `node` only includes the semicolon for (some) statements. However,
declarations have the same issue of (potentially) trailing semicolons, so `node`
should behave the same for them.

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

show more ...

[Transformer] Split ForStmt test into two

It is apparently not possible to have two rewrites in one gtest function
because atomic changes in the test harness accumulate.

Comment out new test while I figure out what is wrong with it

[AST] Update matchers to be traverse-aware

Don't match Stmt or Decl nodes not spelled in the source when using
TK_IgnoreUnlessSpelledInSource. This prevents accidental modification
of source code a

[AST] Update matchers to be traverse-aware

Don't match Stmt or Decl nodes not spelled in the source when using
TK_IgnoreUnlessSpelledInSource. This prevents accidental modification
of source code at incorrect locations.

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

show more ...

[AST] Ignore implicit nodes in IgnoreUnlessSpelledInSource mode

Update the ASTNodeTraverser to dump only nodes spelled in source. There
are only a few which need to be handled, but Decl nodes for w

[AST] Ignore implicit nodes in IgnoreUnlessSpelledInSource mode

Update the ASTNodeTraverser to dump only nodes spelled in source. There
are only a few which need to be handled, but Decl nodes for which
isImplicit() is true are handled together.

Update the RAV instances used in ASTMatchFinder to ignore the nodes too.
As with handling of template instantiations, it is necessary to allow
the RAV to process the implicit nodes because they need to be visitable
before the first traverse() matcher is encountered. An exception to
this is in the MatchChildASTVisitor, because we sometimes wish to make a
node matchable but make its children not-matchable. This is the case
for defaulted CXXMethodDecls for example.

Extend TransformerTests to illustrate the kinds of problems that can
arise when performing source code rewriting due to matching implicit
nodes.

This change accounts for handling nodes not spelled in source when using
direct matching of nodes, and when using the has() and hasDescendant()
matchers. Other matchers such as
cxxRecordDecl(hasMethod(cxxMethodDecl())) still succeed for
compiler-generated methods for example after this change. Updating the
implementations of hasMethod() and other matchers is for a follow-up
patch.

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

show more ...

Undo Revert "Ignore template instantiations if not in AsIs mode"

MaskRay already fixed the ASan bug.

Revert "Ignore template instantiations if not in AsIs mode"

This reverts commit 53df3beb624989ed32d87697d0c17601d7871465 due to
check-asan failure on the buildbot.

[unittest][TrasnformerTest] Fix asan stack-use-after-return

Ignore template instantiations if not in AsIs mode

Summary:
IgnoreUnlessSpelledInSource mode should ignore these because they are
not written in the source. This matters for example when trying to

Ignore template instantiations if not in AsIs mode

Summary:
IgnoreUnlessSpelledInSource mode should ignore these because they are
not written in the source. This matters for example when trying to
replace types or values which are templated. The new test in
TransformerTest.cpp in this commit demonstrates the problem.

In existing matcher code, users can write
`unless(isInTemplateInstantiation())` or `unless(isInstantiated())` (the
user must know which to use). The point of the
TK_IgnoreUnlessSpelledInSource mode is to allow the novice to avoid such
details. This patch changes the IgnoreUnlessSpelledInSource mode to
skip over implicit template instantiations.

This patch does not change the TK_AsIs mode.

Note: An obvious attempt at an alternative implementation would simply
change the shouldVisitTemplateInstantiations() in ASTMatchFinder.cpp to
return something conditional on the operational TraversalKind. That
does not work because shouldVisitTemplateInstantiations() is called
before a possible top-level traverse() matcher changes the operational
TraversalKind.

Reviewers: sammccall, aaron.ballman, gribozavr2, ymandel, klimek

Subscribers: cfe-commits

Tags: #clang

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

show more ...

[libTooling] Add function to Transformer to create a no-op edit.

This functionality is commonly needed in clang tidy checks (based on
transformer) that only print warnings, without suggesting any ed

[libTooling] Add function to Transformer to create a no-op edit.

This functionality is commonly needed in clang tidy checks (based on
transformer) that only print warnings, without suggesting any edits. The no-op
edit allows the user to associate a diagnostic message with a source location.

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

show more ...

[libTooling] Provide overloads of `rewriteDescendants` that operate directly on an AST node.

The new overloads apply directly to a node, like the
`clang::ast_matchers::match` functions, Rather than

[libTooling] Provide overloads of `rewriteDescendants` that operate directly on an AST node.

The new overloads apply directly to a node, like the
`clang::ast_matchers::match` functions, Rather than generating an
`EditGenerator` combinator.

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

show more ...

[libTooling] Restore defaults for matchers in makeRule.

This patch restores the default traversal for Transformer's `makeRule` to
`TK_AsIs`. The implicit mode has proven problematic.

Differential R

[libTooling] Restore defaults for matchers in makeRule.

This patch restores the default traversal for Transformer's `makeRule` to
`TK_AsIs`. The implicit mode has proven problematic.

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

show more ...

[libTooling] Move RewriteRule include edits to ASTEdit granularity.

Currently, changes to includes are applied to an entire rule. However,
include changes may be specific to particular edits within

[libTooling] Move RewriteRule include edits to ASTEdit granularity.

Currently, changes to includes are applied to an entire rule. However,
include changes may be specific to particular edits within a rule (for example,
they may apply to one file but not another). Also, include changes may need to
carry metadata, just like other changes. So, we make include changes first-class
edits.

Reviewed By: tdl-g

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

show more ...