https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/125534
___
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/125534
___
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);
+
https://github.com/NagyDonat closed
https://github.com/llvm/llvm-project/pull/122749
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
NagyDonat wrote:
Yes, I also don't understand what caused the buildbot failure, but it's
definitely unrelated to this commit.
https://github.com/llvm/llvm-project/pull/122749
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.o
@@ -45,3 +48,91 @@ Note: Both Chrome-tracing and speedscope tools might
struggle with time traces a
Luckily, in most cases the default max-steps boundary of 225 000 produces the
traces of approximately that size
for a single entry point.
You can use ``-analyze-function=get_gl
NagyDonat wrote:
**Meta:** can we ensure that commits that modify files in `clang/test/Analysis`
(i.e. the static analyzer lit test directory) are tagged as "clang: static
analyzer"? I will have a few follow-up commits like this and don't want to spam
that label.
https://github.com/llvm/llvm-
https://github.com/NagyDonat created
https://github.com/llvm/llvm-project/pull/126539
Before commit 6e17ed9b04e5523cc910bf171c3122dcc64b86db the test file
`no-outofbounds.c` tested the behavior of the old alpha checker
`alpha.security.ArrayBound` (V1); then that commit converted it into a test
https://github.com/NagyDonat closed
https://github.com/llvm/llvm-project/pull/126094
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
NagyDonat wrote:
I verified that `git blame ArrayBoundChecker.cpp` correctly tracks that this
file is moved and can show the various commits that had modified
`ArrayBoundCheckerV2.cpp` in the past.
https://github.com/llvm/llvm-project/pull/126094
___
NagyDonat wrote:
I checked the buildbot reports and they are irrelevant timeouts in completely
unrelated parts of the testsuite.
https://github.com/llvm/llvm-project/pull/126094
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llv
https://github.com/NagyDonat created
https://github.com/llvm/llvm-project/pull/126094
Previously commit 6e17ed9b04e5523cc910bf171c3122dcc64b86db deleted the obsolete
checker `alpha.security.ArrayBound` which was implemented in
`ArrayBoundChecker.cpp` and renamed the checker `alpha.security.Arr
NagyDonat wrote:
This change is very trivial, but I'm opening a review for it because I'm not
sure what's the ideal time for merging this.
I' think putting this into a separate commit is already sufficient to prevent
any confusion between the old contents of `ArrayBoundChecker.cpp` (the obsole
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/125884
___
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/125884
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
NagyDonat wrote:
> I assume you intentionally did _not_ rename the ArrayBoundCheckerV2.cpp to
> ArrayBoundChecker.cpp to avoid the generating a diff that is much harder to
> understand than just the modification and the deletion of the old one. So
> consistency will be restored in trivial foll
https://github.com/NagyDonat updated
https://github.com/llvm/llvm-project/pull/126094
From 7440c102ba71485c2982aa160c961c163a3da5be Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Don=C3=A1t=20Nagy?=
Date: Thu, 6 Feb 2025 18:26:56 +0100
Subject: [PATCH 1/2] [analyzer][NFC] Remove "V2" from ArrayBoundC
NagyDonat wrote:
> Have you checked if anywhere in the docs or comments we still have "V2"
> somewhere?
I searched for `CheckerV2` and `BoundV2` and the only findings are:
- A annoying testcase called `test_demangle_pass` that contains references to
many obsolete code fragments (in strings, as
https://github.com/NagyDonat updated
https://github.com/llvm/llvm-project/pull/126094
From 7440c102ba71485c2982aa160c961c163a3da5be Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Don=C3=A1t=20Nagy?=
Date: Thu, 6 Feb 2025 18:26:56 +0100
Subject: [PATCH 1/3] [analyzer][NFC] Remove "V2" from ArrayBoundC
NagyDonat wrote:
The unittest failure seems to be random nonsense, apparently the Python package
`psutil` is not available on that windows machine:
> llvm-lit.py: C:\a\lld-x86_64-win\build\utils\lit\tests\lit.cfg:111: warning:
> Setting a timeout per test not supported. Requires the Python psut
https://github.com/NagyDonat updated
https://github.com/llvm/llvm-project/pull/125494
From d938ccc8bf6a0498ea2bf0fad89f4c207e8813f0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Don=C3=A1t=20Nagy?=
Date: Mon, 23 Dec 2024 12:20:35 +0100
Subject: [PATCH 1/3] [analyzer][NFC] Add option assume-one-itera
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/125494
___
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/125494
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
NagyDonat wrote:
I updated the name of the option and tried to clarify the comments that
describe the relationship with `eagerly-assume` (but it's just a
mostly-theoretical buggy corner case, so I wouldn't put it into the minimal
two-sentence documentation).
@gamesh411 @steakhal Are you satis
https://github.com/NagyDonat closed
https://github.com/llvm/llvm-project/pull/125534
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -294,6 +294,16 @@ ANALYZER_OPTION(
bool, ShouldUnrollLoops, "unroll-loops",
"Whether the analysis should try to unroll loops with known bounds.",
false)
+ANALYZER_OPTION(
+bool, ShouldAssumeOneIteration, "assume-one-iteration",
+"Whether the analyzer should
NagyDonat wrote:
> I'm in general open for changing the diagnostic message, but we should also
> consider the friction such renames can cause. Usually tools like CodeChecker
> or other frontends hash the messages, thus if it changes, the suppressions
> may not work ask expected before and afte
NagyDonat wrote:
> > can we ensure that commits that modify files in clang/test/Analysis
>
> I believe that directory has tests that are independent of the CSA.
:astonished: But why?? Is there any good reason for keeping this mixed test
folder, or is this just technical debt from the ancient c
https://github.com/NagyDonat approved this pull request.
https://github.com/llvm/llvm-project/pull/126676
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
NagyDonat wrote:
> > I completely agree that the message sounds a bit too much like "your code
> > is garbage" and that's not very nice.
>
> Ohh, now I see how this could be interpreted in a negative way. I never
> thought of this.
>
> I like where the discussion is heading with emphasizing t
NagyDonat wrote:
> This is a sufficiently strong contract in the static analyzer; I'm not aware
> of any long-lived undefined values and I'd consider it a bug if I ever see a
> long-lived undefined value. I'm pretty sure there are a few assertions that
> would crash if this ever happened.
>
>
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/126596
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/NagyDonat dismissed
https://github.com/llvm/llvm-project/pull/126596
___
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/126596
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/NagyDonat requested changes to this pull request.
I think "garbage" is a perfectly acceptable word, I don't think that its
"snarkiness" is a problem. (Note that e.g. "garbage collector" is a
well-established notion in programming.)
Even if you want to replace it, you need to
NagyDonat wrote:
Yes, obviously "garbage" has negative connotations, but we want to report an
_error_, so we need to have some negative connotations. It's pointless to start
an [euphemism treadmill](https://en.wiktionary.org/wiki/euphemism_treadmill)
because it just introduces churn without ac
https://github.com/NagyDonat created
https://github.com/llvm/llvm-project/pull/126748
This commit heavily refactors `out-of-bounds-constraint-check.c`:
1. The complex combinations of several `clang_analyzer_eval` calls were
replaced by `clang_analyzer_value`, which can directly query the range
NagyDonat wrote:
:thinking: This commit would increase the length of this test file. If you feel
that some tests are redundant, and could be left out, feel free to suggest so.
https://github.com/llvm/llvm-project/pull/126748
___
cfe-commits mailing li
https://github.com/NagyDonat closed
https://github.com/llvm/llvm-project/pull/125494
___
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/126748
From df63943adf054b94249b125078d4dbeafb437641 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Don=C3=A1t=20Nagy?=
Date: Tue, 11 Feb 2025 16:22:32 +0100
Subject: [PATCH 1/2] [NFC][analyzer] OOB test consolidation II:
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/126748
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1,112 +1,163 @@
// RUN: %clang_analyze_cc1
-analyzer-checker=core,unix.Malloc,security.ArrayBound,debug.ExprInspection \
// RUN: -analyzer-config eagerly-assume=false -verify %s
-void clang_analyzer_eval(int);
-void clang_analyzer_printState(void);
-
-typedef typeof(siz
https://github.com/NagyDonat updated
https://github.com/llvm/llvm-project/pull/126748
From df63943adf054b94249b125078d4dbeafb437641 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Don=C3=A1t=20Nagy?=
Date: Tue, 11 Feb 2025 16:22:32 +0100
Subject: [PATCH 1/4] [NFC][analyzer] OOB test consolidation II:
NagyDonat wrote:
> Please avoid matching the types of the `clang_analyzer_value` dumps, but be
> sure to match the whole range sets there, including their curlies. It's still
> important to know that it would have a single range associated.
Yes, that's what I was planning. Pushed a commit that
@@ -1,6 +1,4 @@
-// RUN: %clang_analyze_cc1 -Wno-array-bounds
-analyzer-checker=core,security.ArrayBound,debug.ExprInspection -verify %s
-
-void clang_analyzer_eval(int);
+// RUN: %clang_analyze_cc1 -Wno-array-bounds
-analyzer-checker=core,security.ArrayBound -verify %s
https://github.com/NagyDonat closed
https://github.com/llvm/llvm-project/pull/126748
___
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.
https://github.com/llvm/llvm-project/pull/125272
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
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
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
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
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
@@ -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 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
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 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
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 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
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 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
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:
> > > 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
@@ -1544,7 +1544,7 @@ SVal
RegionStoreManager::getBinding(RegionBindingsConstRef B, Loc L, QualType T)
// The location does not have a bound value. This means that it has
// the value it had upon its creation and/or entry to the analyzed
// function/method. These are e
@@ -353,7 +352,7 @@ static std::string getRegionName(const SubRegion *Region) {
return "the memory returned by 'alloca'";
if (isa(Region) &&
- isa(Region->getMemorySpace()))
+ isa(Region->getRawMemorySpace()))
NagyDonat wrote:
I think this sho
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
@@ -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/NagyDonat commented:
Thanks for the updates!
I added some inline remarks, but overall I'm satisfied with the state of this
PR and I hope that it can be merged soon.
However, I became a bit uncertain about the plans for follow-up changes,
because it seems that there are seve
@@ -948,8 +948,8 @@ SVal SimpleSValBuilder::evalBinOpLL(ProgramStateRef state,
const MemRegion *LeftBase = LeftMR->getBaseRegion();
const MemRegion *RightBase = RightMR->getBaseRegion();
-const MemSpaceRegion *LeftMS = LeftBase->getMemorySpace();
-const MemSpac
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 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
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 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:
> 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
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
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
@@ -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 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
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 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 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/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
@@ -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
@@ -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 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.
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
@@ -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 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
@@ -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
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
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
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
801 - 900 of 1313 matches
Mail list logo
