Revert "Revert "Revert "[analyzer] NFC: Move path diagnostic consumer implementations to libAnalysis."""

This reverts commit d2ddc694ff94743d9735aaf07edcaf6db8aaca04.

This still contains a circular

Revert "Revert "Revert "[analyzer] NFC: Move path diagnostic consumer implementations to libAnalysis."""

This reverts commit d2ddc694ff94743d9735aaf07edcaf6db8aaca04.

This still contains a circular dependency between Analysis and CrossTU:

$ grep -r include.*Analysis clang/include/clang/CrossTU
clang/include/clang/CrossTU/CrossTranslationUnit.h:
#include "clang/Analysis/CrossTUAnalysisHelper.h"
$ grep -r include.*CrossTU clang/lib/Analysis
clang/lib/Analysis/PlistHTMLPathDiagnosticConsumer.cpp:
#include "clang/CrossTU/CrossTranslationUnit.h"
clang/lib/Analysis/PlistPathDiagnosticConsumer.cpp:
#include "clang/Analysis/CrossTUAnalysisHelper.h"

show more ...

Revert "Revert "[analyzer] NFC: Move path diagnostic consumer implementations to libAnalysis.""

This reverts commit 5663bf201f5c444d6fb56fb1bd471bc53c17d837.

The cyclic dependency problem is addres

Revert "Revert "[analyzer] NFC: Move path diagnostic consumer implementations to libAnalysis.""

This reverts commit 5663bf201f5c444d6fb56fb1bd471bc53c17d837.

The cyclic dependency problem is addressed now.
This is the ~fifth attempt to land this change.

show more ...

Revert "[analyzer] NFC: Move path diagnostic consumer implementations to libAnalysis."

The patch introduced a cycle dependency:

clangAnalysis -> clangFrontend -> clangSema -> clangAnalysis

This re

Revert "[analyzer] NFC: Move path diagnostic consumer implementations to libAnalysis."

The patch introduced a cycle dependency:

clangAnalysis -> clangFrontend -> clangSema -> clangAnalysis

This reverts commit 00ffea77ad887b576e9db82d98c97a31fee172cb.
This reverts commit ea6641085d025ca0a5cef940465ef14d0ccace02.

show more ...

Revert "Revert "Revert "Revert "[analyzer] NFC: Move path diagnostic consumer implementations to libAnalysis.""""

This reverts commit 6a89cb8136f3435bd977b419b683dc0acc98e61e.

Revert "Revert "Revert "[analyzer] NFC: Move path diagnostic consumer implementations to libAnalysis."""

This reverts commit 41bcc05e2a4e3062eb12ac6e071bc835decc38f5.

Revert "Revert "[analyzer] NFC: Move path diagnostic consumer implementations to libAnalysis.""

This reverts commit 77bb3ebebbca13f0648beb433fbd1b06ba95a19c.

Revert "Revert "[analyzer] NFC: Separate PathDiagnosticConsumer options from AnalyzerOptions.""

This reverts commit 10f1ca99b498347186ec74b01046ad292bde9a4c.

(cherry picked from commit c599fc738a70

Revert "Revert "[analyzer] NFC: Separate PathDiagnosticConsumer options from AnalyzerOptions.""

This reverts commit 10f1ca99b498347186ec74b01046ad292bde9a4c.

(cherry picked from commit c599fc738a70e482976c6cc0ea31bef561641279)

show more ...

clang/StaticAnalyzer: Stop using SourceManager::getBuffer

Update clang/lib/StaticAnalyzer to stop relying on a `MemoryBuffer*`,
using the `MemoryBufferRef` from `getBufferOrNone` or the
`Optional<Me

clang/StaticAnalyzer: Stop using SourceManager::getBuffer

Update clang/lib/StaticAnalyzer to stop relying on a `MemoryBuffer*`,
using the `MemoryBufferRef` from `getBufferOrNone` or the
`Optional<MemoryBufferRef>` from `getBufferOrFake`, depending on whether
there's logic for checking validity of the buffer. The change to
clang/lib/StaticAnalyzer/Core/IssueHash.cpp is potentially a
functionality change, since the logic was wrong (it checked for
`nullptr`, which was never returned by the old API), but if that was
reachable the new behaviour should be better.

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

show more ...

Revert "[analyzer] NFC: Separate PathDiagnosticConsumer options from AnalyzerOptions."

This reverts commit fd4b3f123d6e64769881e4c6351d5bbbdac30ce3.

Revert "[analyzer] NFC: Move path diagnostic consumer implementations to libAnalysis."

This reverts commit 44b7cf2983b6a8373c99a9b254f8c3f944e03f35.

[analyzer] NFC: Move path diagnostic consumer implementations to libAnalysis.

With this change, we're more or less ready to allow users outside
of the Static Analyzer to take advantage of path diagn

[analyzer] NFC: Move path diagnostic consumer implementations to libAnalysis.

With this change, we're more or less ready to allow users outside
of the Static Analyzer to take advantage of path diagnostic consumers
for emitting their warnings in different formats.

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

show more ...

[analyzer] NFC: Separate PathDiagnosticConsumer options from AnalyzerOptions.

The AnalyzerOptions object contains too much information that's
entirely specific to the Analyzer. It is also being refe

[analyzer] NFC: Separate PathDiagnosticConsumer options from AnalyzerOptions.

The AnalyzerOptions object contains too much information that's
entirely specific to the Analyzer. It is also being referenced by
path diagnostic consumers to tweak their behavior. In order for path
diagnostic consumers to function separately from the analyzer,
make a smaller options object that only contains relevant options.

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

show more ...

Fix some typos (unkown -> unknown); NFC

Revert "[analyzer] Change the default output type to PD_TEXT_MINIMAL in the frontend, error if an output loc is missing for PathDiagConsumers that need it"

This reverts commit fe1a3a7e8c8be33968b9a7

Revert "[analyzer] Change the default output type to PD_TEXT_MINIMAL in the frontend, error if an output loc is missing for PathDiagConsumers that need it"

This reverts commit fe1a3a7e8c8be33968b9a768666489823dabab10.

show more ...

[analyzer] Change the default output type to PD_TEXT_MINIMAL in the frontend, error if an output loc is missing for PathDiagConsumers that need it

The title and the included test file sums everythin

[analyzer] Change the default output type to PD_TEXT_MINIMAL in the frontend, error if an output loc is missing for PathDiagConsumers that need it

The title and the included test file sums everything up -- the only thing I'm
mildly afraid of is whether anyone actually depends on the weird behavior of
HTMLDiagnostics pretending to be TextDiagnostics if an output directory is not
supplied. If it is, I guess we would need to resort to tiptoeing around the
compatibility flag.

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

show more ...

[analyzer] Add the Preprocessor to CheckerManager

Reland "[analyzer][NFC] Tie CheckerRegistry to CheckerManager, allow CheckerManager to be constructed for non-analysis purposes"

Originally commited in rG57b8a407493c34c3680e7e1e4cb82e097f43744a, bu

Reland "[analyzer][NFC] Tie CheckerRegistry to CheckerManager, allow CheckerManager to be constructed for non-analysis purposes"

Originally commited in rG57b8a407493c34c3680e7e1e4cb82e097f43744a, but
it broke the modules bot. This is solved by putting the contructors of
the CheckerManager class to the Frontend library.

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

show more ...

[analyzer] Delete unneeded headers and using after D76509 for layering check

Otherwise it is incorrect to remove clangStaticAnalyzerFrontend's
dependency on clangRewrite and clangToolingCore.

[analyzer][NFC] Move the text output type to its own file, move code to PathDiagnosticConsumer creator functions

TableGen and .def files (which are meant to be used with the preprocessor) come
with

[analyzer][NFC] Move the text output type to its own file, move code to PathDiagnosticConsumer creator functions

TableGen and .def files (which are meant to be used with the preprocessor) come
with obvious downsides. One of those issues is that generated switch-case
branches have to be identical. This pushes corner cases either to an outer code
block, or into the generated code.

Inspect the removed code in AnalysisConsumer::DigestAnalyzerOptions. You can see
how corner cases like a not existing output file, the analysis output type being
set to PD_NONE, or whether to complement the output with additional diagnostics
on stderr lay around the preprocessor generated code. This is a bit problematic,
as to how to deal with such errors is not in the hands of the users of this
interface (those implementing output types, like PlistDiagnostics etc).

This patch changes this by moving these corner cases into the generated code,
more specifically, into the called functions. In addition, I introduced a new
output type for convenience purposes, PD_TEXT_MINIMAL, which always existed
conceptually, but never in the actual Analyses.def file. This refactoring
allowed me to move TextDiagnostics (renamed from ClangDiagPathDiagConsumer) to
its own file, which it really deserved.

Also, those that had the misfortune to gaze upon Analyses.def will probably
enjoy the sight that a clang-format did on it.

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

show more ...

Revert "[analyzer][NFC] Tie CheckerRegistry to CheckerManager, allow CheckerManager to be constructed for non-analysis purposes"

Temporarily reverting this patch because it breaks the modules build.

[analyzer][NFC] Tie CheckerRegistry to CheckerManager, allow CheckerManager to be constructed for non-analysis purposes

Its been a while since my CheckerRegistry related patches landed, allow me to

[analyzer][NFC] Tie CheckerRegistry to CheckerManager, allow CheckerManager to be constructed for non-analysis purposes

Its been a while since my CheckerRegistry related patches landed, allow me to
refresh your memory:

During compilation, TblGen turns
clang/include/clang/StaticAnalyzer/Checkers/Checkers.td into
(build directory)/tools/clang/include/clang/StaticAnalyzer/Checkers/Checkers.inc.
This is a file that contains the full name of the checkers, their options, etc.

The class that is responsible for parsing this file is CheckerRegistry. The job
of this class is to establish what checkers are available for the analyzer (even
from plugins and statically linked but non-tblgen generated files!), and
calculate which ones should be turned on according to the analyzer's invocation.

CheckerManager is the class that is responsible for the construction and storage
of checkers. This process works by first creating a CheckerRegistry object, and
passing itself to CheckerRegistry::initializeManager(CheckerManager&), which
will call the checker registry functions (for example registerMallocChecker) on
it.

The big problem here is that these two classes lie in two different libraries,
so their interaction is pretty awkward. This used to be far worse, but I
refactored much of it, which made things better but nowhere near perfect.

---

This patch changes how the above mentioned two classes interact. CheckerRegistry
is mainly used by CheckerManager, and they are so intertwined, it makes a lot of
sense to turn in into a field, instead of a one-time local variable. This has
additional benefits: much of the information that CheckerRegistry conveniently
holds is no longer thrown away right after the analyzer's initialization, and
opens the possibility to pass CheckerManager in the shouldRegister* function
rather then LangOptions (D75271).

There are a few problems with this. CheckerManager isn't the only user, when we
honor help flags like -analyzer-checker-help, we only have access to a
CompilerInstance class, that is before the point of parsing the AST.
CheckerManager makes little sense without ASTContext, so I made some changes and
added new constructors to make it constructible for the use of help flags.

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

show more ...

[analyzer] Skip analysis of inherited ctor as top-level function

Summary:
This fixes a regression introduced in https://reviews.llvm.org/D74735

Reviewers: NoQ, Szelethus

Tags: #clang

Differential

[analyzer] Skip analysis of inherited ctor as top-level function

Summary:
This fixes a regression introduced in https://reviews.llvm.org/D74735

Reviewers: NoQ, Szelethus

Tags: #clang

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

show more ...

[analyzer] AnalyzerOptions: Remove 'fixits-as-remarks'

Summary: The new way of checking fix-its is `%check_analyzer_fixit`.

Reviewed By: NoQ, Szelethus, xazax.hun

Differential Revision: https://re

[analyzer] AnalyzerOptions: Remove 'fixits-as-remarks'

Summary: The new way of checking fix-its is `%check_analyzer_fixit`.

Reviewed By: NoQ, Szelethus, xazax.hun

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

show more ...

[analyzer] FixItHint: Apply and test hints with the Clang-Tidy's script

Summary:
This patch introduces a way to apply the fix-its by the Analyzer:
`-analyzer-config apply-fixits=true`.

The fix-its

[analyzer] FixItHint: Apply and test hints with the Clang-Tidy's script

Summary:
This patch introduces a way to apply the fix-its by the Analyzer:
`-analyzer-config apply-fixits=true`.

The fix-its should be testable, therefore I have copied the well-tested
`check_clang_tidy.py` script. The idea is that the Analyzer's workflow
is different so it would be very difficult to use only one script for
both Tidy and the Analyzer, the script would diverge a lot.
Example test: `// RUN: %check-analyzer-fixit %s %t -analyzer-checker=core`

When the copy-paste happened the original authors were:
@alexfh, @zinovy.nis, @JonasToth, @hokein, @gribozavr, @lebedev.ri

Reviewed By: NoQ, alexfh, zinovy.nis

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

show more ...

[analyzer] CheckerContext: Make the Preprocessor available

Summary:
This patch hooks the `Preprocessor` trough `BugReporter` to the
`CheckerContext` so the checkers could look for macro definitions.

[analyzer] CheckerContext: Make the Preprocessor available

Summary:
This patch hooks the `Preprocessor` trough `BugReporter` to the
`CheckerContext` so the checkers could look for macro definitions.

Reviewed By: NoQ

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

show more ...