forked from llvm/llvm-project
-
Notifications
You must be signed in to change notification settings - Fork 341
🍒 Static Analyzer cherrypicks #8184
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
haoNoQ
merged 8 commits into
swiftlang:stable/20230725
from
haoNoQ:static-analyzer-cherrypicks-2024-02
Feb 14, 2024
Merged
🍒 Static Analyzer cherrypicks #8184
haoNoQ
merged 8 commits into
swiftlang:stable/20230725
from
haoNoQ:static-analyzer-cherrypicks-2024-02
Feb 14, 2024
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…issue. (llvm#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 <[email protected]> (cherry picked from commit 56e241a)
This is a follow-up for 721dd3b [analyzer] NFC: Don't regenerate duplicate HTML reports. Because HTMLRewriter re-runs the Lexer for syntax highlighting and macro expansion purposes, it may get fairly expensive when the rewriter is invoked multiple times on the same file. In the static analyzer (which uses HTMLRewriter for HTML output mode) we only get away with this because there are usually very few reports emitted per file. But if loud checkers are enabled, such as `webkit.*`, this may explode in complexity and even cause the compiler to run over the 32-bit SourceLocation addressing limit. This patch caches intermediate results so that re-lexing only needed to happen once. As the clever __COUNTER__ test demonstrates, "once" is still too many. Ideally we shouldn't re-lex anything at all, which remains a TODO. (cherry picked from commit 243bfed)
…ToFindPtrOrigin (llvm#80768) (cherry picked from commit 93a2a8c)
…dCallArgsChecker. (llvm#80810) (cherry picked from commit 85507f1)
This accessor returns a pointer from Ref type and is therefore safe. (cherry picked from commit 8256804)
… a false positive. (llvm#80934) The bug was caused by isRefCountable erroneously returning false for a class with both ref() and deref() functions defined because we were not resetting the base paths results between looking for "ref()" and "deref()" (cherry picked from commit f63da47)
…ts. (llvm#80956) This PR aligns the evaluation of default arguments with other kinds of arguments by extracting the expressions within them as argument values to be evaluated. (cherry picked from commit 2dbfa84)
llvm#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. (cherry picked from commit 017675f)
@swift-ci please test |
rniwa
approved these changes
Feb 14, 2024
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for merging these!
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Cherry-pick improvements to
[[clang::suppress]]
and webkit checkers into the stable branch.