@@ -0,0 +1,27 @@
+===
+Analysis Statistics
+===
+
+CSA enjoys two facilities to collect statistics: per translation unit and per
entry point.
+We use llvm/ADT/Statistic.h for numbers describing the entire translation unit
(TU).
+We use clang/Stati
@@ -0,0 +1,27 @@
+===
+Analysis Statistics
+===
+
+CSA enjoys two facilities to collect statistics: per translation unit and per
entry point.
+We use llvm/ADT/Statistic.h for numbers describing the entire translation unit
(TU).
+We use clang/Stati
https://github.com/NagyDonat updated
https://github.com/llvm/llvm-project/pull/130985
From 895b6947690ec51d8e8bccfa09420afae4449343 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Don=C3=A1t=20Nagy?=
Date: Mon, 3 Mar 2025 15:33:44 +0100
Subject: [PATCH 1/9] [NFC][analyzer] Framework for multipart chec
https://github.com/NagyDonat updated
https://github.com/llvm/llvm-project/pull/130985
From 895b6947690ec51d8e8bccfa09420afae4449343 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Don=C3=A1t=20Nagy?=
Date: Mon, 3 Mar 2025 15:33:44 +0100
Subject: [PATCH 01/10] [NFC][analyzer] Framework for multipart ch
@@ -190,23 +203,38 @@ class CheckerManager {
// Checker registration.
//======//
- /// Used to register checkers.
- /// All arguments are automatically passed through to the checker
- /// constructor.
@@ -190,23 +203,38 @@ class CheckerManager {
// Checker registration.
//======//
- /// Used to register checkers.
- /// All arguments are automatically passed through to the checker
- /// constructor.
@@ -0,0 +1,27 @@
+===
+Analysis Statistics
+===
+
+CSA enjoys two facilities to collect statistics: per translation unit and per
entry point.
+We use llvm/ADT/Statistic.h for numbers describing the entire translation unit
(TU).
+We use clang/Stati
@@ -0,0 +1,162 @@
+// EntryPointStats.h - Tracking statistics per entry point -*- C++ -*-//
NagyDonat wrote:
```suggestion
// EntryPointStats.h - Tracking statistics per entry point --*- C++ -*-//
```
Just a doubled space.
https://github.com/llvm/llvm-project/p
https://github.com/NagyDonat created
https://github.com/llvm/llvm-project/pull/131612
The virtual method `ProgramPointTag::getTagDescription` had two very distinct
use cases:
- It is printed in the DOT graph visualization of the exploded graph (that is,
a debug printout).
- The checker option
@@ -39,6 +39,9 @@ class ProgramPointTag {
public:
ProgramPointTag(void *tagKind = nullptr) : TagKind(tagKind) {}
virtual ~ProgramPointTag();
+
+ /// The description of this program point which will be displayed when the
+ /// ExplodedGraph is dumped in DOT format for debu
@@ -485,16 +485,60 @@ class Call {
} // end eval namespace
class CheckerBase : public ProgramPointTag {
- CheckerNameRef Name;
+ /// A single checker class (i.e. a subclass of `CheckerBase`) can implement
+ /// multiple user-facing checkers that have separate names and can
@@ -12,3 +12,4 @@ Contents:
developer-docs/nullability
developer-docs/RegionStore
developer-docs/PerformanceInvestigation
+ developer-docs/Statistics
NagyDonat wrote:
I am really happy that you're also adding a documentation page for this :smile:
h
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/131175
___
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/134869
___
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/135169
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,242 @@
+#!/usr/bin/env python3
+# A tool to automatically generate documentation for the config options of the
+# clang static analyzer by reading `AnalyzerOptions.def`.
+
+import argparse
+from collections import namedtuple
+from enum import Enum, auto
+import re
+impo
@@ -0,0 +1,102 @@
+
+Configuring the Analyzer
+
+
+The clang static analyzer supports two kinds of options:
+
+1. Global **analyzer options** influence the behavior of the analyzer engine.
+ They are documented on this page, in the
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/136720
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1,5 +1,5 @@
-// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection
-analyzer-config unroll-loops=true,cfg-loopexit=true -verify -std=c++14
-analyzer-config exploration_strategy=unexplored_first_queue %s
-// RUN: %clang_analyze_cc1 -analyzer-checker=core,debu
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/136720
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -81,10 +81,6 @@ class FunctionSummariesTy {
I->second.MayInline = 0;
}
- void markReachedMaxBlockCount(const Decl *D) {
-markShouldNotInline(D);
- }
NagyDonat wrote:
I'm removing this function (by inlining its trivial definition) because I feel
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/136720
___
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/136720
Recently some users reported that the runtime of the static analyzer
drastically increased on their codebase when they upgraded to a more recent
(sligthly patched, internal) clang version: some of their trans
@@ -0,0 +1,58 @@
+//===--- MisleadingSetterOfReferenceCheck.cpp -
clang-tidy-===//
+//
+// 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
@@ -2523,6 +2523,20 @@ bool ExprEngine::replayWithoutInlining(ExplodedNode *N,
return true;
}
+/// Return the innermost location context which is inlined at `Node`, unless
+/// it's the top-level (entry point) location context.
+static const LocationContext *getInlinedLocati
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/136720
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
NagyDonat wrote:
@balazs-benics-sonarsource Unfortunately our current CI (which runs the static
analyzer via CodeChecker) cannot provide file-level or entrypoint-level timing
information, but I do have full analysis runtime measurements (which I'll edit
into the table in my previous comment).
@@ -414,6 +414,20 @@ ANALYZER_OPTION(
"any target.",
true)
+ANALYZER_OPTION(
+bool, LegacyInliningPrevention, "legacy-inlining-prevention",
+"If enabled, the analyzer puts functions on a \"do not inline this\" list "
+"if it finds an execution path within t
@@ -2570,21 +2584,24 @@ void ExprEngine::processCFGBlockEntrance(const
BlockEdge &L,
const ExplodedNode *Sink =
nodeBuilder.generateSink(Pred->getState(), Pred, &tag);
-// Check if we stopped at the top level function or not.
-// Root node shoul
@@ -0,0 +1,198 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection
-verify=expected,default %s
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection
-analyzer-config legacy-inlining-prevention=false -verify=expected,disabled %s
+
+int get
NagyDonat wrote:
I tested the impact of this commit on various open source projects and the
changes in the result counts are surprisingly small:
| Project | New Reports | Resolved Reports |
|-|-|--|
| memcached | 0 new reports | 0 resolved reports
| tmux | 2
@@ -0,0 +1,198 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection
-verify=expected,default %s
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection
-analyzer-config legacy-inlining-prevention=false -verify=expected,disabled %s
+
+int get
@@ -2856,8 +2873,29 @@ void ExprEngine::processBranch(
// conflicts with the widen-loop analysis option (which is off by
// default). If we intend to support and stabilize the loop widening,
// we must ensure that it 'plays nicely' with this logic.
- if (
@@ -0,0 +1,198 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection
-verify=expected,default %s
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection
-analyzer-config legacy-inlining-prevention=false -verify=expected,disabled %s
+
+int get
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/136720
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -81,10 +81,6 @@ class FunctionSummariesTy {
I->second.MayInline = 0;
}
- void markReachedMaxBlockCount(const Decl *D) {
-markShouldNotInline(D);
- }
NagyDonat wrote:
I agree that it's OK to write code like
```c++
if ()
markReachedConditionX(A
NagyDonat wrote:
@balazs-benics-sonarsource Gentle ping
https://github.com/llvm/llvm-project/pull/136720
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2523,6 +2523,20 @@ bool ExprEngine::replayWithoutInlining(ExplodedNode *N,
return true;
}
+/// Return the innermost location context which is inlined at `Node`, unless
+/// it's the top-level (entry point) location context.
+static const LocationContext *getInlinedLocati
NagyDonat wrote:
The commit looks promising, my only remaining remarks are about phrasing in the
documentation and comments.
https://github.com/llvm/llvm-project/pull/132242
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.or
@@ -0,0 +1,58 @@
+//===--- MisleadingSetterOfReferenceCheck.cpp -
clang-tidy-===//
+//
+// 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/132242
___
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/136720
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
NagyDonat wrote:
I discussed the name with Endre (@gamesh411) in person and our best idea is
`inline-functions-with-ambiguous-loops` which would be the opposite of the
currently implemented `legacy-inlining-prevention` (i.e. the default would be
`inline-functions-with-ambiguous-loops=false` wh
@@ -0,0 +1,58 @@
+//===--- MisleadingSetterOfReferenceCheck.cpp -
clang-tidy-===//
+//
+// 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 @@
+.. title:: clang-tidy - bugprone-misleading-setter-of-reference
+
+bugprone-misleading-setter-of-reference
+===
+
+Finds setter-like member functions that take a pointer parameter and set a
+(non-const) reference member of the
@@ -6,42 +6,42 @@ bugprone-misleading-setter-of-reference
Finds setter-like member functions that take a pointer parameter and set a
(non-const) reference member of the same class with the pointed value.
+The checker detects public member functions that have a single parameter
@@ -0,0 +1,47 @@
+.. title:: clang-tidy - bugprone-misleading-setter-of-reference
+
+bugprone-misleading-setter-of-reference
+===
+
+Finds setter-like member functions that take a pointer parameter and set a
+(non-const) reference member of the
@@ -0,0 +1,42 @@
+.. title:: clang-tidy - bugprone-misleading-setter-of-reference
+
+bugprone-misleading-setter-of-reference
+===
+
+Finds setter-like functions that take a pointer parameter and set a (non-const)
NagyDonat wrote
@@ -0,0 +1,58 @@
+//===--- MisleadingSetterOfReferenceCheck.cpp -
clang-tidy-===//
+//
+// 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
NagyDonat wrote:
Also @vbvictor thanks for your helpful remarks. As far as I see they were all
addressed by @balazske -- do you have anything to add?
https://github.com/llvm/llvm-project/pull/132242
___
cfe-commits mailing list
cfe-commits@lists.llvm.
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/128735
___
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.
This commit looks good to me, although I'm not very familiar with this area.
I agree that the sentence "I did not check for other possibilities for
namespaces that are not in a TU or namespace but at least the code should
handle all case
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/128735
___
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/136720
From 011008bd03f66e9afdfb3eec24a1c1c8a4018f52 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Don=C3=A1t=20Nagy?=
Date: Tue, 22 Apr 2025 16:46:05 +0200
Subject: [PATCH 1/5] [analyzer] Workaround for unintended slowdo
NagyDonat wrote:
> But I was shocked that sometimes intuition fails, and we didn't check the RT
> for that patch.
This is a legacy project with many skeletons hidden in various closets... The
main moral of this story is probably that we should be more paranoid about
measuring runtime (I'm thi
@@ -2856,8 +2873,29 @@ void ExprEngine::processBranch(
// conflicts with the widen-loop analysis option (which is off by
// default). If we intend to support and stabilize the loop widening,
// we must ensure that it 'plays nicely' with this logic.
- if (
NagyDonat wrote:
Execution time comparisons between the commit under review and just reverting
https://github.com/llvm/llvm-project/commit/bb27d5e5c6b194a1440b8ac4e5ace68d0ee2a849
("Don't assume third iteration") atop
https://github.com/llvm/llvm-project/commit/a84a6f7dd68b218757e192fe21a806c8
NagyDonat wrote:
With the two recent commits I think I addressed all review comments except for
the "on-by-default config option" vs "unconditionally active logic" question.
In this area (which we discussed in inline comments) I'm still leaning towards
the currently implemented `legacy-inlinin
@@ -143,6 +143,32 @@ if (LLVM_ENABLE_SPHINX)
gen_rst_file_from_td(DiagnosticsReference.rst -gen-diag-docs
../include/clang/Basic/Diagnostic.td "${docs_targets}")
gen_rst_file_from_td(ClangCommandLineReference.rst -gen-opt-docs
../include/clang/Driver/ClangOptionDocs.td
@@ -0,0 +1,242 @@
+#!/usr/bin/env python3
+# A tool to automatically generate documentation for the config options of the
+# clang static analyzer by reading `AnalyzerOptions.def`.
+
+import argparse
+from collections import namedtuple
+from enum import Enum, auto
+import re
+impo
@@ -143,6 +143,32 @@ if (LLVM_ENABLE_SPHINX)
gen_rst_file_from_td(DiagnosticsReference.rst -gen-diag-docs
../include/clang/Basic/Diagnostic.td "${docs_targets}")
gen_rst_file_from_td(ClangCommandLineReference.rst -gen-opt-docs
../include/clang/Driver/ClangOptionDocs.td
@@ -7,6 +7,9 @@
//===--===//
//
// This file defines the analyzer options avaible with -analyzer-config.
+// Note that clang/docs/tools/generate_analyzer_options_docs.py relies on the
+// structure of this
@@ -0,0 +1,242 @@
+#!/usr/bin/env python3
+# A tool to automatically generate documentation for the config options of the
+# clang static analyzer by reading `AnalyzerOptions.def`.
+
+import argparse
+from collections import namedtuple
+from enum import Enum, auto
+import re
+impo
NagyDonat wrote:
If there is only one anonymous namespace for each TU, then what does the AST
import do in a situation like
```c++
TEST_P(ImportAndMergeAnonymousNamespace, NamespaceInLinkageSpec) {
const char *ToCode =
R"(
extern "C" {
namespace {
}
}
)";
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/136720
___
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/136720
___
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/135169
From 705372a8a2f6e87f5fdf6b0e99bfa6a13408c5d4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Don=C3=A1t=20Nagy?=
Date: Thu, 3 Apr 2025 20:13:04 +0200
Subject: [PATCH 1/4] [NFC][analyzer] Document configuration optio
NagyDonat wrote:
@steakhal I implemented most of your review suggestions (the only missing thing
is that I'll set up a test to validate that this script can parse
`AnalyzerOptions.def`).
Please check the wording of the disclaimers added by
https://github.com/llvm/llvm-project/pull/135169/comm
https://github.com/NagyDonat updated
https://github.com/llvm/llvm-project/pull/135169
From 705372a8a2f6e87f5fdf6b0e99bfa6a13408c5d4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Don=C3=A1t=20Nagy?=
Date: Thu, 3 Apr 2025 20:13:04 +0200
Subject: [PATCH 1/5] [NFC][analyzer] Document configuration optio
https://github.com/NagyDonat updated
https://github.com/llvm/llvm-project/pull/136720
Rate limit · GitHub
body {
background-color: #f6f8fa;
color: #24292e;
font-family: -apple-system,BlinkMacSystemFont,Segoe
UI,Helvetica,Arial,sans
https://github.com/NagyDonat updated
https://github.com/llvm/llvm-project/pull/136720
From 011008bd03f66e9afdfb3eec24a1c1c8a4018f52 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Don=C3=A1t=20Nagy?=
Date: Tue, 22 Apr 2025 16:46:05 +0200
Subject: [PATCH 1/7] [analyzer] Workaround for unintended slowdo
NagyDonat wrote:
> That being said, I wonder if we should record the presence of casts when we
> produce `ElementRegion`s to better help checks suppress potentially false
> results. This would just make some workarounds easier to write rather than
> having full modelling.
After stabilizing th
https://github.com/NagyDonat approved this pull request.
LGTM, thanks for the improvements :)
In the follow-up commits let's pay attention to the `ArrayBound` lower bound
check where the code says that _"A symbolic region in unknown space represents
an unknown pointer that may point into the m
NagyDonat wrote:
As I thought a bit more about the reorganization that I suggested, I realized
that it can be summarized as **we should synchronize adding the default
`Unknown` binding and calling `escapeValue`** -- because they correspond to the
two end-points of the same "_this_ value is sto
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/127602
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -483,6 +483,14 @@ ANALYZER_OPTION(
"behavior, set the option to 0.",
5)
+ANALYZER_OPTION(
+unsigned, RegionStoreMaxBindingFanOut, "region-store-max-binding-fanout",
+"This option limits how many sub-bindings a single binding operation can "
+"scatter int
@@ -2782,6 +2865,8 @@ RegionBindingsRef
RegionStoreManager::bindStruct(RegionBindingsConstRef B,
if (VI == VE)
break;
+ if (NewB.hasExhaustedBindingLimit())
+return NewB.escapeValues(VI, VE);
NagyDonat wrote:
This is confusing to r
@@ -176,31 +177,59 @@ class RegionBindingsRef : public
llvm::ImmutableMapRefpush_back(V);
+return *this;
+ }
+ RegionBindingsRef escapeValues(nonloc::CompoundVal::iterator Begin,
+ nonloc::CompoundVal::iterator End) const {
+for (SVal V :
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/127602
___
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'm really happy that you managed to track down and fix these slow corner
cases, and overall I like the code changes, but I there were a few places where
the code was difficult to understand for me (although this may be also related
to the fact that I di
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/127602
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
NagyDonat wrote:
(I'm writing a review right now, please wait a bit -- a few hours -- before
merging.)
https://github.com/llvm/llvm-project/pull/127602
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/list
NagyDonat wrote:
> An interesting thing could be to track in the analyzer the number of
> suppressed underflows (i.e.: the number of times we resorted to hacking with
> this solution). That way, we could have more information about how far we
> deviate from the precise modelling. This could pr
https://github.com/NagyDonat closed
https://github.com/llvm/llvm-project/pull/127117
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -176,31 +177,59 @@ class RegionBindingsRef : public
llvm::ImmutableMapRefpush_back(V);
+return *this;
+ }
+ RegionBindingsRef escapeValues(nonloc::CompoundVal::iterator Begin,
+ nonloc::CompoundVal::iterator End) const {
+for (SVal V :
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/127602
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -359,7 +326,80 @@ class RegionBindingsRef : public
llvm::ImmutableMapRef`
Perhaps use `Limited` instead of `Bounded` in the name of this class, because
the common linguistical origin of the words "Bounded" and "Binding" makes the
current name a bit hard to parse. (I almost r
https://github.com/NagyDonat commented:
> I'm sorry if the poor code quality hindered the comprehension.
I wouldn't say "poor code quality" -- the code was difficult to understand, but
mostly due to the inherent complexity of the logic that's being implemented
here.
> In short, I decided to p
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/127602
___
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/127814
Because it is one of the three "misplaced" test files that appeared under
`/clang/test/Analysis` but were unrelated to the clang static analyzer. For
background see the following discourse thread:
https://di
https://github.com/NagyDonat closed
https://github.com/llvm/llvm-project/pull/128887
___
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/129697
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
NagyDonat wrote:
No problem, in git we can eventually track down and resolve everything.
However, let's try to pay attention to putting logically separate tests into
separate files -- our tests are badly disorganized, but we can gradually
improve the average quality if we spend some attention
NagyDonat wrote:
:thinking: Instead of this change I could also imagine introducing an
accurately named explicit method – e.g. `StringRef toStringRef()` – and using
that for all `CheckerNameRef` → `StringRef` conversions (including the half
dozen cases where the codebase already uses `operator
https://github.com/NagyDonat created
https://github.com/llvm/llvm-project/pull/130780
`CheckerNameRef` is a trivial wrapper around a `StringRef` which is guaranteed
to be owned by the `CheckerRegistry` (the only `friend` of the class) because
other code can't call the private constructor.
Thi
https://github.com/NagyDonat updated
https://github.com/llvm/llvm-project/pull/129697
From 3a3236237e193fb1d1de1aed72e128195d4d0730 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Don=C3=A1t=20Nagy?=
Date: Tue, 4 Mar 2025 11:44:18 +0100
Subject: [PATCH 1/3] [NFC][analyzer] OOB test consolidation IV: r
https://github.com/NagyDonat closed
https://github.com/llvm/llvm-project/pull/130763
___
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/130763
Recently commit e5821bae80db3f3f0fe0d5f8ce62f79e548eed5 (which is a
re-application of 2b9abf0db2d106c7208b4372e662ef5df869e6f1) added some tests to
out-of-bonunds-new.cpp, which use a very simple out of bound
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/130763
___
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/130763
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
1001 - 1100 of 1319 matches
Mail list logo
