pskrgag wrote:
> I think APINotes support attributes on param declarations
Hm, cannot find it, but anyway will check if it's possible to extend APINotes.
Thanks!
https://github.com/llvm/llvm-project/pull/111588
___
cfe-commits mailing list
cfe-commit
Xazax-hun wrote:
I think APINotes support attributes on param declarations. That being said, I
think APINotes might need an extension to explicitly add support for handle
attributes. But I think that should be a straightforward patch.
https://github.com/llvm/llvm-project/pull/111588
_
pskrgag wrote:
> Make the check recognize the syscalls and consider them annotated.
I guess, this may confuse checker more, since not all syscalls actually consume
handles. I will try and share my results =) Thanks!
https://github.com/llvm/llvm-project/pull/111588
Xazax-hun wrote:
> The problem in our code is that function that releases a handle calls a
> syscall via macro, so it's not possible to directly annotate it.
Ah, I see! Thanks for sharing! I think there are a couple potential workarounds
here if you cannot change the macros:
* Use something l
pskrgag wrote:
> Is the problem that some calls cannot be annotated or is the problem that the
> inlined bodies often have coding patterns that are to complicated for the
> analyzer to understand?
Oh, sorry I missed that comment.
The problem in our code is that function that releases a handl
Xazax-hun wrote:
> I don't have strong opinion, I just want to fix annoying false positives with
> ctu =)
Thanks for working on this, I really appreciate it! :) I would even say this is
not related to ctu, because users could run into this behavior within a single
translation unit. I just wan
pskrgag wrote:
> This is the main problem with evalCall, it does not really compose.
I get it, but it seems very unlikely... Anyway, I don't have strong opinion, I
just want to fix annoying false positives with ctu =)
https://github.com/llvm/llvm-project/pull/111588
___
Xazax-hun wrote:
> I thougth evalCall approach is more clean.
It is definitely more clean locally. My concerns is about the global behavior.
Imagine a function that deals with both Fuchsia handles and plain old C file
handles. If we start to do evalCall and no longer inline the body, we no lon
Xazax-hun wrote:
> The problem was in if (C.wasInlined) logic in old version.
Thanks for elaborating! I think the idea was to have annotations all the way
down to syscalls, so if we end up inlining the body with the syscalls we still
get reasonable behavior.
Is the problem that some calls ca
pskrgag wrote:
> I'd love to better understand what is the root cause for these weird
> diagnostics when the functions are inlined
The problem was in `if (C.wasInlined)` logic in old version. So checker was not
modeling all inlined functions. If we drop that check and just allow modeling
inli
Xazax-hun wrote:
> To fix it, PR moves part of the modeling related to acquiring and releasing
> to evalCall.
`evalCall` is a really big cannon and we should use it sparingly. The problem
is, evalCall needs to modify all aspects of the function. Moreover, there is
only one check that could do
https://github.com/pskrgag updated
https://github.com/llvm/llvm-project/pull/111588
>From a3805292ea37cf06d1cf227768034b30a42a685f Mon Sep 17 00:00:00 2001
From: Pavel Skripkin
Date: Mon, 7 Oct 2024 23:01:24 +0300
Subject: [PATCH 1/6] wip: initial versio
---
.../Checkers/FuchsiaHandleChecker.
https://github.com/pskrgag updated
https://github.com/llvm/llvm-project/pull/111588
>From a3805292ea37cf06d1cf227768034b30a42a685f Mon Sep 17 00:00:00 2001
From: Pavel Skripkin
Date: Mon, 7 Oct 2024 23:01:24 +0300
Subject: [PATCH 1/6] wip: initial versio
---
.../Checkers/FuchsiaHandleChecker.
https://github.com/pskrgag edited
https://github.com/llvm/llvm-project/pull/111588
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/pskrgag updated
https://github.com/llvm/llvm-project/pull/111588
>From a3805292ea37cf06d1cf227768034b30a42a685f Mon Sep 17 00:00:00 2001
From: Pavel Skripkin
Date: Mon, 7 Oct 2024 23:01:24 +0300
Subject: [PATCH 1/6] wip: initial versio
---
.../Checkers/FuchsiaHandleChecker.
@@ -314,6 +329,193 @@ getFuchsiaHandleSymbols(QualType QT, SVal Arg,
ProgramStateRef State) {
return {};
}
+FuchsiaHandleChecker::Note FuchsiaHandleChecker::createNote(
+SymbolRef Sym,
+std::function Message) const {
+ return [Sym, Message](BugReport &BR) -> std::s
https://github.com/pskrgag updated
https://github.com/llvm/llvm-project/pull/111588
>From a3805292ea37cf06d1cf227768034b30a42a685f Mon Sep 17 00:00:00 2001
From: Pavel Skripkin
Date: Mon, 7 Oct 2024 23:01:24 +0300
Subject: [PATCH 1/5] wip: initial versio
---
.../Checkers/FuchsiaHandleChecker.
@@ -314,6 +329,193 @@ getFuchsiaHandleSymbols(QualType QT, SVal Arg,
ProgramStateRef State) {
return {};
}
+FuchsiaHandleChecker::Note FuchsiaHandleChecker::createNote(
+SymbolRef Sym,
+std::function Message) const {
+ return [Sym, Message](BugReport &BR) -> std::s
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff 91fdfec263ff2b8e88433c4294a550cabb0f2314
d4df259bb3cf88d1540b836a6aaa7622751b0287 --e
@@ -314,6 +449,127 @@ getFuchsiaHandleSymbols(QualType QT, SVal Arg,
ProgramStateRef State) {
return {};
}
+bool FuchsiaHandleChecker::needsInvalidate(const CallEvent &Call) const {
+ const FunctionDecl *FuncDecl =
dyn_cast_or_null(Call.getDecl());
+
+ assert(FuncDecl &&
@@ -267,12 +286,128 @@ class FuchsiaHandleSymbolVisitor final : public
SymbolVisitor {
private:
SmallVector Symbols;
};
+
+class FuchsiaBugVisitor final : public BugReporterVisitor {
+ // Handle that caused a problem.
+ SymbolRef Sym;
+
+ bool IsLeak;
+
+public:
+ Fuchsi
@@ -99,6 +99,7 @@
#include "clang/StaticAnalyzer/Core/PathSensitive/ConstraintManager.h"
#include "clang/StaticAnalyzer/Core/PathSensitive/ExplodedGraph.h"
#include "clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h"
+#include "clang/StaticAnalyzer/Core/PathSensitive/Progr
https://github.com/pskrgag updated
https://github.com/llvm/llvm-project/pull/111588
>From a3805292ea37cf06d1cf227768034b30a42a685f Mon Sep 17 00:00:00 2001
From: Pavel Skripkin
Date: Mon, 7 Oct 2024 23:01:24 +0300
Subject: [PATCH 1/4] wip: initial versio
---
.../Checkers/FuchsiaHandleChecker.
NagyDonat wrote:
> I just saw it in various easy checkers like `ValistChecker`, so I thought
> it's "standard" way of reporting.
Yes, ValistChecker is another example where it's useless. By the way that's the
first checker that I wrote (not completely alone) when I was an intern many
years ag
@@ -336,141 +592,55 @@ void FuchsiaHandleChecker::checkPreCall(const CallEvent
&Call,
SmallVector Handles =
getFuchsiaHandleSymbols(PVD->getType(), Call.getArgSVal(Arg), State);
-// Handled in checkPostCall.
-if (hasFuchsiaAttr(PVD) ||
-hasFuchsiaA
pskrgag wrote:
> In general, bug reporter visitors are complex tools that are good for complex
> situations where you want to find arbitrary complicated patterns in the bug
> report path, but should be avoided in simpler cases.
Aha, Ok. I just saw it in various easy checkers like `ValistChecke
@@ -314,6 +449,127 @@ getFuchsiaHandleSymbols(QualType QT, SVal Arg,
ProgramStateRef State) {
return {};
}
+bool FuchsiaHandleChecker::needsInvalidate(const CallEvent &Call) const {
+ const FunctionDecl *FuncDecl =
dyn_cast_or_null(Call.getDecl());
+
+ assert(FuncDecl &&
@@ -99,6 +99,7 @@
#include "clang/StaticAnalyzer/Core/PathSensitive/ConstraintManager.h"
#include "clang/StaticAnalyzer/Core/PathSensitive/ExplodedGraph.h"
#include "clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h"
+#include "clang/StaticAnalyzer/Core/PathSensitive/Progr
@@ -314,6 +449,127 @@ getFuchsiaHandleSymbols(QualType QT, SVal Arg,
ProgramStateRef State) {
return {};
}
+bool FuchsiaHandleChecker::needsInvalidate(const CallEvent &Call) const {
+ const FunctionDecl *FuncDecl =
dyn_cast_or_null(Call.getDecl());
+
+ assert(FuncDecl &&
@@ -267,12 +286,128 @@ class FuchsiaHandleSymbolVisitor final : public
SymbolVisitor {
private:
SmallVector Symbols;
};
+
+class FuchsiaBugVisitor final : public BugReporterVisitor {
+ // Handle that caused a problem.
+ SymbolRef Sym;
+
+ bool IsLeak;
+
+public:
+ Fuchsi
@@ -267,12 +286,128 @@ class FuchsiaHandleSymbolVisitor final : public
SymbolVisitor {
private:
SmallVector Symbols;
};
+
+class FuchsiaBugVisitor final : public BugReporterVisitor {
+ // Handle that caused a problem.
+ SymbolRef Sym;
+
+ bool IsLeak;
+
+public:
+ Fuchsi
@@ -267,12 +286,128 @@ class FuchsiaHandleSymbolVisitor final : public
SymbolVisitor {
private:
SmallVector Symbols;
};
+
+class FuchsiaBugVisitor final : public BugReporterVisitor {
+ // Handle that caused a problem.
+ SymbolRef Sym;
+
+ bool IsLeak;
+
+public:
+ Fuchsi
@@ -336,141 +592,55 @@ void FuchsiaHandleChecker::checkPreCall(const CallEvent
&Call,
SmallVector Handles =
getFuchsiaHandleSymbols(PVD->getType(), Call.getArgSVal(Arg), State);
-// Handled in checkPostCall.
-if (hasFuchsiaAttr(PVD) ||
-hasFuchsiaA
@@ -127,26 +135,30 @@ class HandleState {
bool isEscaped() const { return K == Kind::Escaped; }
bool isUnowned() const { return K == Kind::Unowned; }
- static HandleState getMaybeAllocated(SymbolRef ErrorSym) {
-return HandleState(Kind::MaybeAllocated, ErrorSym);
+ s
@@ -314,6 +449,127 @@ getFuchsiaHandleSymbols(QualType QT, SVal Arg,
ProgramStateRef State) {
return {};
}
+bool FuchsiaHandleChecker::needsInvalidate(const CallEvent &Call) const {
+ const FunctionDecl *FuncDecl =
dyn_cast_or_null(Call.getDecl());
+
+ assert(FuncDecl &&
https://github.com/NagyDonat commented:
I read the patch and added my suggestions in inline comments, but I don't
promise that I found every little corner case.
Moreover, I'm strongly opposed to introducing a `BugReporterVisitor` instead of
directly creating the notes, because in this case you
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/111588
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
pskrgag wrote:
CI again looks unrelated
```
| Failed Tests (1):
| LLVM :: Transforms/InstCombine/and-or-icmps.ll
```
https://github.com/llvm/llvm-project/pull/111588
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/c
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Pavel Skripkin (pskrgag)
Changes
This PR modernizes FuchsiaHandleChecker to fix real-world problem. Previous
checker logic was modeling handles via `checkPreCall` and `checkPostCall`,
which doesn't work well for CTU, since function body g
https://github.com/pskrgag created
https://github.com/llvm/llvm-project/pull/111588
This PR modernizes FuchsiaHandleChecker to fix real-world problem. Previous
checker logic was modeling handles via `checkPreCall` and `checkPostCall`,
which doesn't work well for CTU, since function body gets i
40 matches
Mail list logo
