NagyDonat wrote:
@balazske As we discussed in person, I think you switch to detecting
_dereference_ of fixed addresses (instead of extending the current "store of
fixed address in pointer value" model e.g. by the commit under review).
I think you should briefly look at DereferenceChecker and c
NagyDonat wrote:
Thanks for the information!
I'll merge this now and I might create a followup commit to remove the rest of
`TraversalChecker.cpp` later.
https://github.com/llvm/llvm-project/pull/113906
___
cfe-commits mailing list
cfe-commits@lists.
https://github.com/NagyDonat closed
https://github.com/llvm/llvm-project/pull/113906
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
NagyDonat wrote:
Thanks for the explanation -- code example reduction friendliness is a good
point that I didn't think about. Based on this, I support keeping that commit,
but perhaps add some remarks (in comments or the commit message, wherever you
think it's well-placed) that mentions code r
NagyDonat wrote:
Thanks for handling this issue!
My quick first impression is that I'm satisfied with your changes. However, I'm
a bit confused because as far as I see, the empty struct is _unable to_
transfer any attacker-controlled data, and therefore I don't know what does it
mean that it'
NagyDonat wrote:
> I did take the cases one by one from identical-expressions.cpp to the tidy
> checks and noticed one pattern. It looks to me like identical expressions
> utilizing floats were excluded in the tidy checks but found in the static
> analysis check. Do you want to retain that thr
https://github.com/NagyDonat commented:
Thanks for implementing this cleanup commit!
I like that you ported the tests from the old checker to the tidy checks.
However, as these test files are very large, perhaps it would be better to put
these moved tests into stand-alone files instead of addi
NagyDonat wrote:
Offtopic @Xazax-hun
> there are many ways to get to undef during constant folding (signed overflows
> ...
I was surprised to read this because as far as I know (knew) the analyzer
models signed operations as if overflow was completely natural for them. (See
e.g. the method `a
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/85224
___
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.
It seems that we forgot about this issue :sweat:
The change looks good to me at first glance, although I didn't investigate the
context and the the possible indirect effects.
https://github.com/llvm/llvm-project/pull/85224
__
https://github.com/NagyDonat commented:
Overall I support moving this checker out of alpha, because its narrow
functionality indeed seems to be stable enough for general use.
However, eventually it would be good to extend this checker to get a "real"
NonNullTerminated checker that can deduce t
@@ -53,3 +53,7 @@ struct TestNotNullTerm {
strlen((char *)&x); // expected-warning{{Argument to string length
function is not a null-terminated string}}
}
};
+
+void test_notcstring_tempobject() {
+ strlen((char[]){'a', 0}); // expected-warning{{Argument to string lengt
https://github.com/NagyDonat edited
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
NagyDonat wrote:
This PR takes a conservative approach and only removes the `BranchCondition`
callback from `TraversalChecker.cpp`.
However I don't think that `TraversalChecker.cpp` is useful for manual
debugging and it's only used in two very simple testcases
[[1]](https://github.com/llvm/l
https://github.com/NagyDonat created
https://github.com/llvm/llvm-project/pull/113906
This commit removes the `check::BranchCondition` callback of the debug checker
`debug.DumpTraversal` (in `TraversalChecker.cpp`) and the single broken
testcase that was referring to it.
The testcase `travers
https://github.com/NagyDonat updated
https://github.com/llvm/llvm-project/pull/113906
From 003236dd68aee99a0b53b93a4c3406a44fec0085 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Don=C3=A1t=20Nagy?=
Date: Mon, 28 Oct 2024 13:54:57 +0100
Subject: [PATCH 1/2] [analyzer][NFC] Remove check::BranchConditi
https://github.com/NagyDonat approved this pull request.
https://github.com/llvm/llvm-project/pull/112833
___
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 fixing this crash!
I also happy to see that you simplify the logic and clean up the variable
names. (I was a bit curious about the original reason that led to introduce
this pattern matching, but I see that you're the or
https://github.com/NagyDonat approved this pull request.
Looks good to me, this is an important improvement of report quality.
If the analysis is performed in a cloud-based environment (which is common),
the full path name of the analyzed file may contain e.g. directory names that
are unpredic
https://github.com/NagyDonat approved this pull request.
LGTM, straightforward NFC improvement. Thanks for cleaning this up!
(Currently the diff is a bit confusing, because this cleanup builds on the
not-yet-merged commit https://github.com/llvm/llvm-project/pull/112887, but
that's just GUI aw
https://github.com/NagyDonat approved this pull request.
LGTM. I already reviewed this together with the first step.
https://github.com/llvm/llvm-project/pull/112887
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin
@@ -2883,22 +2883,16 @@ const llvm::APSInt
*RangeConstraintManager::getSymVal(ProgramStateRef St,
const llvm::APSInt *RangeConstraintManager::getSymMinVal(ProgramStateRef St,
SymbolRef Sym) const {
- // TODO: Use `getR
@@ -18,242 +17,11 @@
FAQ and How to Deal with Common False Positives
+This page is deprecated and will be
removed in release 21.0
+https://clang.llvm.org/docs/analyzer/user-docs/FAQ.html";>The new
site
NagyDonat wrote:
```suggestion
Its content was migrate
@@ -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 edited
https://github.com/llvm/llvm-project/pull/112831
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/NagyDonat commented:
Overall LGTM, with some minor bikeshedding on the redirect page.
I also added several inline comments about the _content_ of the page, but the
content changes should be left for a separate follow-up commit to separate
migrating the text and changing it.
@@ -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
@@ -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
@@ -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 approved this pull request.
LGTM, thanks for the updates!
I have an optional suggestion/question in the only inline discussion that's
left unresolved, but feel free to merge this without handling that.
https://github.com/llvm/llvm-project/pull/112583
__
@@ -177,7 +177,8 @@ BugReportPtr BitwiseShiftValidator::checkOvershift() {
RightOpStr = formatv(" '{0}'", ConcreteRight->getValue());
else {
SValBuilder &SVB = Ctx.getSValBuilder();
-if (const llvm::APSInt *MinRight = SVB.getMinValue(FoldedState, Right)) {
+if
@@ -2883,22 +2883,16 @@ const llvm::APSInt
*RangeConstraintManager::getSymVal(ProgramStateRef St,
const llvm::APSInt *RangeConstraintManager::getSymMinVal(ProgramStateRef St,
SymbolRef Sym) const {
- // TODO: Use `getR
@@ -2866,12 +2877,14 @@ ConditionTruthVal
RangeConstraintManager::checkNull(ProgramStateRef State,
const llvm::APSInt *RangeConstraintManager::getSymVal(ProgramStateRef St,
SymbolRef Sym) const {
- const RangeSet *T = get
@@ -1485,6 +1487,18 @@ class SymbolicRangeInferrer
Sym->getType());
}
+ std::optional getRangeCommutativeSymSym(const SymSymExpr *SSE) {
+bool IsCommutative = llvm::is_contained({BO_Add, BO_Mul},
SSE->getOpcode());
+if (!IsCommutative)
+ return std::nu
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/112688
___
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 itself LGTM, but I'm a bit confused by the commit message.
Do I understand it correctly that the import was crashing (more precisely
running into an assertion failure) on some input? If yes, then this is not an
NFC change (but
https://github.com/NagyDonat requested changes to this pull request.
(The "approve mark" was accidental, this should not be merged without fixing
the trivial mistake that hardcodes addition.)
https://github.com/llvm/llvm-project/pull/112583
___
cfe-co
@@ -2866,12 +2877,14 @@ ConditionTruthVal
RangeConstraintManager::checkNull(ProgramStateRef State,
const llvm::APSInt *RangeConstraintManager::getSymVal(ProgramStateRef St,
SymbolRef Sym) const {
- const RangeSet *T = get
@@ -1485,6 +1487,18 @@ class SymbolicRangeInferrer
Sym->getType());
}
+ std::optional getRangeCommutativeSymSym(const SymSymExpr *SSE) {
+bool IsCommutative = llvm::is_contained({BO_Add, BO_Mul},
SSE->getOpcode());
+if (!IsCommutative)
+ return std::nu
@@ -50,28 +50,17 @@ void test2() {
b = d;
a -= d;
+ clang_analyzer_warnIfReached(); // expected-warning {{REACHABLE}}
+
if (a != 0)
return;
- clang_analyzer_warnIfReached(); // expected-warning{{REACHABLE}}
-
- /* The BASELINE passes these checks ('wrning' is
https://github.com/NagyDonat approved this pull request.
LGTM overall, see inline remarks for details.
https://github.com/llvm/llvm-project/pull/112583
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listi
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/112583
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
NagyDonat wrote:
> > * I think it's likely (although not guaranteed) that this heuristic would
> > be helpful for other checkers as well, and if we want to activate it for
> > all checkers, then it must be done in an eager way (because eagerly sinking
> > lots of paths is significantly better
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/112209
___
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/112209
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -299,13 +299,12 @@ ANALYZER_OPTION(
ANALYZER_OPTION(
bool, ShouldEagerlyAssume, "eagerly-assume",
-"Whether we should eagerly assume evaluations of conditionals, thus, "
-"bifurcating the path. This indicates how the engine should handle "
-"expressions such
@@ -458,7 +458,6 @@ ClangTidyASTConsumerFactory::createASTConsumer(
if (!AnalyzerOptions.CheckersAndPackages.empty()) {
setStaticAnalyzerCheckerOpts(Context.getOptions(), AnalyzerOptions);
AnalyzerOptions.AnalysisDiagOpt = PD_NONE;
-AnalyzerOptions.eagerlyAssumeBi
NagyDonat wrote:
@steakhal May I merge this commit?
https://github.com/llvm/llvm-project/pull/112209
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
NagyDonat wrote:
By the way, my plans for the "how do we get an accurate iteration count?" and
the "how do we handle complex loop conditions that contain short-circuit
operators?" issues is that in this first patch I want to go with the rough
approximation that's easiest to implement, and I'll
NagyDonat wrote:
@steakhal I'm sorry that I disappeared for more than a week when you dropped
your alternative implementation. I thought a lot about the advantages and
limitations of my implementation, your implementation and even "third way"
alternatives (but unfortunately `check::BranchCondi
@@ -121,6 +121,34 @@ struct EvalCallOptions {
EvalCallOptions() {}
};
+/// Simple control flow statements like `if` can only produce a single two-way
+/// state split, so when the analyzer cannot determine the value of the
+/// condition, it can assume either of the two opti
@@ -212,6 +212,25 @@ typedef llvm::ImmutableMap
REGISTER_TRAIT_WITH_PROGRAMSTATE(PendingArrayDestruction,
PendingArrayDestructionMap)
+// This trait is used to heuristically filter out results produced from
+// execution paths that took "weak"
@@ -194,3 +199,99 @@ char test_comparison_with_extent_symbol(struct incomplete
*p) {
return ((char *)p)[-1]; // no-warning
}
+// WeakLoopAssumption suppression
+///
+
+int GlobalArray[100];
+int loop_suppre
@@ -583,11 +603,11 @@ class ExprEngine {
ExplodedNode *Pred,
ExplodedNodeSet &Dst);
- /// evalEagerlyAssumeBinOpBifurcation - Given the nodes in 'Src', eagerly
assume symbolic
- /// expressions of the form 'x
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/112209
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -3742,23 +3742,20 @@ void ExprEngine::evalLocation(ExplodedNodeSet &Dst,
BldrTop.addNodes(Tmp);
}
-std::pair
-ExprEngine::geteagerlyAssumeBinOpBifurcationTags() {
- static SimpleProgramPointTag
- eagerlyAssumeBinOpBifurcationTrue(TagProviderName,
-
@@ -3767,28 +3764,26 @@ void
ExprEngine::evalEagerlyAssumeBinOpBifurcation(ExplodedNodeSet &Dst,
continue;
}
-ProgramStateRef state = Pred->getState();
-SVal V = state->getSVal(Ex, Pred->getLocationContext());
+ProgramStateRef State = Pred->getState();
+
@@ -299,13 +299,12 @@ ANALYZER_OPTION(
ANALYZER_OPTION(
bool, ShouldEagerlyAssume, "eagerly-assume",
-"Whether we should eagerly assume evaluations of conditionals, thus, "
-"bifurcating the path. This indicates how the engine should handle "
-"expressions such
https://github.com/NagyDonat updated
https://github.com/llvm/llvm-project/pull/112209
From ea6ab3fe84e5ac89f82def877c37c8409889d01d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Don=C3=A1t=20Nagy?=
Date: Mon, 14 Oct 2024 15:34:55 +0200
Subject: [PATCH 1/5] [analyzer][clang-tidy][NFC] Clean up eagerl
@@ -3742,23 +3742,20 @@ void ExprEngine::evalLocation(ExplodedNodeSet &Dst,
BldrTop.addNodes(Tmp);
}
-std::pair
-ExprEngine::geteagerlyAssumeBinOpBifurcationTags() {
- static SimpleProgramPointTag
- eagerlyAssumeBinOpBifurcationTrue(TagProviderName,
-
@@ -3742,23 +3742,20 @@ void ExprEngine::evalLocation(ExplodedNodeSet &Dst,
BldrTop.addNodes(Tmp);
}
-std::pair
-ExprEngine::geteagerlyAssumeBinOpBifurcationTags() {
- static SimpleProgramPointTag
- eagerlyAssumeBinOpBifurcationTrue(TagProviderName,
-
https://github.com/NagyDonat updated
https://github.com/llvm/llvm-project/pull/112209
From ea6ab3fe84e5ac89f82def877c37c8409889d01d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Don=C3=A1t=20Nagy?=
Date: Mon, 14 Oct 2024 15:34:55 +0200
Subject: [PATCH 1/4] [analyzer][clang-tidy][NFC] Clean up eagerl
@@ -3767,28 +3765,27 @@ void
ExprEngine::evalEagerlyAssumeBinOpBifurcation(ExplodedNodeSet &Dst,
continue;
}
-ProgramStateRef state = Pred->getState();
-SVal V = state->getSVal(Ex, Pred->getLocationContext());
+ProgramStateRef State = Pred->getState();
+
@@ -583,14 +583,14 @@ class ExprEngine {
ExplodedNode *Pred,
ExplodedNodeSet &Dst);
- /// evalEagerlyAssumeBinOpBifurcation - Given the nodes in 'Src', eagerly
assume symbolic
- /// expressions of the form 'x
@@ -3742,20 +3742,18 @@ void ExprEngine::evalLocation(ExplodedNodeSet &Dst,
BldrTop.addNodes(Tmp);
}
-std::pair
-ExprEngine::geteagerlyAssumeBinOpBifurcationTags() {
- static SimpleProgramPointTag
- eagerlyAssumeBinOpBifurcationTrue(TagProviderName,
-
https://github.com/NagyDonat created
https://github.com/llvm/llvm-project/pull/112209
This commit is a collection of several very minor code quality improvements.
The main goal is removing the misleading "Bin" substring from the names of
several methods and variables (like `evalEagerlyAssumedB
https://github.com/NagyDonat approved this pull request.
LGTM, this clarifiction is useful. I feel that these tests are very slightly
too verbose, but if you already wrote them, then we might as well keep them.
https://github.com/llvm/llvm-project/pull/112019
___
NagyDonat wrote:
> > The change LGTM, I think we can merge it.
>
> I guess the testcase pointer-sub.c have to be fixed to work on the windows
> buildbot, also. Right?
Right, thanks for catching my mistake!
https://github.com/llvm/llvm-project/pull/111846
__
https://github.com/NagyDonat approved this pull request.
The change LGTM, I think we can merge it.
My only nitpick was that I tweaked the PR title to make it a bit more accurate.
(Feel free to tweak it further / discuss this if you disagree with my choice.)
https://github.com/llvm/llvm-project
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/111846
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
NagyDonat wrote:
> Is it a possible way forward dropping that assert?
The function that performs the assertion is not part of the static analyzer,
it's a generic graph algorithm from an LLVM support library and the assertion
seems to be a really obvious sanity check. I don't think that it's re
@@ -212,6 +212,25 @@ typedef llvm::ImmutableMap
REGISTER_TRAIT_WITH_PROGRAMSTATE(PendingArrayDestruction,
PendingArrayDestructionMap)
+// This trait is used to heuristically filter out results produced from
+// execution paths that took "weak"
NagyDonat wrote:
Thanks for the explanation, I agree with your POV and I don't think that we
need a drastic change like renaming or reordering everything.
However, in this case I think it would be good to remove the type based section
headers, which are no longer accurate. When someone adds a
NagyDonat wrote:
@steakhal As I was browsing the list of analyzer options, I was surprised to
see that the numerical `unsigned` options added by this commit are placed in
the "Boolean analyzer options" section of `AnalyzerOptions.def`.
I understand that it's natural to group them together with
https://github.com/NagyDonat approved this pull request.
Looks good to me as well.
https://github.com/llvm/llvm-project/pull/110099
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -314,6 +329,193 @@ getFuchsiaHandleSymbols(QualType QT, SVal Arg,
ProgramStateRef State) {
return {};
}
+FuchsiaHandleChecker::Note FuchsiaHandleChecker::createNote(
+SymbolRef Sym,
+std::function Message) const {
+ return [Sym, Message](BugReport &BR) -> std::s
NagyDonat wrote:
> I just saw it in various easy checkers like `ValistChecker`, so I thought
> it's "standard" way of reporting.
Yes, ValistChecker is another example where it's useless. By the way that's the
first checker that I wrote (not completely alone) when I was an intern many
years ag
@@ -314,6 +449,127 @@ getFuchsiaHandleSymbols(QualType QT, SVal Arg,
ProgramStateRef State) {
return {};
}
+bool FuchsiaHandleChecker::needsInvalidate(const CallEvent &Call) const {
+ const FunctionDecl *FuncDecl =
dyn_cast_or_null(Call.getDecl());
+
+ assert(FuncDecl &&
@@ -99,6 +99,7 @@
#include "clang/StaticAnalyzer/Core/PathSensitive/ConstraintManager.h"
#include "clang/StaticAnalyzer/Core/PathSensitive/ExplodedGraph.h"
#include "clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h"
+#include "clang/StaticAnalyzer/Core/PathSensitive/Progr
@@ -314,6 +449,127 @@ getFuchsiaHandleSymbols(QualType QT, SVal Arg,
ProgramStateRef State) {
return {};
}
+bool FuchsiaHandleChecker::needsInvalidate(const CallEvent &Call) const {
+ const FunctionDecl *FuncDecl =
dyn_cast_or_null(Call.getDecl());
+
+ assert(FuncDecl &&
@@ -267,12 +286,128 @@ class FuchsiaHandleSymbolVisitor final : public
SymbolVisitor {
private:
SmallVector Symbols;
};
+
+class FuchsiaBugVisitor final : public BugReporterVisitor {
+ // Handle that caused a problem.
+ SymbolRef Sym;
+
+ bool IsLeak;
+
+public:
+ Fuchsi
@@ -267,12 +286,128 @@ class FuchsiaHandleSymbolVisitor final : public
SymbolVisitor {
private:
SmallVector Symbols;
};
+
+class FuchsiaBugVisitor final : public BugReporterVisitor {
+ // Handle that caused a problem.
+ SymbolRef Sym;
+
+ bool IsLeak;
+
+public:
+ Fuchsi
@@ -267,12 +286,128 @@ class FuchsiaHandleSymbolVisitor final : public
SymbolVisitor {
private:
SmallVector Symbols;
};
+
+class FuchsiaBugVisitor final : public BugReporterVisitor {
+ // Handle that caused a problem.
+ SymbolRef Sym;
+
+ bool IsLeak;
+
+public:
+ Fuchsi
@@ -336,141 +592,55 @@ void FuchsiaHandleChecker::checkPreCall(const CallEvent
&Call,
SmallVector Handles =
getFuchsiaHandleSymbols(PVD->getType(), Call.getArgSVal(Arg), State);
-// Handled in checkPostCall.
-if (hasFuchsiaAttr(PVD) ||
-hasFuchsiaA
@@ -127,26 +135,30 @@ class HandleState {
bool isEscaped() const { return K == Kind::Escaped; }
bool isUnowned() const { return K == Kind::Unowned; }
- static HandleState getMaybeAllocated(SymbolRef ErrorSym) {
-return HandleState(Kind::MaybeAllocated, ErrorSym);
+ s
@@ -314,6 +449,127 @@ getFuchsiaHandleSymbols(QualType QT, SVal Arg,
ProgramStateRef State) {
return {};
}
+bool FuchsiaHandleChecker::needsInvalidate(const CallEvent &Call) const {
+ const FunctionDecl *FuncDecl =
dyn_cast_or_null(Call.getDecl());
+
+ assert(FuncDecl &&
https://github.com/NagyDonat commented:
I read the patch and added my suggestions in inline comments, but I don't
promise that I found every little corner case.
Moreover, I'm strongly opposed to introducing a `BugReporterVisitor` instead of
directly creating the notes, because in this case you
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/111588
___
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. Let's not crash.
https://github.com/llvm/llvm-project/pull/111390
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,773 @@
+//===--- MutexModeling.cpp - Modeling of mutexes
--===//
+//
+// 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: Ap
@@ -0,0 +1,773 @@
+//===--- MutexModeling.cpp - Modeling of mutexes
--===//
+//
+// 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: Ap
@@ -0,0 +1,169 @@
+//===--- MutexModelingGDM.h - Modeling of mutexes in GDM
--===//
+//
+// 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: Ap
@@ -0,0 +1,126 @@
+//===--- MutexModelingDomain.h - Common vocabulary for modeling mutexes
---===//
+//
+// 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: Ap
@@ -0,0 +1,773 @@
+//===--- MutexModeling.cpp - Modeling of mutexes
--===//
+//
+// 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: Ap
@@ -0,0 +1,773 @@
+//===--- MutexModeling.cpp - Modeling of mutexes
--===//
+//
+// 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: Ap
@@ -0,0 +1,139 @@
+//===--- MutexRegionExtractor.h - Modeling of mutexes
-===//
+//
+// 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: Ap
https://github.com/NagyDonat commented:
Nice well-designed code; I added several remarks, but they are all minor.
https://github.com/llvm/llvm-project/pull/111381
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/ma
@@ -0,0 +1,139 @@
+//===--- MutexRegionExtractor.h - Modeling of mutexes
-===//
+//
+// 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: Ap
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/111381
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
NagyDonat wrote:
@pskrgag Thanks for fixing this issue quickly! :smile:
https://github.com/llvm/llvm-project/pull/111253
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
1 - 100 of 718 matches
Mail list logo
