NagyDonat wrote:
> The only spot I thought was questionable to change is this lower bound check
> in `ArrayBoundCheckerV2`; I think it is fine to leave unchanged for now,
> thoughts?
>
> https://github.com/llvm/llvm-project/blob/7e0758d2ead53bd4288989b8b2eda218cd6dc34a/clang/lib/StaticAnalyzer
NagyDonat wrote:
@Xazax-hun
When you write that this commit "makes memspaces a bit more error prone to use.
Do you think we could find a way to prevent using isa on memspaces?" do I
understand it correctly you mean that it's error-prone to use
`isa<...>(MR->getMemorySpace())` directly? This e
@@ -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
@@ -0,0 +1,62 @@
+//===-- 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
@@ -0,0 +1,47 @@
+//===-- MemSpaces.h ---*- 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
@@ -0,0 +1,62 @@
+//===-- 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/NagyDonat 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,62 @@
+//===-- 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
@@ -0,0 +1,62 @@
+//===-- 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/NagyDonat commented:
I strongly support the idea that we should eventually represent the memory
space of a memory region by a state trait (instead of the "fake" super-region)
and I am grateful that you're working on this.
I added a few suggestions in inline comments that cou
@@ -163,6 +163,42 @@ the use of preprocessor macros.
void my_assert_rtn(const char *, const char *, int, const char *)
CLANG_ANALYZER_NORETURN;
+Dynamic Memory Modeling Annotations
+###
+
+If a project uses custom functions for dynamic memor
https://github.com/NagyDonat updated
https://github.com/llvm/llvm-project/pull/122749
From 098e884885cc3f82eac66b735203610a6e2af01a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Don=C3=A1t=20Nagy?=
Date: Mon, 13 Jan 2025 18:20:06 +0100
Subject: [PATCH 1/2] [NFC][analyzer][docs] Improve Annotations.r
https://github.com/NagyDonat created
https://github.com/llvm/llvm-project/pull/122749
This commit fixes three issues within the documentation file `Annotations.rst`
which was recently created by my earlier commit
https://github.com/llvm/llvm-project/pull/122246 .
(1) The section title "Annota
NagyDonat wrote:
Buildbot failure https://lab.llvm.org/buildbot/#/builders/190/builds/12715 is
due to "IO failure on output stream: No space left on device" (on a random
Mach-O testcase) :sweat_smile:
https://github.com/llvm/llvm-project/pull/122246
https://github.com/NagyDonat closed
https://github.com/llvm/llvm-project/pull/122481
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
NagyDonat wrote:
... I still ended up with some annoying git wrangling: a force push and a merge
via the github gui editor. :face_with_diagonal_mouth: Next time I'll wait until
my commits are merged before creating a follow-up PR.
https://github.com/llvm/llvm-project/pull/122481
__
https://github.com/NagyDonat updated
https://github.com/llvm/llvm-project/pull/122481
From 161b66805ffb542d25d51ed336faba25457c5de1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Don=C3=A1t=20Nagy?=
Date: Fri, 10 Jan 2025 16:21:44 +0100
Subject: [PATCH] [NFC][analyzer][docs] Restore/remove orphaned i
https://github.com/NagyDonat updated
https://github.com/llvm/llvm-project/pull/122481
From 161b66805ffb542d25d51ed336faba25457c5de1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Don=C3=A1t=20Nagy?=
Date: Fri, 10 Jan 2025 16:21:44 +0100
Subject: [PATCH] [NFC][analyzer][docs] Restore/remove orphaned i
https://github.com/NagyDonat closed
https://github.com/llvm/llvm-project/pull/122246
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
NagyDonat wrote:
> Shouldn't we leave a stub in the old HTML page that the docs were moved? Or
> we haven't done that in the past either?
This commit _does_ leave a stub HTML page (which is closely modeled after the
earlier similar stub pages).
> I understand (and strongly agree with) you not
@@ -0,0 +1,208 @@
+FAQ and How to Deal with Common False Positives
+===
+
+.. contents::
+ :local:
+
+Custom Assertions
+-
+
+Q: How do I tell the analyzer that I do not want the bug being reported here
since my custom
https://github.com/NagyDonat closed
https://github.com/llvm/llvm-project/pull/122249
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
NagyDonat wrote:
I created PR https://github.com/llvm/llvm-project/pull/122481 which properly
handles these images.
https://github.com/llvm/llvm-project/pull/122249
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin
NagyDonat wrote:
The first two commits in this PR are separately reviewed at
https://github.com/llvm/llvm-project/pull/122246 and I intend to merge them
(squashed into a single commit) through that PR.
**In this PR please only review the third commit [[NFC][analyzer][docs]
Restore/remove orph
https://github.com/NagyDonat updated
https://github.com/llvm/llvm-project/pull/122246
From 4d558f5fff178b9897319b0e63dcf6f955e7eee9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Don=C3=A1t=20Nagy?=
Date: Wed, 8 Jan 2025 17:24:34 +0100
Subject: [PATCH 1/2] [NFC][analyzer][docs] Migrate 'annotations.h
https://github.com/NagyDonat approved this pull request.
https://github.com/llvm/llvm-project/pull/122272
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
NagyDonat wrote:
I assumed the correctness of the old commits, but now that I looked into it, it
seems that the three `example_*.png` images were orphaned by PR
https://github.com/llvm/llvm-project/pull/112831 which converted the FAQ from
HTML to RST. @gamesh411 Why didn't you add these images
@@ -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();
- Chk->SuppressAddressSpaces =
mgr.getAnalyzerOption
https://github.com/NagyDonat 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
@@ -206,7 +206,12 @@ def CallAndMessageChecker : Checker<"CallAndMessage">,
Documentation,
Dependencies<[CallAndMessageModeling]>;
-def DereferenceChecker : Checker<"NullDereference">,
+def DereferenceModeling : Checker<"DereferenceModeling">,
+ HelpText<"General support
https://github.com/NagyDonat approved this pull request.
Overall LGTM.
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
https://github.com/NagyDonat created
https://github.com/llvm/llvm-project/pull/122246
This commit migrates the contents of 'annotations.html' in the old HTML-based
documentation of the Clang static analyzer to the new RST-based documentation.
During this conversion I reordered the sections of
https://github.com/NagyDonat approved this pull request.
LGTM, thanks!
https://github.com/llvm/llvm-project/pull/121781
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/121910
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/NagyDonat approved this pull request.
LGTM, straightforward improvement.
https://github.com/llvm/llvm-project/pull/121910
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-com
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/121781
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/121781
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/121781
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/121781
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -525,14 +527,14 @@ class SymbolManager {
static bool canSymbolicate(QualType T);
- /// Make a unique symbol for MemRegion R according to its kind.
- const SymbolRegionValue* getRegionValueSymbol(const TypedValueRegion* R);
+ template const T *get(Args &&...args);
---
NagyDonat wrote:
My first idea is a "down to earth", not so modern, but more backwards
compatible approach:
- the analyzer option type stays plain `unsigned`;
- we introduce a new method called `validateAnalyzerOptionValues()` or
something similar;
- in this method we specify that `if (Z3Crossc
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/120239
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -213,6 +215,15 @@ ANALYZER_OPTION(
"400'000 should on average make Z3 queries run for up to 100ms on modern "
"hardware. Set 0 for unlimited.", 0)
+ANALYZER_OPTION(
+unsigned, Z3CrosscheckRetriesOnTimeout,
+"crosscheck-with-z3-retries-on-timeout",
+"Set
@@ -213,6 +215,15 @@ ANALYZER_OPTION(
"400'000 should on average make Z3 queries run for up to 100ms on modern "
"hardware. Set 0 for unlimited.", 0)
+ANALYZER_OPTION(
+unsigned, Z3CrosscheckRetriesOnTimeout,
+"crosscheck-with-z3-retries-on-timeout",
+"Set
@@ -525,14 +527,14 @@ class SymbolManager {
static bool canSymbolicate(QualType T);
- /// Make a unique symbol for MemRegion R according to its kind.
- const SymbolRegionValue* getRegionValueSymbol(const TypedValueRegion* R);
+ template const T *get(Args &&...args);
---
https://github.com/NagyDonat commented:
I'm grateful for this code quality improvement, it's nice to see that you got
rid of 180 lines of boilerplate :smile:
I have one minor inline suggestion that it would be nice to document the
purpose of this new template method; but otherwise the change i
@@ -224,6 +224,8 @@ class SymbolMetadata : public SymbolData {
const Stmt *S;
QualType T;
const LocationContext *LCtx;
+ /// Count can be used to differentiate regions corresponding to
+ /// different loop iterations, thus, making the symbol path-dependent.
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/121781
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/NagyDonat approved this pull request.
https://github.com/llvm/llvm-project/pull/120239
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/NagyDonat approved this pull request.
LGTM, thanks for the updates!
If the updated test passes, feel free to merge it.
https://github.com/llvm/llvm-project/pull/120239
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://
@@ -77,16 +80,32 @@ void
Z3CrosscheckVisitor::finalizeVisitor(BugReporterContext &BRC,
RefutationSolver->addConstraint(SMTConstraints);
}
- // And check for satisfiability
- llvm::TimeRecord Start = llvm::TimeRecord::getCurrentTime(/*Start=*/true);
- std::optional Is
https://github.com/NagyDonat commented:
I'm really grateful that you implemented my request about defining this option
as a positive value; especially considering that it ended up being more work
than what I expected. (I guessed that we must already had precedent(s) for
positive (or at least o
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/120239
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/NagyDonat approved this pull request.
LGTM, thanks for adding this documentation!
I added an inline suggestion that -- hopefully -- clarifies the differences
between held and taken memory areas; but the original is also completely OK.
Feel free to ignore or tweak my suggesti
@@ -1389,6 +1389,68 @@ Query for this attribute with
``__has_attribute(overloadable)``.
}];
}
+def OwnershipDocs : Documentation {
+ let Heading = "ownership_holds, ownership_returns, ownership_takes (Clang "
+"Static Analyzer)";
+ let Category = DocCatFun
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/121759
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
NagyDonat wrote:
> I adjusted the first commit message to highlight my answer to these
> questions. I hope that's clear enough.
Ok, I'd say that this explanation is _good enough_ to claim that "this change
may be helpful" -- which is sufficient to merge this change, because it's
conservative,
@@ -213,6 +215,15 @@ ANALYZER_OPTION(
"400'000 should on average make Z3 queries run for up to 100ms on modern "
"hardware. Set 0 for unlimited.", 0)
+ANALYZER_OPTION(
+unsigned, Z3CrosscheckRetriesOnTimeout,
+"crosscheck-with-z3-retries-on-timeout",
+"Set
https://github.com/NagyDonat approved this pull request.
LGTM, thanks for this improvement. Using the "raw" ordering of pointers is
always a red flag, I strongly support eliminating it if possible.
By the way, what fraction of the results is perturbed (replaced with other
random results) when
NagyDonat wrote:
> That being said, do we know how exactly the unstable addresses result in
> unstable results?
I cannot pinpoint the responsible code fragment, but in general this is a
typical property of associative data structures. A typical associative map
doesn't preserve the order of in
NagyDonat wrote:
The LLVM Buildbot failure is clearly unrelated to this commit -- it seems to be
a straightforward flakiness on a completely unrelated part of the project.
https://github.com/llvm/llvm-project/pull/119388
___
cfe-commits mailing list
c
https://github.com/NagyDonat closed
https://github.com/llvm/llvm-project/pull/119388
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
NagyDonat wrote:
> My bad. I thought I already approved this one.
No problem, I didn't intend to merge this during the Christmas period (when I
was on vacation and didn't want to monitor the effects of the change).
> Please mention this in the release notes.
I added a paragraph to the release
https://github.com/NagyDonat updated
https://github.com/llvm/llvm-project/pull/119388
From cb9b5ef4d8b0ed8e67276947525d327c547424fc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Don=C3=A1t=20Nagy?=
Date: Thu, 28 Nov 2024 17:22:58 +0100
Subject: [PATCH 1/9] [analyzer] Don't assume third iteration in
https://github.com/NagyDonat updated
https://github.com/llvm/llvm-project/pull/119388
From cb9b5ef4d8b0ed8e67276947525d327c547424fc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Don=C3=A1t=20Nagy?=
Date: Thu, 28 Nov 2024 17:22:58 +0100
Subject: [PATCH 1/8] [analyzer] Don't assume third iteration in
NagyDonat wrote:
If I understand correctly, I handled every review suggestion.
@steakhal If there are no additional suggestions, I'd be grateful for an
approval. (My follow-up commit is mostly ready, I'll release it soon after
merging this.)
https://github.com/llvm/llvm-project/pull/119388
__
NagyDonat wrote:
The logic that I added only affects the handling of the condition part of loop
statements, so it has absolutely no effect on the handling of code that
implements similar looping behavior with different language features. I added a
testcase to document this (and as an example,
https://github.com/NagyDonat updated
https://github.com/llvm/llvm-project/pull/119388
From cb9b5ef4d8b0ed8e67276947525d327c547424fc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Don=C3=A1t=20Nagy?=
Date: Thu, 28 Nov 2024 17:22:58 +0100
Subject: [PATCH 1/7] [analyzer] Don't assume third iteration in
https://github.com/NagyDonat updated
https://github.com/llvm/llvm-project/pull/119388
From cb9b5ef4d8b0ed8e67276947525d327c547424fc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Don=C3=A1t=20Nagy?=
Date: Thu, 28 Nov 2024 17:22:58 +0100
Subject: [PATCH 1/6] [analyzer] Don't assume third iteration in
NagyDonat wrote:
> > [...] To fix this problem, it would be sufficient to e.g. ensure that
> > evalEagerlyAssumeBifurcation sets LastEagerlyAssumeBifurcationAt to nullptr
> > [...]
>
> Sounds good to me. Let's zero it out after it's "used"/"consumed".
I took a different approach (which was al
https://github.com/NagyDonat commented:
Thanks for doing this NFC code fortification, I appreciate the effort!
I quickly read through all comments in this stack, and I approve their goals
and high-level structure. I'm not (yet) giving a formal approval only because I
didn't dig into the small
https://github.com/NagyDonat commented:
I'm a bit surprised by the idea of using multiple attempts instead of a single
run with a larger timeout -- intuitively we're wasting the already performed
calculations if we are impatient and abort+restart the calculations after each
short timeout (inst
@@ -213,6 +215,15 @@ ANALYZER_OPTION(
"400'000 should on average make Z3 queries run for up to 100ms on modern "
"hardware. Set 0 for unlimited.", 0)
+ANALYZER_OPTION(
+unsigned, Z3CrosscheckRetriesOnTimeout,
+"crosscheck-with-z3-retries-on-timeout",
+"Set
@@ -77,16 +80,33 @@ void
Z3CrosscheckVisitor::finalizeVisitor(BugReporterContext &BRC,
RefutationSolver->addConstraint(SMTConstraints);
}
- // And check for satisfiability
- llvm::TimeRecord Start = llvm::TimeRecord::getCurrentTime(/*Start=*/true);
- std::optional Is
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/120239
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/NagyDonat updated
https://github.com/llvm/llvm-project/pull/119388
From cb9b5ef4d8b0ed8e67276947525d327c547424fc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Don=C3=A1t=20Nagy?=
Date: Thu, 28 Nov 2024 17:22:58 +0100
Subject: [PATCH 1/2] [analyzer] Don't assume third iteration in
NagyDonat wrote:
Thanks for the review, I'll fix the minor remarks soon.
> I wonder how you found out that loop widening may conflict with this
> heuristic, were any tests broken that raised your awareness?
Yes, some (IIRC three) testcases fail in `loop-widening.c`.
> I have one concern with
https://github.com/NagyDonat closed
https://github.com/llvm/llvm-project/pull/109804
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
NagyDonat wrote:
I'm abandoning this PR because I decided to return to writing general commits
which improve the overall logic of the engine instead of just suppressing
results from one particular (heavily affected) checker. (Moreover, this PR
would've needed significant rebasing and code qual
NagyDonat wrote:
The difference between this PR and my earlier PR
https://github.com/llvm/llvm-project/pull/109804 "Suppress out of bounds
reports after weak loop assumptions" is:
| This PR | Earlier PR |
| :---: | :---: |
| affects all checkers | only affects ArrayBoundV2 |
| doesn't traverse
https://github.com/NagyDonat created
https://github.com/llvm/llvm-project/pull/119388
This commit ensures that if the loop condition is opaque (the analyzer cannot
determine whether it's true or false) and there were at least two iterations,
then the analyzer doesn't make the unjustified assum
https://github.com/NagyDonat approved this pull request.
The commit which introduced the new Z3 timeout logic
(https://github.com/llvm/llvm-project/pull/97298) was landed with my approval,
but since then I realized that this was a mistake -- in particular the concrete
fine-tuned default values
NagyDonat wrote:
I tested this commit on several open source projects, and as there were no
changes in the results, I'm merging this PR now.
https://github.com/llvm/llvm-project/pull/117898
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https
https://github.com/NagyDonat closed
https://github.com/llvm/llvm-project/pull/117898
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
NagyDonat wrote:
> The second is, how can we end up with such subregions. I think the only way
> is by field regions. If we had something that I missed, the assert would
> catch it.
Quick guesses: can we form a base or derived object subregion from them? Is
there some hacky pathway where we c
NagyDonat wrote:
I didn't run an analysis yet, because I was convinced about the correctness of
this change based on an understanding of the source code (and the fact that the
lit tests pass). However, I started a test run now to double-check this. I'll
merge this commit if it reveals no discr
https://github.com/NagyDonat created
https://github.com/llvm/llvm-project/pull/117898
Previously `BranchNodeBuilder` had a machinery to mark the two possible
branches (true, false) as infeasible, but this was completely useless in
practice, because the `BranchNodeBuilder` objects where short-l
https://github.com/NagyDonat approved this pull request.
I didn't systematically analyze all the small details of this commit, but
overall it looks good to me.
https://github.com/llvm/llvm-project/pull/117863
___
cfe-commits mailing list
cfe-commits@l
https://github.com/NagyDonat approved this pull request.
I'm not familiar with these files, but the change seems to be harmless enough...
Let's hope that it doesn't cause any weird bugs.
https://github.com/llvm/llvm-project/pull/117481
___
cfe-commits
https://github.com/NagyDonat approved this pull request.
LGTM, thanks for the updates.
https://github.com/llvm/llvm-project/pull/113899
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/NagyDonat approved this pull request.
Sorry for missing this review, I didn't noticed that this is distinct from the
similar `CallEnter` change.
https://github.com/llvm/llvm-project/pull/116034
___
cfe-commits mailing list
cfe-commi
NagyDonat wrote:
It turns out that this commit increases the runtime by ~3% on a set of 6-8 open
source projects that we used as a benchmark. (The testing was done on our local
fork by @gamesh411, he can provide more accurate data if needed.) Based on
this, we decided to temporarily disable th
https://github.com/NagyDonat closed
https://github.com/llvm/llvm-project/pull/111843
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/116840
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/NagyDonat approved this pull request.
The change LGTM and I'm happy to hear that you're improving the handling of
compound values. I hope that these foundational improvements will help further
development of checkers that deal with structured data. (Perhaps even the
iterator
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/116225
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/NagyDonat approved this pull request.
LGTM, with one minor simplification suggestion marked in an inline comment.
Disclaimer: I don't use this exploded-graph-rewriter tool, but the change seems
to be straightforward and useful.
https://github.com/llvm/llvm-project/pull/11622
@@ -86,6 +86,8 @@ def __init__(self, json_pp):
if json_pp["location"] is not None
else None
)
+elif self.kind == "CallEnter":
+self.callee_decl = json_pp["callee_decl"] if "callee_decl" in
json_pp else "None"
@@ -2605,9 +2608,43 @@ RegionBindingsRef
RegionStoreManager::bindVector(RegionBindingsConstRef B,
return NewB;
}
+std::optional
+RegionStoreManager::getUniqueDefaultBinding(nonloc::LazyCompoundVal LCV) const
{
+ const MemRegion *BaseR = LCV.getRegion();
+
+ // We only ha
https://github.com/NagyDonat approved this pull request.
LGTM, clean little patch, I don't have anything to say here.
https://github.com/llvm/llvm-project/pull/115918
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-b
1 - 100 of 847 matches
Mail list logo
