[clang] Don't call raw_string_ostream::flush() (NFC)

Don't call raw_string_ostream::flush(), which is essentially a no-op.
As specified in the docs, raw_string_ostream is always unbuffered

[clang] NFCI: Use `FileEntryRef` in `SourceManager::overrideFileContents()`

Sarif: stabilize artifacts order

StringMap iteration order is not guaranteed to be deterministic
(https://llvm.org/docs/ProgrammersManual.html#llvm-adt-stringmap-h).

Recommit "[Support] change StringMap hash function from djbHash to xxHash"

This reverts commit 37eb9d13f891f7656f811516e765b929b169afe0.

Test failures have been fixed:

- ubsan failure fixed by 72e

Recommit "[Support] change StringMap hash function from djbHash to xxHash"

This reverts commit 37eb9d13f891f7656f811516e765b929b169afe0.

Test failures have been fixed:

- ubsan failure fixed by 72eac42f21c0f45a27f3eaaff9364cbb5189b9e4
- warn-unsafe-buffer-usage-fixits-local-var-span.cpp fixed by
03cc52dfd1dbb4a59b479da55e87838fb93d2067 (wasn't related)
- test-output-format.ll failure was spurious, build failed at
https://lab.llvm.org/buildbot/#/builders/54/builds/3545 (b4431b2d945b6fc19b1a55ac6ce969a8e06e1e93)
but passed at
https://lab.llvm.org/buildbot/#/builders/54/builds/3546 (5ae99be0377248c74346096dc475af254a3fc799)
which is before my revert
https://github.com/llvm/llvm-project/compare/b4431b2d945b6fc19b1a55ac6ce969a8e06e1e93...5ae99be0377248c74346096dc475af254a3fc799

Original commit message:

Depends on https://reviews.llvm.org/D142861.

Alternative to https://reviews.llvm.org/D137601.

xxHash is much faster than djbHash. This makes a simple Rust test case with a large constant string 10% faster to compile.

Previous attempts at changing this hash function (e.g. https://reviews.llvm.org/D97396) had to be reverted due to breaking tests that depended on iteration order.
No additional tests fail with this patch compared to `main` when running `check-all` with `-DLLVM_ENABLE_PROJECTS="all"` (on a Linux host), so I hope I found everything that needs to be changed.

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

show more ...

Revert "[Support] change StringMap hash function from djbHash to xxHash"

This reverts commit d768b97424f9e1a0aae45440a18b99f21c4027ce.

Causes sanitizer failure: https://lab.llvm.org/buildbot/#/buil

Revert "[Support] change StringMap hash function from djbHash to xxHash"

This reverts commit d768b97424f9e1a0aae45440a18b99f21c4027ce.

Causes sanitizer failure: https://lab.llvm.org/buildbot/#/builders/238/builds/1114

```
/b/sanitizer-aarch64-linux-bootstrap-ubsan/build/llvm-project/llvm/lib/Support/xxhash.cpp:107:12: runtime error: applying non-zero offset 8 to null pointer
#0 0xaaaab28ec6c8 in llvm::xxHash64(llvm::StringRef) /b/sanitizer-aarch64-linux-bootstrap-ubsan/build/llvm-project/llvm/lib/Support/xxhash.cpp:107:12
#1 0xaaaab28cbd38 in llvm::StringMapImpl::LookupBucketFor(llvm::StringRef) /b/sanitizer-aarch64-linux-bootstrap-ubsan/build/llvm-project/llvm/lib/Support/StringMap.cpp:87:28
```

Probably causes test failure in `warn-unsafe-buffer-usage-fixits-local-var-span.cpp`: https://lab.llvm.org/buildbot/#/builders/60/builds/10619

Probably causes reverse-iteration test failure in `test-output-format.ll`: https://lab.llvm.org/buildbot/#/builders/54/builds/3545

show more ...

[Support] change StringMap hash function from djbHash to xxHash

Depends on https://reviews.llvm.org/D142861.

Alternative to https://reviews.llvm.org/D137601.

xxHash is much faster than djbHash. Th

[Support] change StringMap hash function from djbHash to xxHash

Depends on https://reviews.llvm.org/D142861.

Alternative to https://reviews.llvm.org/D137601.

xxHash is much faster than djbHash. This makes a simple Rust test case with a large constant string 10% faster to compile.

Previous attempts at changing this hash function (e.g. https://reviews.llvm.org/D97396) had to be reverted due to breaking tests that depended on iteration order.
No additional tests fail with this patch compared to `main` when running `check-all` with `-DLLVM_ENABLE_PROJECTS="all"` (on a Linux host), so I hope I found everything that needs to be changed.

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

show more ...

clang/unittests/Basic/SarifTest.cpp: std::optional::value => operator*

Refactor StaticAnalyzer to use `clang::SarifDocumentWriter`

Refactor StaticAnalyzer to use clang::SarifDocumentWriter for
serializing sarif diagnostics.

Uses clang::SarifDocumentWriter to generate

Refactor StaticAnalyzer to use `clang::SarifDocumentWriter`

Refactor StaticAnalyzer to use clang::SarifDocumentWriter for
serializing sarif diagnostics.

Uses clang::SarifDocumentWriter to generate SARIF output in the
StaticAnalyzer.

Various bugfixes are also made to clang::SarifDocumentWriter.

Summary of changes:

clang/lib/Basic/Sarif.cpp:
* Fix bug in adjustColumnPos introduced from prev move, it now uses
FullSourceLoc::getDecomposedExpansionLoc which provides the correct
location (in the presence of macros) instead of
FullSourceLoc::getDecomposedLoc.
* Fix createTextRegion so that it handles caret ranges correctly,
this should bring it to parity with the previous implementation.

clang/test/Analysis/diagnostics/Inputs/expected-sarif:
* Update the schema URL to the offical website
* Add the emitted defaultConfiguration sections to all rules
* Annotate results with the "level" property

clang/lib/StaticAnalyzer/Core/SarifDiagnostics.cpp:
* Update SarifDiagnostics class to hold a clang::SarifDocumentWriter
that it uses to convert diagnostics to SARIF.

show more ...

Add support for specifying the severity of a SARIF Result

* Extend SarifResult with level property, and allow rule configuration
* Create SarifReportingConfiguration which allow configuring rules wi

Add support for specifying the severity of a SARIF Result

* Extend SarifResult with level property, and allow rule configuration
* Create SarifReportingConfiguration which allow configuring rules with
a default priority, severity and an enable-toggle
* Support for setting the level property[1] of a result.

If unset, it defaults to "warning", which is the result of an empty
default configuration on rules[2]

[1]: https://docs.oasis-open.org/sarif/sarif/v2.1.0/os/sarif-v2.1.0-os.html#_Toc34317648
[2]: https://docs.oasis-open.org/sarif/sarif/v2.1.0/os/sarif-v2.1.0-os.html#_Toc34317855

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

show more ...

Use value instead of getValue (NFC)

Use has_value instead of hasValue (NFC)

Don't include private gtest/gmock headers

Only gmock.h and gtest.h are supposed to be user-visible.

[clang] Emit SARIF Diagnostics: Create `clang::SarifDocumentWriter` interface

[clang] Emit SARIF Diagnostics: Create clang::SarifDocumentWriter interface

Create an interface for writing SARIF docum

[clang] Emit SARIF Diagnostics: Create `clang::SarifDocumentWriter` interface

[clang] Emit SARIF Diagnostics: Create clang::SarifDocumentWriter interface

Create an interface for writing SARIF documents from within clang:

The primary intent of this change is to introduce the interface
clang::SarifDocumentWriter, which allows incrementally adding
diagnostic data to a JSON backed document. The proposed interface is
not yet connected to the compiler internals, which will be covered in
future work. As such this change will not change the input/output
interface of clang.

This change also introduces the clang::FullSourceRange type that is
modeled after clang::SourceRange + clang::FullSourceLoc, this is useful
for packaging a pair of clang::SourceLocation objects with their
corresponding SourceManagers.

Previous discussions:

RFC for this change: https://lists.llvm.org/pipermail/cfe-dev/2021-March/067907.html
https://lists.llvm.org/pipermail/cfe-dev/2021-July/068480.html
SARIF Standard (2.1.0):

https://docs.oasis-open.org/sarif/sarif/v2.1.0/os/sarif-v2.1.0-os.html

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

show more ...

Emit SARIF Diagnostics: Create `clang::SarifDocumentWriter` interface

Create an interface for writing SARIF documents from within clang:

The primary intent of this change is to introduce the interf

Emit SARIF Diagnostics: Create `clang::SarifDocumentWriter` interface

Create an interface for writing SARIF documents from within clang:

The primary intent of this change is to introduce the interface
clang::SarifDocumentWriter, which allows incrementally adding
diagnostic data to a JSON backed document. The proposed interface is
not yet connected to the compiler internals, which will be covered in
future work. As such this change will not change the input/output
interface of clang.

This change also introduces the clang::FullSourceRange type that is
modeled after clang::SourceRange + clang::FullSourceLoc, this is useful
for packaging a pair of clang::SourceLocation objects with their
corresponding SourceManagers.

Previous discussions:

RFC for this change: https://lists.llvm.org/pipermail/cfe-dev/2021-March/067907.html
https://lists.llvm.org/pipermail/cfe-dev/2021-July/068480.html
SARIF Standard (2.1.0):

https://docs.oasis-open.org/sarif/sarif/v2.1.0/os/sarif-v2.1.0-os.html

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

show more ...

[clang] Emit SARIF Diagnostics: Create `clang::SarifDocumentWriter` interface

Create an interface for writing SARIF documents from within clang:

The primary intent of this change is to introduce th

[clang] Emit SARIF Diagnostics: Create `clang::SarifDocumentWriter` interface

Create an interface for writing SARIF documents from within clang:

The primary intent of this change is to introduce the interface
clang::SarifDocumentWriter, which allows incrementally adding
diagnostic data to a JSON backed document. The proposed interface is
not yet connected to the compiler internals, which will be covered in
future work. As such this change will not change the input/output
interface of clang.

This change also introduces the clang::FullSourceRange type that is
modeled after clang::SourceRange + clang::FullSourceLoc, this is useful
for packaging a pair of clang::SourceLocation objects with their
corresponding SourceManagers.

Previous discussions:

RFC for this change: https://lists.llvm.org/pipermail/cfe-dev/2021-March/067907.html
https://lists.llvm.org/pipermail/cfe-dev/2021-July/068480.html
SARIF Standard (2.1.0):

https://docs.oasis-open.org/sarif/sarif/v2.1.0/os/sarif-v2.1.0-os.html

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

show more ...

[clang] Emit SARIF Diagnostics: Create `clang::SarifDocumentWriter` interface

Create an interface for writing SARIF documents from within clang:

The primary intent of this change is to introduce th

[clang] Emit SARIF Diagnostics: Create `clang::SarifDocumentWriter` interface

Create an interface for writing SARIF documents from within clang:

The primary intent of this change is to introduce the interface
clang::SarifDocumentWriter, which allows incrementally adding
diagnostic data to a JSON backed document. The proposed interface is
not yet connected to the compiler internals, which will be covered in
future work. As such this change will not change the input/output
interface of clang.

This change also introduces the clang::FullSourceRange type that is
modeled after clang::SourceRange + clang::FullSourceLoc, this is useful
for packaging a pair of clang::SourceLocation objects with their
corresponding SourceManagers.

Previous discussions:

RFC for this change: https://lists.llvm.org/pipermail/cfe-dev/2021-March/067907.html
https://lists.llvm.org/pipermail/cfe-dev/2021-July/068480.html
SARIF Standard (2.1.0):

https://docs.oasis-open.org/sarif/sarif/v2.1.0/os/sarif-v2.1.0-os.html

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

show more ...