Revision tags: llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4 |
|
#
dde802b1 |
| 15-Nov-2024 |
Sirraide <aeternalmail@gmail.com> |
[Clang] [NFC] Refactor AST visitors in Sema and the static analyser to use DynamicRecursiveASTVisitor (#115144)
This pr refactors all recursive AST visitors in `Sema`, `Analyze`, and
`StaticAnalysi
[Clang] [NFC] Refactor AST visitors in Sema and the static analyser to use DynamicRecursiveASTVisitor (#115144)
This pr refactors all recursive AST visitors in `Sema`, `Analyze`, and
`StaticAnalysis` to inherit from DRAV instead. This is over half of the
visitors that inherit from RAV directly.
See also #115132, #110040, #93462
LLVM Compile-Time Tracker link for this branch:
https://llvm-compile-time-tracker.com/compare.php?from=5adb5c05a2e9f31385fbba8b0436cbc07d91a44d&to=b58e589a86c06ba28d4d90613864d10be29aa5ba&stat=instructions%3Au
show more ...
|
Revision tags: llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3 |
|
#
017675ff |
| 13-Feb-2024 |
Artem Dergachev <adergachev@apple.com> |
[attributes][analyzer] Generalize [[clang::suppress]] to declarations. (#80371)
The attribute is now allowed on an assortment of declarations, to
suppress warnings related to declarations themselve
[attributes][analyzer] Generalize [[clang::suppress]] to declarations. (#80371)
The attribute is now allowed on an assortment of declarations, to
suppress warnings related to declarations themselves, or all warnings in
the lexical scope of the declaration.
I don't necessarily see a reason to have a list at all, but it does look
as if some of those more niche items aren't properly supported by the
compiler itself so let's maintain a short safe list for now.
The initial implementation raised a question whether the attribute
should apply to lexical declaration context vs. "actual" declaration
context. I'm using "lexical" here because it results in less warnings
suppressed, which is the conservative behavior: we can always expand it
later if we think this is wrong, without breaking any existing code. I
also think that this is the correct behavior that we will probably never
want to change, given that the user typically desires to keep the
suppressions as localized as possible.
show more ...
|
Revision tags: llvmorg-18.1.0-rc2 |
|
#
56e241a0 |
| 31-Jan-2024 |
Artem Dergachev <adergachev@apple.com> |
[analyzer] Unbreak [[clang::suppress]] on checkers without decl-with-issue. (#79398)
There are currently a few checkers that don't fill in the bug report's
"decl-with-issue" field (typically a func
[analyzer] Unbreak [[clang::suppress]] on checkers without decl-with-issue. (#79398)
There are currently a few checkers that don't fill in the bug report's
"decl-with-issue" field (typically a function in which the bug is
found).
The new attribute `[[clang::suppress]]` uses decl-with-issue to reduce
the size of the suppression source range map so that it didn't need to
do that for the entire translation unit.
I'm already seeing a few problems with this approach so I'll probably
redesign it in some point as it looks like a premature optimization. Not
only checkers shouldn't be required to pass decl-with-issue (consider
clang-tidy checkers that never had such notion), but also it's not
necessarily uniquely determined (consider leak suppressions at
allocation site).
For now I'm adding a simple stop-gap solution that falls back to
building the suppression map for the entire TU whenever decl-with-issue
isn't specified. Which won't happen in the default setup because luckily
all default checkers do provide decl-with-issue.
---------
Co-authored-by: Balazs Benics <benicsbalazs@gmail.com>
show more ...
|
Revision tags: llvmorg-18.1.0-rc1, llvmorg-19-init |
|
#
ef3f4760 |
| 28-Nov-2023 |
Artem Dergachev <adergachev@apple.com> |
[attributes][analyzer] Implement [[clang::suppress]] - suppress static analysis warnings.
The new attribute can be placed on statements in order to suppress arbitrary warnings produced by static ana
[attributes][analyzer] Implement [[clang::suppress]] - suppress static analysis warnings.
The new attribute can be placed on statements in order to suppress arbitrary warnings produced by static analysis tools at those statements.
Previously such suppressions were implemented as either informal comments (eg. clang-tidy `// NOLINT:`) or with preprocessor macros (eg. clang static analyzer's `#ifdef __clang_analyzer__`). The attribute provides a universal, formal, flexible and neat-looking suppression mechanism.
Implement support for the new attribute in the clang static analyzer; clang-tidy coming soon.
The attribute allows specifying which specific warnings to suppress, in the form of free-form strings that are intended to be specific to the tools, but currently none are actually supported; so this is also going to be a future improvement.
Differential Revision: https://reviews.llvm.org/D93110
show more ...
|