https://github.com/steakhal closed
https://github.com/llvm/llvm-project/pull/120437
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
steakhal wrote:
### Merge activity
* **Dec 19, 6:57 AM EST**: A user merged this pull request with
[Graphite](https://app.graphite.dev/github/pr/llvm/llvm-project/120437).
https://github.com/llvm/llvm-project/pull/120437
___
cfe-commits mailing list
https://github.com/steakhal updated
https://github.com/llvm/llvm-project/pull/120438
>From a5f566aff5cfef5c56b1bc7d122fd58e2ccd4357 Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Wed, 18 Dec 2024 15:59:23 +0100
Subject: [PATCH] [analyzer][NFC] Migrate {SymInt,IntSym}Expr to use APSIntPtr
(
https://github.com/steakhal closed
https://github.com/llvm/llvm-project/pull/120438
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
steakhal wrote:
### Merge activity
* **Dec 19, 7:01 AM EST**: A user merged this pull request with
[Graphite](https://app.graphite.dev/github/pr/llvm/llvm-project/120438).
https://github.com/llvm/llvm-project/pull/120438
___
cfe-commits mailing list
@@ -165,79 +166,70 @@ class BasicValueFactory {
/// Convert - Create a new persistent APSInt with the same value as 'From'
/// but with the bitwidth and signedness of 'To'.
- const llvm::APSInt &Convert(const llvm::APSInt& To,
- const llvm::A
@@ -0,0 +1,64 @@
+//== APSIntPtr.h - Wrapper for APSInt objects owned separately -*- C++ -*--==//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apach
https://github.com/steakhal closed
https://github.com/llvm/llvm-project/pull/116462
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/steakhal created
https://github.com/llvm/llvm-project/pull/120572
This PR splits the existing modeling of builtin assume from the
BuiltinFunctionChecker.
We just sink the execution path if we are about to leave the assume expression
with a false assumption.
Assumptions with
steakhal wrote:
I made the followup for this one in #120572
https://github.com/llvm/llvm-project/pull/116462
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/steakhal edited
https://github.com/llvm/llvm-project/pull/120572
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/steakhal updated
https://github.com/llvm/llvm-project/pull/120572
>From 097d7feb474e7eca884730dc8eebbb8b1bdef2e1 Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Thu, 19 Dec 2024 13:45:58 +0100
Subject: [PATCH 1/2] [analyzer] Model [[assume]] attributes without
side-ffects
steakhal wrote:
How did you notice this? If its from a real case then we could add a regression
test for this too.
https://github.com/llvm/llvm-project/pull/120597
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/
https://github.com/steakhal closed
https://github.com/llvm/llvm-project/pull/116034
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
steakhal wrote:
I took the time to update the branch with my recommendations.
Please confirm if you agree with the current status.
tldr; I only made sure the tests actually test what they intended now that the
default threshold has changed.
I also added a couple more tests where it made sense,
https://github.com/steakhal approved this pull request.
https://github.com/llvm/llvm-project/pull/118291
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/steakhal updated
https://github.com/llvm/llvm-project/pull/118291
>From 1fb92742a066444d4a074655704c8148ce1f8326 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Krist=C3=B3f=20Umann?=
Date: Mon, 2 Dec 2024 11:21:05 +0100
Subject: [PATCH 1/5] [analyzer][Z3] Restore the original timeo
steakhal wrote:
> I agree that it would make more sense to generalize this beyond loop
> widening. However, I'm having a hard time understanding how your proposal
> would fit in to the augmentation of the assignment message like I do in this
> PR.
>
> The part I'm most confused about is how w
steakhal wrote:
My current stance is that we should have the memoryspace trait only for
memregions that have an UnknownSpace memspace, becuase that would be the least
amount of work. So it would be a hybrid solution.
We have the memspaces as we have today, but for UnknownSpace you would need to
=?utf-8?q?Balázs_Kéri?=
Message-ID:
In-Reply-To:
@@ -351,12 +356,30 @@ void DereferenceChecker::checkBind(SVal L, SVal V, const
Stmt *S,
C.addTransition(State, this);
}
-void ento::registerDereferenceChecker(CheckerManager &mgr) {
- auto *Chk = mgr.registerChecker();
-
=?utf-8?q?Balázs_Kéri?=
Message-ID:
In-Reply-To:
@@ -351,12 +356,30 @@ void DereferenceChecker::checkBind(SVal L, SVal V, const
Stmt *S,
C.addTransition(State, this);
}
-void ento::registerDereferenceChecker(CheckerManager &mgr) {
- auto *Chk = mgr.registerChecker();
-
=?utf-8?q?Bal=C3=A1zs_K=C3=A9ri?=
Message-ID:
In-Reply-To:
https://github.com/steakhal approved this pull request.
LGTM.
https://github.com/llvm/llvm-project/pull/122139
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/
=?utf-8?q?Bal=C3=A1zs_K=C3=A9ri?=
Message-ID:
In-Reply-To:
@@ -155,22 +155,27 @@ static bool isDeclRefExprToReference(const Expr *E) {
void DereferenceChecker::reportBug(DerefKind K, ProgramStateRef State,
const Stmt *S, CheckerContext &C)
=?utf-8?q?Balázs_Kéri?=
Message-ID:
In-Reply-To:
https://github.com/steakhal edited
https://github.com/llvm/llvm-project/pull/122139
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
steakhal wrote:
I agree that it's important to augment the bug reports with information about
the source of the symbols. Especially for conjured and derived symbols that are
produced widely because of invalidations.
Loop widening is just one source of invalidation, and we could generalize it
s
@@ -0,0 +1,48 @@
+// RUN: %clang_analyze_cc1 -triple=x86_64-pc-linux-gnu
-analyzer-checker=core,unix.Stream,debug.ExprInspection \
+// RUN: -analyzer-config eagerly-assume=false,unix.Stream:Pedantic=true
-verify %s
+// RUN: %clang_analyze_cc1 -triple=armv8-none-linux-eabi
-an
@@ -0,0 +1,48 @@
+// RUN: %clang_analyze_cc1 -triple=x86_64-pc-linux-gnu
-analyzer-checker=core,unix.Stream,debug.ExprInspection \
+// RUN: -analyzer-config eagerly-assume=false,unix.Stream:Pedantic=true
-verify %s
+// RUN: %clang_analyze_cc1 -triple=armv8-none-linux-eabi
-an
@@ -952,6 +952,12 @@ SVal SimpleSValBuilder::evalBinOpLL(ProgramStateRef state,
const MemSpaceRegion *RightMS = RightBase->getMemorySpace();
const MemSpaceRegion *UnknownMS = MemMgr.getUnknownRegion();
+if (LeftMS != RightMS &&
+((isa(LeftMS) && isa(RightMS
https://github.com/steakhal edited
https://github.com/llvm/llvm-project/pull/122404
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/steakhal requested changes to this pull request.
In general, the concept of having the memory space directly embedded into a
memory region is flawed. And that is the root cause of the problem.
Ideally, the property of "in what memory space does this region live in" is a
trai
@@ -0,0 +1,48 @@
+// RUN: %clang_analyze_cc1 -triple=x86_64-pc-linux-gnu
-analyzer-checker=core,unix.Stream,debug.ExprInspection \
+// RUN: -analyzer-config eagerly-assume=false,unix.Stream:Pedantic=true
-verify %s
+// RUN: %clang_analyze_cc1 -triple=armv8-none-linux-eabi
-an
steakhal wrote:
> Hi @steakhal .
>
> Thank you for the further clarification and example. I now understand how
> your proposal fits in with what I'm trying to accomplish.
Thank you for your time for considering it!
> I've started to implement the proposal but I have a few questions:
>
> * Wh
https://github.com/steakhal edited
https://github.com/llvm/llvm-project/pull/123003
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,72 @@
+//===-- MemSpaces.cpp -*- C++
-*--//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apa
https://github.com/steakhal commented:
I had a quick look at the PR, and over all it looks as expected. Good job!
Have you considered changing `MemRegion::getMemorySpace()` into
`MemRegion::getMemorySpace(ProgramStateRef)`?
This should lessen the confusion of which APIs should a dev use to get
steakhal wrote:
> Working on some benchmarking. Posted some problems in the discord channel,
> but working through it now, and benchmarking with the CodeChecker tool using
> only clangsa. Is there an already established set of benchmarks y'all use
> somewhere? IIRC, there was some github repo
@@ -437,7 +437,7 @@ bool SymbolReaper::isLiveRegion(const MemRegion *MR) {
// tell if anything still refers to this region. Unlike SymbolicRegions,
// AllocaRegions don't have associated symbols, though, so we don't actually
// have a way to track their liveness.
- retur
steakhal wrote:
> Benchmarking is taking a while for me, and I can only really run benchmarks
> with low run-time variance overnight. I will post more over time as I get
> more benchmark projects added.
>
> Here is the result from benchmarking one C project, libsodium, so far. These
> results
@@ -437,7 +437,7 @@ bool SymbolReaper::isLiveRegion(const MemRegion *MR) {
// tell if anything still refers to this region. Unlike SymbolicRegions,
// AllocaRegions don't have associated symbols, though, so we don't actually
// have a way to track their liveness.
- retur
steakhal wrote:
> > Have you considered changing `MemRegion::getMemorySpace()` into
> > `MemRegion::getMemorySpace(ProgramStateRef)`?
>
> I thought about this, but I decided against it since I am thinking that
> MemSpaces will eventually be their own separate thing, not part of the
> MemRegio
https://github.com/steakhal commented:
This change affects how an AST node is modeled. Consequently, it's a core
change.
As such a change, we should have a test.
Overall, I really liked how thoroughly you described what caused the issue, and
that helped to justify the fix. On that front, it lo
https://github.com/steakhal edited
https://github.com/llvm/llvm-project/pull/124477
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -124,24 +124,26 @@ void ExprEngine::VisitObjCForCollectionStmt(const
ObjCForCollectionStmt *S,
bool isContainerNull = state->isNull(collectionV).isConstrainedTrue();
- ExplodedNodeSet dstLocation;
- evalLocation(dstLocation, S, elem, Pred, state, elementV, false);
+
@@ -119,7 +120,26 @@ class MemRegion : public llvm::FoldingSetNode {
virtual MemRegionManager &getMemRegionManager() const = 0;
- LLVM_ATTRIBUTE_RETURNS_NONNULL const MemSpaceRegion *getMemorySpace() const;
+ /// Deprecated. Gets the 'raw' memory space of a memory region'
https://github.com/steakhal edited
https://github.com/llvm/llvm-project/pull/123003
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/steakhal created
https://github.com/llvm/llvm-project/pull/124798
The commits were gathered using:
```sh
git log --reverse --oneline llvmorg-20-init..llvm/main \
clang/{lib/StaticAnalyzer,include/clang/StaticAnalyzer} | grep -v NFC | grep
-v OpenACC | grep -v -i revert
```
https://github.com/steakhal milestoned
https://github.com/llvm/llvm-project/pull/124798
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/steakhal edited
https://github.com/llvm/llvm-project/pull/124798
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
steakhal wrote:
https://github.com/llvm/llvm-project/pull/124798
___
cf
steakhal wrote:
@necto as you also contributed a signifficant amount in this release.
https://github.com/llvm/llvm-project/pull/124798
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/steakhal created
https://github.com/llvm/llvm-project/pull/125044
If we see a variable declaration (aka. DeclStmt), and the VarRegion it declared
doesn't have Stack memspace, we assumed that it must be a local static variable.
However, the declared variable may be an extern d
@@ -427,8 +434,8 @@ class BinarySymExprImpl : public BinarySymExpr {
public:
BinarySymExprImpl(LHSTYPE lhs, BinaryOperator::Opcode op, RHSTYPE rhs,
-QualType t)
- : BinarySymExpr(ClassKind, op, t), LHS(lhs), RHS(rhs) {
+QualType t
https://github.com/steakhal edited
https://github.com/llvm/llvm-project/pull/121551
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -56,6 +68,8 @@ class SymExpr : public llvm::FoldingSetNode {
Kind getKind() const { return K; }
+ SymbolID getSymbolID() const { return Sym; }
steakhal wrote:
This is expected to be a fairly infrequently used API. I think this deserves to
be highlight
@@ -687,4 +711,35 @@ class SymbolVisitor {
} // namespace clang
+// Override the default definition that would use pointer values of SymbolRefs
+// to order them, which is unstable due to ASLR.
+// Use the SymbolID instead which reflect the order in which the symbols were
+//
@@ -687,4 +711,35 @@ class SymbolVisitor {
} // namespace clang
+// Override the default definition that would use pointer values of SymbolRefs
+// to order them, which is unstable due to ASLR.
+// Use the SymbolID instead which reflect the order in which the symbols were
+//
@@ -687,4 +711,35 @@ class SymbolVisitor {
} // namespace clang
+// Override the default definition that would use pointer values of SymbolRefs
+// to order them, which is unstable due to ASLR.
+// Use the SymbolID instead which reflect the order in which the symbols were
+//
https://github.com/steakhal commented:
@Xazax-hun I'm pretty happy with this PR, but I'm curious about your opinion on
adding the `SymbolID Sym` member to the SymExprs.
https://github.com/llvm/llvm-project/pull/121551
___
cfe-commits mailing list
cfe-
https://github.com/steakhal approved this pull request.
LGTM, thanks.
https://github.com/llvm/llvm-project/pull/121551
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/steakhal closed
https://github.com/llvm/llvm-project/pull/121551
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/steakhal closed
https://github.com/llvm/llvm-project/pull/121592
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/steakhal created
https://github.com/llvm/llvm-project/pull/121592
Reverts llvm/llvm-project#121551
We had a bunch of build errors caused by this PR.
https://lab.llvm.org/buildbot/#/builders/144/builds/14875
>From 81d2afb2991e636de374eb1d1b550786618ed036 Mon Sep 17 00:00:00
steakhal wrote:
@necto Please have a look at the build failures. There are plenty.
For the time being, I reverted this PR.
https://github.com/llvm/llvm-project/pull/121551
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/c
@@ -427,8 +434,8 @@ class BinarySymExprImpl : public BinarySymExpr {
public:
BinarySymExprImpl(LHSTYPE lhs, BinaryOperator::Opcode op, RHSTYPE rhs,
-QualType t)
- : BinarySymExpr(ClassKind, op, t), LHS(lhs), RHS(rhs) {
+QualType t
@@ -401,7 +401,22 @@ class RangeSet {
friend class Factory;
};
-using ConstraintMap = llvm::ImmutableMap;
+struct ConstraintKVInfo : llvm::ImutKeyValueInfo {
+ static inline bool isEqual(key_type_ref L, key_type_ref R) {
+return L->getAllocID() == R->getAllocID();
+ }
https://github.com/steakhal commented:
The content look narrow and precise.
It raises me questions why is the only user of this new field the Constraint
manager?
And if the constraint manager is the only user, why is the SMT-based solver not
using this? Should all the other immutableSet/Map ben
https://github.com/steakhal edited
https://github.com/llvm/llvm-project/pull/121347
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/steakhal created
https://github.com/llvm/llvm-project/pull/120981
I noticed recently that this code (that I wrote xD) uses the
`getRuntimeDefinition()` which isn't quite necessary for the simple task this
function was designed for.
Why would it be better not using this API
https://github.com/steakhal created
https://github.com/llvm/llvm-project/pull/122272
In my patch there, I left a test expectation stale. Tests with `REQUIRES: Z3`
never run because no bots check such configurations.
Here I'm adjusting the test expectations to meet reality.
>From 70d29e2ed8a98
steakhal wrote:
Now that I looked at that PR, it was merged without approval, while having open
comments.
https://github.com/llvm/llvm-project/pull/122249
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/l
=?utf-8?q?Balázs_Kéri?=
Message-ID:
In-Reply-To:
https://github.com/steakhal edited
https://github.com/llvm/llvm-project/pull/122139
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
steakhal wrote:
Its usually good practice to refer to the last commit where the dead resources
become dead.
You can use the git log -S to find out about the commits the thing is mentioned.
Example: `git log -Sexample_custom_assert -- clang/www/analyzer/`, will mention:
```
61a76f58ebf161c739fb1
=?utf-8?q?Don=C3=A1t?= Nagy ,
=?utf-8?q?Don=C3=A1t?= Nagy ,
=?utf-8?q?Don=C3=A1t?= Nagy ,
=?utf-8?q?Don=C3=A1t?= Nagy ,
=?utf-8?q?Don=C3=A1t?= Nagy ,
=?utf-8?q?Don=C3=A1t?= Nagy ,
=?utf-8?q?Don=C3=A1t?= Nagy ,
=?utf-8?q?Don=C3=A1t?= Nagy
Message-ID:
In-Reply-To:
https://github.com/steakhal appr
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy
Message-ID:
In-Reply-To:
https://github.com/steakhal approved this pull request.
> If I understand correctly, I handled every review suggestion.
>
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy
Message-ID:
In-Reply-To:
https://github.com/steakhal edited
https://github.com/llvm/llvm-project/pull/119388
_
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy ,
=?utf-8?q?Donát?= Nagy
Message-ID:
In-Reply-To:
@@ -910,38 +910,51 @@ void pr6302(id x, Class y) {
//===-
=?utf-8?q?Don=C3=A1t?= Nagy ,
=?utf-8?q?Don=C3=A1t?= Nagy ,
=?utf-8?q?Don=C3=A1t?= Nagy ,
=?utf-8?q?Don=C3=A1t?= Nagy ,
=?utf-8?q?Don=C3=A1t?= Nagy ,
=?utf-8?q?Don=C3=A1t?= Nagy
Message-ID:
In-Reply-To:
steakhal wrote:
One more thing. Please mention this in the release notes.
https://github.c
steakhal wrote:
> Unfortunately the test still seems to be flaky. With EXPENSIVE_CHECKS I often
> see it fail on the RHEL8 x86_64 machines I use.
> E.g.
> ```
> FAIL: Clang :: Analysis/live-stmts.cpp (1 of 1)
> TEST 'Clang :: Analysis/live-stmts.cpp' FAILED
> **
steakhal wrote:
> For what it worth this change made it persistently failing in my setup.
I'm not sure I follow you.
The test is disabled on all platforms unconditionally on main.
Since e823f14eab4762bdf8483d02e2684f24ec4f100b
https://github.com/llvm/llvm-project/pull/126913
___
steakhal wrote:
> @steakhal : Sure I can do some tests if you come up with a fix. Right now,
> with an EXPENSIVE_CHECKS build it fails in 30-40% of the runs for me so it
> should be pretty quick to see if a fix works or not. I've never seen it fail
> without EXPENSIVE_CHECKS.
I could reproduc
steakhal wrote:
Now it says:
```
UNSUPPORTED: Clang :: Analysis/live-stmts.cpp (1 of 1)
Test does not support the following features and/or targets: true, true
steakhal wrote:
```
ValueError: Error in UNSUPPORTED list:
couldn't parse text: '*'
https://github.com/steakhal closed
https://github.com/llvm/llvm-project/pull/127034
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -194,3 +194,34 @@ char test_comparison_with_extent_symbol(struct incomplete
*p) {
return ((char *)p)[-1]; // no-warning
}
+int table[256], small_table[128];
+int test_cast_to_unsigned(signed char x) {
+ unsigned char y = x;
+ if (x >= 0)
+return x;
+ // FIXME: Her
https://github.com/steakhal approved this pull request.
Makes sense.
https://github.com/llvm/llvm-project/pull/127062
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
=?utf-8?q?Don=C3=A1t?= Nagy
Message-ID:
In-Reply-To:
https://github.com/steakhal approved this pull request.
Looks great. Thanks.
https://github.com/llvm/llvm-project/pull/127062
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.
https://github.com/steakhal edited
https://github.com/llvm/llvm-project/pull/127062
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -314,6 +314,7 @@ void MacOSKeychainAPIChecker::checkPreStmt(const CallExpr
*CE,
RegionArgIsBad = true;
}
+ assert(ArgSM);
steakhal wrote:
I'm okay with this assert.
It shouldn't change much though because the very next lookup would fail if this
wa
https://github.com/steakhal edited
https://github.com/llvm/llvm-project/pull/127017
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/steakhal updated
https://github.com/llvm/llvm-project/pull/127034
>From 518e232d68b73c884bc6c9a56b0d7c7e217e3d13 Mon Sep 17 00:00:00 2001
From: Balazs Benics
Date: Thu, 13 Feb 2025 10:36:42 +0100
Subject: [PATCH 1/2] [analyzer] Disable a flaky test while triaging why its
fla
https://github.com/steakhal created
https://github.com/llvm/llvm-project/pull/127034
I had previous attempts for fixing this flaky test. Let's admit I failed so
far, and disable this until we have a permanent fix.
See the discussion at:
https://github.com/llvm/llvm-project/pull/126913#issuecom
steakhal wrote:
I revisited the check using `ExprSequence`.
It became more actionable from what I can tell, but exposes weaknesses of
`ExprSequence` too, which I'll later demonstrate.
My approach with my prototype using `ExprSequence` was:
1) Collect lookups just like before.
2) Take the cros
@@ -91,6 +91,12 @@ Improvements to clang-tidy
New checks
^^
+- New :doc:`performance-redundant-lookup
+ ` check.
+
+ This check warns about potential redundant container lookup operations within
steakhal wrote:
Dropped in c6a681c955fef8b933374a05a15
steakhal wrote:
> @steakhal: Please fix documentation and Release Notes wording that I
> mentioned already.
Thanks, fixed!
I'm actually more curious about the semantic requirements, and about what
directions should I explore more.
https://github.com/llvm/llvm-project/pull/125420
_
@@ -2464,6 +2464,10 @@ CFGBlock
*CFGBuilder::VisitCXXDefaultInitExpr(CXXDefaultInitExpr *Init,
autoCreateBlock();
appendStmt(Block, Init);
}
+
+// Unlike CXXDefaultArgExpr::getExpr stripped off the top level FullExpr
and
+// ConstantExpr, CXXDefaultIni
steakhal wrote:
Ah, so this one is already merged. Then nvm. It's not worth a followup.
https://github.com/llvm/llvm-project/pull/126796
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
steakhal wrote:
> Thanks for the insight. Take your time.
So, I spent a few hours experimenting and it's really difficult to do, only
using `ExprSequence`.
Just to recap, my idea was to match the assignments and inc/dec unary operator
calls to detect if the container or the key object is mutat
=?utf-8?q?Balázs_Kéri?=
Message-ID:
In-Reply-To:
@@ -129,6 +129,8 @@ The ``SuppressAddressSpaces`` option suppresses
warnings for null dereferences of all pointers with address spaces. You can
disable this behavior with the option
``-analyzer-config core.NullDereference:Supp
=?utf-8?q?Bal=C3=A1zs_K=C3=A9ri?=
Message-ID:
In-Reply-To:
@@ -2919,6 +2921,42 @@ Check for assignment of a fixed address to a pointer.
p = (int *) 0x1; // warn
}
+.. _alpha-core-FixedAddressDereference:
+
+alpha.core.FixedAddressDereference (C, C++, ObjC)
+
=?utf-8?q?Balázs_Kéri?=
Message-ID:
In-Reply-To:
@@ -1,7 +1,163 @@
// RUN: %clang_analyze_cc1 -analyzer-checker=core,alpha.core -verify %s
-// expected-no-diagnostics
-void foo(void) {
+extern void __assert_fail (__const char *__assertion, __const char *__file,
+unsigned
2001 - 2100 of 2519 matches
Mail list logo
