https://github.com/balazske closed
https://github.com/llvm/llvm-project/pull/79312
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
=?utf-8?q?Bal=C3=A1zs_K=C3=A9ri?=
Message-ID:
In-Reply-To:
https://github.com/NagyDonat approved this pull request.
LGTM, this is a nice little cleanup patch.
https://github.com/llvm/llvm-project/pull/79312
___
cfe-commits mailing list
cfe-commits@l
https://github.com/balazske updated
https://github.com/llvm/llvm-project/pull/79312
From 62dc7fdb2f86c81af501f7f1255a98d97ede303f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bal=C3=A1zs=20K=C3=A9ri?=
Date: Wed, 24 Jan 2024 16:28:57 +0100
Subject: [PATCH 1/2] [clang][analyzer] Simplify code of Stre
benshi001 wrote:
For the part in the end of most `evalXX` functions,
```
StateFailed = ...
StateNotFailed = ...
```
They are quite similar but not identical, so we can generalize them with helper
functions.
https://github.com/llvm/llvm-project/pull/79312
__
benshi001 wrote:
I do not like too long lambda either. In my opinion lambda should be
short/compact.
And I do not think the redundancy is serious, except the common part
```
ProgramStateRef State = C.getState();
SymbolRef StreamSym = getStreamArg(Desc, Call).getAsSymbol();
if (!StreamSym
balazske wrote:
For clarification, the `evalRWCommon` new function is not planned to be used in
the same way as other `eval*` calls, the name may be misleading. This function
contains a "generic algorithm" that is called from the other `eval*` calls, but
not used directly in `CallDescriptionMa
NagyDonat wrote:
Yes, the "common big set of arguments" is an annoying problem. Perhaps you
could consider my solution in core.BitwiseShift where I introduced a
"validator" class that holds all the common arguments as data members, so
instead of helper functions you have helper methods that ca
balazske wrote:
My concern was the addition of many small functions that are used only from few
other `eval*` calls and are relatively special. And all of these need a common
big set of arguments like `StreamSym`, `CE`, `Call`. The build of states for
success and failure cases in the thing tha
steakhal wrote:
> I'm seconding the suggestions of @steakhal, and in particular I agree with
>
> > I'd also advise against using more callables bundled with CallDescriptions.
> > They make debugging code more difficult, as the control-flow would become
> > also data-dependent. I'd suggest othe
NagyDonat wrote:
I'm seconding the suggestions of @steakhal, and in particular I agree with
> I'd also advise against using more callables bundled with CallDescriptions.
> They make debugging code more difficult, as the control-flow would become
> also data-dependent. I'd suggest other ways to
benshi001 wrote:
This change is a bit complex and I need more time to understand.
https://github.com/llvm/llvm-project/pull/79312
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
steakhal wrote:
I'm yet to review the PR, but I would express my opinion on the ergonomics of
the StreamChecker, as I've spent the last couple of days around it.
I find code duplication less harmful than unnatural generalization over small
set of functions (I know, it's a hot take :D).
`std::b
balazske wrote:
Later more functions can be simplified with `evalRWCommon`, probably in a next
patch to make the review more simple.
https://github.com/llvm/llvm-project/pull/79312
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.
llvmbot wrote:
@llvm/pr-subscribers-clang-static-analyzer-1
Author: Balázs Kéri (balazske)
Changes
Common parts of some "eval" functions are moved into one function. The
non-common parts of the "eval" functions are passed through lambda parameters
to the new function.
---
Full diff: htt
https://github.com/balazske created
https://github.com/llvm/llvm-project/pull/79312
Common parts of some "eval" functions are moved into one function. The
non-common parts of the "eval" functions are passed through lambda parameters
to the new function.
From 62dc7fdb2f86c81af501f7f1255a98d97e
15 matches
Mail list logo
