Re: [PATCH] D30691: [analyzer] Support for naive cross translational unit analysis

2018. márc. 1. 14:58 ezt írta ("Ilya Biryukov" ): I replied to a commit in the wrong thread (https://reviews.llvm.org/rL326323), sorry. Here are the important bits: This change introduced the following cyclic dependency in the build system: StaticAnalyzerCore -> CrossTU -> Frontend -> StaticAnaly

Re: [PATCH] D30691: [analyzer] Support for naive cross translational unit analysis

I am away from my workstation so I would really appreciate if you could recommit. Thanks in advance, Gábor 2018. márc. 1. 15:28 ezt írta ("Ilya Biryukov" ): > You're right. We have this extra dependency in our internal build files > for some reason and I missed that. > It's totally my fault. > >

Re: r368459 - Fix a build bot failure and multiple warnings instances for range base for loops

Hmm, strange. Looking into it! If I do not manage to find the root cause in a few minutes I will revert! On Fri, 9 Aug 2019 at 11:32, Jonas Devlieghere wrote: > I think this is causing a stage2 failure: > > http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/124/consoleFull#-95886206949ba46

Re: r368459 - Fix a build bot failure and multiple warnings instances for range base for loops

I reverted but I cannot reproduce this locally on a linux box. Is there any way to get more information from the build bot (like preprocessed files?)? On Fri, 9 Aug 2019 at 11:38, Gábor Horváth wrote: > Hmm, strange. Looking into it! If I do not manage to find the root cause > in a few minutes I

Re: r368459 - Fix a build bot failure and multiple warnings instances for range base for loops

I tried both with libc++ instead of libstdc++ and modules but none of them reproduced in my local machine I would be glad if you could try it locally as well! Thanks in advance, Gabor On Fri, 9 Aug 2019 at 13:10, Jonas Devlieghere wrote: > The bot is a little special in that it has modules enab

Re: r368459 - Fix a build bot failure and multiple warnings instances for range base for loops

Also, how does this stage2 bot work? I clearly see which revision is being compiled from the logs but it is not apparent to me what is the version of the compiler that is used to compiler it. Is it possible that due to some race condition a compiler before my fix is picked up and that is causing th

Re: r368499 - Attempt to reapply "Even more warnings utilizing gsl::Owner/gsl::Pointer annotations"

Indeed! There pointer is moved later on! Interestingly, I run these warnings on 300+ projects and none of them had this pattern. Will revert or fix the patch soon. On Fri, 9 Aug 2019 at 17:13, Nico Weber wrote: > http://lab.llvm.org:8011/builders/clang-with-lto-ubuntu/builds/14045 > > FAILED: >

Re: r368499 - Attempt to reapply "Even more warnings utilizing gsl::Owner/gsl::Pointer annotations"

It was an easy fix! In case any problem persists I will revert the commit with the fix itself. On Fri, 9 Aug 2019 at 17:16, Gábor Horváth wrote: > Indeed! > > There pointer is moved later on! Interestingly, I run these warnings on > 300+ projects and none of them had this pattern. Will revert or

Re: r368501 - Fix a false positive warning when initializing members with gsl::Owners.

It does! Do you want me to commit that test as well? On Fri, 9 Aug 2019 at 17:50, Nico Weber wrote: > This fixes `+ X(std::unique_ptr up) : pointee(up.get()), > pointer(std::move(up)) {}` as well, right? > > On Fri, Aug 9, 2019 at 8:31 PM Gabor Horvath via cfe-commits < > cfe-commits@lists.llvm

Re: r368446 - More warnings regarding gsl::Pointer and gsl::Owner attributes

You are right! I will look into this tomorrow. If you think this is urgent feel free to revert the commits. Cheers, Gabor On Sat, Aug 10, 2019, 6:41 PM Nico Weber wrote: > Hi Gabor, > > this makes clang warn on this program: > > $ cat test.cc > #include > #include > > struct S { > bool ope

Re: r368446 - More warnings regarding gsl::Pointer and gsl::Owner attributes

This should be fixed now. On Sat, Aug 10, 2019, 8:08 PM Gábor Horváth wrote: > You are right! > > I will look into this tomorrow. If you think this is urgent feel free to > revert the commits. > > Cheers, > Gabor > > On Sat, Aug 10, 2019, 6:41 PM Nico Weber wrote: > >> Hi Gabor, >> >> this make

Re: r368446 - More warnings regarding gsl::Pointer and gsl::Owner attributes

Great news! Thanks for all the feedback and patience! :) On Sun, Aug 11, 2019, 4:35 PM Nico Weber wrote: > Confirmed, after r368534 the Chromium builds looks good again. (r368528 > without r368534 regressed something else, but r368534 fixed things. I'm > assuming you don't need a repro for the

[PATCH] D24881: [clang-tidy] Cleaning up language options.

xazax.hun created this revision. xazax.hun added reviewers: hokein, alexfh. xazax.hun added a subscriber: cfe-commits. xazax.hun set the repository for this revision to rL LLVM. xazax.hun added a project: clang-tools-extra. Herald added a subscriber: nemanjai. In some cases do not register the mat

Re: [PATCH] D24881: [clang-tidy] Cleaning up language options.

xazax.hun added a comment. In https://reviews.llvm.org/D24881#551487, @Eugene.Zelenko wrote: > I think will be good idea to enable modernize-loop-convert, > modernize-use-auto, modernize-use-default, modernize-use-nullptr only in > C++11 mode. > > Probably modernize-avoid-bind code code be simp

[PATCH] D24894: [clang-tidy] Prefer transparent functors to non-transparent one.

xazax.hun created this revision. xazax.hun added reviewers: alexfh, hokein. xazax.hun added a subscriber: cfe-commits. xazax.hun set the repository for this revision to rL LLVM. xazax.hun added a project: clang-tools-extra. Herald added subscribers: mgorny, beanz. This check finds the usages of no

Re: [PATCH] D19586: Misleading Indentation check

xazax.hun added inline comments. Comment at: test/clang-tidy/readability-misleading-indentation.cpp:16 @@ +15,3 @@ + // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: wrong indentation, 'else' belongs to 'if(cond2)' statement + // CHECK-FIXES: {{^}} // commen

Re: [PATCH] D24905: Fix unreachable code false positive, vardecl in switch

xazax.hun added inline comments. Comment at: lib/StaticAnalyzer/Checkers/UnreachableCodeChecker.cpp:195 @@ +194,3 @@ +if (Optional S = I->getAs()) { + if (isa(S->getStmt())) +return S->getStmt(); Maybe I would prefer something like !isa which is a

Re: [PATCH] D24905: Fix unreachable code false positive, vardecl in switch

xazax.hun accepted this revision. xazax.hun added a comment. This revision is now accepted and ready to land. LGTM! https://reviews.llvm.org/D24905 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinf

[PATCH] D24878: ASTImporter: expressions, pt.2

xazax.hun added a comment. The referenced patch was commited. Could you close/abandon this one? https://reviews.llvm.org/D24878 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D25429: [analyzer] Link libStaticAnalyzerCheckers to libASTMatchers.

xazax.hun added a comment. I might be confused, but as far as I remember, when you do static linking, symbols tend to be linked in lazily. So as long as you do not use the matchers, those numbers might be misleading. https://reviews.llvm.org/D25429 __

[PATCH] D25429: [analyzer] Link libStaticAnalyzerCheckers to libASTMatchers.

xazax.hun added a comment. In https://reviews.llvm.org/D25429#565940, @NoQ wrote: > In https://reviews.llvm.org/D25429#565939, @xazax.hun wrote: > > > I might be confused, but as far as I remember, when you do static linking, > > symbols tend to be linked in lazily. So as long as you do not use

[clang] [analyzer][solver] On SymSym RelOps, check EQClass members for contradictions (PR #71284)

Xazax-hun wrote: > So, if I understand you correctly, at the 3rd if statement, we should > canonicalize the symbol we are constraining by walking every sub-symbol and > substituting it with its equivalent counterpart (if any), by basically with > its eqclass' representative symbol. I am not 1

[clang] [analyzer][solver] On SymSym RelOps, check EQClass members for contradictions (PR #71284)

Xazax-hun wrote: > So to be explicit, no other component would know what canonicalization > happens within the range-based solver. Oh, I see! Thanks for the clarification, this sounds good to me. https://github.com/llvm/llvm-project/pull/71284 ___ cf

[clang] [clang][dataflow] Fix assert-fail when calling assignment operator with by-value parameter. (PR #71384)

https://github.com/Xazax-hun approved this pull request. https://github.com/llvm/llvm-project/pull/71384 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][dataflow] Replace one remaining call to deprecated `addToFlowCondition()`. (PR #71547)

https://github.com/Xazax-hun approved this pull request. https://github.com/llvm/llvm-project/pull/71547 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][dataflow][NFC] Fix stale comments. (PR #71654)

https://github.com/Xazax-hun approved this pull request. https://github.com/llvm/llvm-project/pull/71654 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [analyzer] Switch to PostStmt callbacks in ArrayBoundV2 (PR #72107)

https://github.com/Xazax-hun approved this pull request. I wish we could clean up `checkLocation` to work as expected for all cases. It is more future proof in the sense that if C++ introduces new kinds of statements or expressions that could index into something (like multi-dimensional `opera

[clang] [analyzer] Switch to PostStmt callbacks in ArrayBoundV2 (PR #72107)

https://github.com/Xazax-hun edited https://github.com/llvm/llvm-project/pull/72107 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [analyzer] EnumCastOutOfRangeChecker: report the value (PR #74503)

https://github.com/Xazax-hun approved this pull request. LG, thanks! https://github.com/llvm/llvm-project/pull/74503 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [analyzer][NFC] Simplify BugType handling in core.BitwiseShift (PR #74609)

https://github.com/Xazax-hun approved this pull request. Thanks! https://github.com/llvm/llvm-project/pull/74609 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][dataflow] Convert `SpecialBoolAnalysis` to synthetic fields. (PR #74706)

https://github.com/Xazax-hun approved this pull request. https://github.com/llvm/llvm-project/pull/74706 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [NFC][CLANG] Fix static analyzer bugs about large copy by values (PR #75060)

@@ -110,7 +110,7 @@ void ModuleDepCollector::addOutputPaths(CowCompilerInvocation &CI, } static CowCompilerInvocation -makeCommonInvocationForModuleBuild(CompilerInvocation CI) { +makeCommonInvocationForModuleBuild(const CompilerInvocation &CI) { Xazax-hun wr

[clang] [NFC][CLANG] Fix static analyzer bugs about large copy by values (PR #75060)

https://github.com/Xazax-hun approved this pull request. https://github.com/llvm/llvm-project/pull/75060 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [NFC][CLANG] Fix static analyzer bugs about large copy by values (PR #75060)

Xazax-hun wrote: Could you also update the description of the patch? https://github.com/llvm/llvm-project/pull/75060 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [analyzer] Move alpha checker EnumCastOutOfRange to optin (PR #67157)

Xazax-hun wrote: I am a bit concerned about the bad user experience with bitwise enums, but I think that is probably OK since this is an optin check. That being said, I think: * It would be easy to address this, there is already a clang tidy check for bitwise enums, the heuristics to recognize

[clang] [clang][dataflow] Discard unneeded `ExprToLoc` and `ExprToVal` entries. (PR #72850)

@@ -311,7 +318,10 @@ computeBlockInputState(const CFGBlock &Block, AnalysisContext &AC) { } } - JoinedStateBuilder Builder(AC); + // When performing the join, only retain state for those expressions that are + // consumed by this block. This avoids performing joins a

[clang] [clang][dataflow] Discard unneeded `ExprToLoc` and `ExprToVal` entries. (PR #72850)

@@ -52,23 +52,39 @@ class ControlFlowContext { return StmtToBlock; } + /// Returns the expressions consumed by `Block`. These are all children of + /// statements in `Block` as well as children of a possible terminator. + const llvm::DenseSet * + getExprConsumedByBlo

[clang] [clang][dataflow] Discard unneeded `ExprToLoc` and `ExprToVal` entries. (PR #72850)

@@ -311,7 +318,10 @@ computeBlockInputState(const CFGBlock &Block, AnalysisContext &AC) { } } - JoinedStateBuilder Builder(AC); + // When performing the join, only retain state for those expressions that are + // consumed by this block. This avoids performing joins a

[clang] [clang][dataflow] Discard unneeded `ExprToLoc` and `ExprToVal` entries. (PR #72850)

https://github.com/Xazax-hun edited https://github.com/llvm/llvm-project/pull/72850 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][dataflow] Discard unneeded `ExprToLoc` and `ExprToVal` entries. (PR #72850)

Xazax-hun wrote: +1 for the simpler approach. I think I have a high-level question about the stability of the locations, its effect on convergence. But I am happy with the `ExprToVal` part of the simple patch. https://github.com/llvm/llvm-project/pull/72850

[clang] [clang][dataflow] Clear `ExprToLoc` and `ExprToVal` at the start of a block. (PR #72985)

https://github.com/Xazax-hun approved this pull request. https://github.com/llvm/llvm-project/pull/72985 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [analyzer] Fix assertion failure in CXXInstanceCall::getCXXThisVal (PR #70837)

https://github.com/Xazax-hun approved this pull request. https://github.com/llvm/llvm-project/pull/70837 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [analyzer] Fix assertion failure in CXXInstanceCall::getCXXThisVal (PR #70837)

Xazax-hun wrote: Hmm, I wonder if we should leave a FIXME comment, but it looks good to me. https://github.com/llvm/llvm-project/pull/70837 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-comm

[clang] [analyzer] Fix assertion failure in `CXXInstanceCall::getCXXThisVal` (PR #70837)

Xazax-hun wrote: > WDYT? I like this! I hope we do not add too much redundant work, but at least we make it clear what is the plan to fix this in the future. https://github.com/llvm/llvm-project/pull/70837 ___ cfe-commits mailing list cfe-commits@lis

[clang] [analyzer] Fix assertion failure in `CXXInstanceCall::getCXXThisVal` (PR #70837)

https://github.com/Xazax-hun approved this pull request. https://github.com/llvm/llvm-project/pull/70837 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [analyzer][NFC] Rework SVal kind representation (PR #71039)

https://github.com/Xazax-hun approved this pull request. https://github.com/llvm/llvm-project/pull/71039 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][analyzer] Do not analyze opaque types in CXXDeleteChecker (PR #70638)

Xazax-hun wrote: In case it is not too hard to synthesize a test case, could you add a regression test as well in a follow-up commit? https://github.com/llvm/llvm-project/pull/70638 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists

[clang] [analyzer][solver] On SymSym RelOps, check EQClass members for contradictions (PR #71284)

Xazax-hun wrote: I think every time we need to iterate over all member of an equivalence class, we might do something wrong. The point of the equivalence class would be to make sure those elements are equivalent. One way to avoid iteration would be to always use the representative of the equiv

[clang] [analyzer] Move alpha checker EnumCastOutOfRange to optin (PR #67157)

Xazax-hun wrote: Sounds good! https://github.com/llvm/llvm-project/pull/67157 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [analyzer] Move alpha checker EnumCastOutOfRange to optin (PR #67157)

https://github.com/Xazax-hun approved this pull request. https://github.com/llvm/llvm-project/pull/67157 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][dataflow] Strengthen pointer comparison. (PR #75170)

https://github.com/Xazax-hun edited https://github.com/llvm/llvm-project/pull/75170 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][dataflow] Strengthen pointer comparison. (PR #75170)

@@ -152,6 +153,47 @@ TEST_F(EnvironmentTest, JoinRecords) { } } +TEST_F(EnvironmentTest, DifferentReferenceLocInJoin) { Xazax-hun wrote: While running analysis on C++ code is indirect, it has the advantage of documenting what code can trigger such behavior

[clang] [clang][dataflow] Strengthen pointer comparison. (PR #75170)

https://github.com/Xazax-hun approved this pull request. This is a massive improvement! Thanks! Looks great to me, I have some not too important comments inline. https://github.com/llvm/llvm-project/pull/75170 ___ cfe-commits mailing list cfe-commits

[clang] [clang][dataflow] Strengthen pointer comparison. (PR #75170)

@@ -3893,6 +3893,66 @@ TEST(TransferTest, BooleanInequality) { }); } +TEST(TransferTest, PointerEquality) { Xazax-hun wrote: I think it would be great to add a test case with union members to document the limitation. https://github.com/llvm/llvm-proj

[clang] [clang][dataflow] Strengthen pointer comparison. (PR #75170)

Xazax-hun wrote: An alternative approach would be to do [hash consing](https://en.wikipedia.org/wiki/Hash_consing). Since pointer values are completely determined by the pointee (for some definition of the pointee, e.g., we might have `void*` and `int*` pointers pointing to the same storage

[clang] [clang][dataflow] Strengthen pointer comparison. (PR #75170)

Xazax-hun wrote: > It's probably a good thing for storage locations to have types (because we > want to be able to model the dynamic type of an object), but this probably > means that we want to model addresses separately from storage locations. Our knowledge of the dynamic type might change d

[clang] [clang][dataflow] Fix an issue with `Environment::getResultObjectLocation()`. (PR #75483)

@@ -726,27 +726,69 @@ void Environment::setStorageLocation(const Expr &E, StorageLocation &Loc) { // so allow these as an exception. assert(E.isGLValue() || E.getType()->isSpecificBuiltinType(BuiltinType::BuiltinFn)); - setStorageLocationInternal(E, Loc); + cons

[clang] [clang][dataflow] Fix an issue with `Environment::getResultObjectLocation()`. (PR #75483)

https://github.com/Xazax-hun approved this pull request. https://github.com/llvm/llvm-project/pull/75483 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][dataflow] Add `Environment::get<>()`. (PR #76027)

@@ -489,8 +489,7 @@ Environment Environment::pushCall(const CallExpr *Call) const { if (const auto *MethodCall = dyn_cast(Call)) { if (const Expr *Arg = MethodCall->getImplicitObjectArgument()) { if (!isa(Arg)) - Env.ThisPointeeLoc = - cast(ge

[clang] [clang][dataflow] Add `Environment::get<>()`. (PR #76027)

https://github.com/Xazax-hun approved this pull request. https://github.com/llvm/llvm-project/pull/76027 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][dataflow] Disallow setting properties on `RecordValue`s. (PR #76042)

https://github.com/Xazax-hun edited https://github.com/llvm/llvm-project/pull/76042 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][dataflow] Disallow setting properties on `RecordValue`s. (PR #76042)

https://github.com/Xazax-hun approved this pull request. https://github.com/llvm/llvm-project/pull/76042 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][dataflow] Disallow setting properties on `RecordValue`s. (PR #76042)

@@ -636,40 +636,37 @@ class OptionalIntAnalysis final if (!CS) return; const Stmt *S = CS->getStmt(); -auto OptionalIntRecordDecl = recordDecl(hasName("OptionalInt")); -auto HasOptionalIntType = hasType(OptionalIntRecordDecl); - -SmallVector Matches =

[clang] [clang][dataflow] Disallow setting properties on `RecordValue`s. (PR #76042)

@@ -184,33 +188,23 @@ class PointerValue final : public Value { /// In C++, prvalues of class type serve only a limited purpose: They can only /// be used to initialize a result object. It is not possible to access member /// variables or call member functions on a prvalue of c

[clang] [analyzer] Switch to PostStmt callbacks in ArrayBoundV2 (PR #72107)

@@ -34,20 +34,37 @@ using llvm::formatv; namespace { enum OOB_Kind { OOB_Precedes, OOB_Exceeds, OOB_Taint }; -class ArrayBoundCheckerV2 : -public Checker { +struct Messages { + std::string Short, Full; +}; + +class ArrayBoundCheckerV2 : public Checker, +

[clang] [analyzer] Switch to PostStmt callbacks in ArrayBoundV2 (PR #72107)

Xazax-hun wrote: Note that &array[idx] is perfectly valid code when `idx == number of elements`. And it is relatively common to do that when one is using STL algorithms on arrays: ``` auto it = std::find(&array[0], &array[size], foo); ``` Of course, one could use the `begin/end` free functions

[clang] [clang][analyzer] Move `security.cert.env.InvalidPtr` out of `alpha` (PR #71912)

https://github.com/Xazax-hun approved this pull request. https://github.com/llvm/llvm-project/pull/71912 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][analyzer] Support `fprintf` in the SecuritySyntaxChecker (PR #73247)

https://github.com/Xazax-hun approved this pull request. https://github.com/llvm/llvm-project/pull/73247 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][analyzer] Support `fprintf` in the SecuritySyntaxChecker (PR #73247)

Xazax-hun wrote: This is unrelated to this particular patch, but it would be great if this checker would also give suggestions what other functions should be used instead. https://github.com/llvm/llvm-project/pull/73247 ___ cfe-commits mailing list

[clang] [analyzer] Use AllocaRegion in MallocChecker (PR #72402)

Xazax-hun wrote: I think the original `alloca(0)` warning message might be clearer/easier to understand. While it might have platform or compiler dependent meaning, those behaviors are non-portable, so I think it is undesirable in most cases and people probably want to be notified about it. Re

[compiler-rt] [flang] [llvm] [libc] [libcxx] [clang] [clang-tools-extra] [clang][cleanup] simplify ReachableCode scanFromBlock (PR #72257)

@@ -341,30 +341,27 @@ static unsigned scanFromBlock(const CFGBlock *Start, // This allows us to potentially uncover some "always unreachable" code // within the "sometimes unreachable" code. // Look at the successors and mark then reachable. -std::optional Treat

[clang] [clang][dataflow] Strengthen widening of boolean values. (PR #73484)

https://github.com/Xazax-hun approved this pull request. https://github.com/llvm/llvm-project/pull/73484 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [analyzer] Switch to PostStmt callbacks in ArrayBoundV2 (PR #72107)

Xazax-hun wrote: I think another question is whether warning on code like `int& val = arr[i]` where `val` is not actually used on the path where `i == size` is OK. I would not block this PR on a case like this, but it might be nice to add a test and potentially a comment about the desired beha

[clang] [clang][dataflow] Add synthetic fields to `RecordStorageLocation` (PR #73860)

https://github.com/Xazax-hun edited https://github.com/llvm/llvm-project/pull/73860 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][dataflow] Add synthetic fields to `RecordStorageLocation` (PR #73860)

https://github.com/Xazax-hun commented: I generally love this direction, this was just a first pass, not a full review. I plan to take a second look but wanted to familiarize myself with the PR and start some conversations. https://github.com/llvm/llvm-project/pull/73860 __

[clang] [clang][dataflow] Add synthetic fields to `RecordStorageLocation` (PR #73860)

@@ -88,12 +94,12 @@ class ScalarStorageLocation final : public StorageLocation { class RecordStorageLocation final : public StorageLocation { public: using FieldToLoc = llvm::DenseMap; + using SyntheticFieldMap = llvm::StringMap; Xazax-hun wrote: I was wond

[clang] [clang][dataflow] Add synthetic fields to `RecordStorageLocation` (PR #73860)

@@ -92,11 +96,39 @@ class DataflowAnalysisContext { /*Logger=*/nullptr}); ~DataflowAnalysisContext(); + /// Sets a callback that returns the names and types of the synthetic fields + /// to add to a `RecordStorageLocation` of a given type. +

[clang] [clang][dataflow] Add synthetic fields to `RecordStorageLocation` (PR #73860)

@@ -92,11 +96,39 @@ class DataflowAnalysisContext { /*Logger=*/nullptr}); ~DataflowAnalysisContext(); + /// Sets a callback that returns the names and types of the synthetic fields + /// to add to a `RecordStorageLocation` of a given type. +

[clang] [clang][dataflow] Add synthetic fields to `RecordStorageLocation` (PR #73860)

https://github.com/Xazax-hun edited https://github.com/llvm/llvm-project/pull/73860 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][dataflow] Add synthetic fields to `RecordStorageLocation` (PR #73860)

@@ -367,3 +394,14 @@ clang::dataflow::FieldSet clang::dataflow::getObjectFields(QualType Type) { getFieldsFromClassHierarchy(Type, Fields); return Fields; } + +bool clang::dataflow::containsSameFields( +const clang::dataflow::FieldSet &Fields, +const clang::dataflo

[clang] [clang][dataflow] Add synthetic fields to `RecordStorageLocation` (PR #73860)

https://github.com/Xazax-hun approved this pull request. Overall, I love it! I have some comments on some features in the future, but those are probably not going to be addressed any time soon. First of all, I think in the future when we reason about the values of the pointers, synthetic field

[clang] [clang][dataflow] Add synthetic fields to `RecordStorageLocation` (PR #73860)

https://github.com/Xazax-hun edited https://github.com/llvm/llvm-project/pull/73860 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [analyzer] Let the checkers query upper and lower bounds on symbols (PR #74141)

Xazax-hun wrote: Does this work with Z3 as the solver? Since Z3 is not officially supported, I think it is not a blocker, but I'd love to see some FIXMEs/tickets opened in that case. https://github.com/llvm/llvm-project/pull/74141 ___ cfe-commits ma

[clang] [clang][dataflow] Disallow setting properties on `RecordValue`s. (PR #76042)

@@ -636,40 +636,37 @@ class OptionalIntAnalysis final if (!CS) return; const Stmt *S = CS->getStmt(); -auto OptionalIntRecordDecl = recordDecl(hasName("OptionalInt")); -auto HasOptionalIntType = hasType(OptionalIntRecordDecl); - -SmallVector Matches =

[clang] [clang][dataflow] Disallow setting properties on `RecordValue`s. (PR #76042)

https://github.com/Xazax-hun edited https://github.com/llvm/llvm-project/pull/76042 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [analyzer][docs] Update the release notes for llvm-18 (PR #76446)

https://github.com/Xazax-hun approved this pull request. https://github.com/llvm/llvm-project/pull/76446 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [analyzer][docs] Update the release notes for llvm-18 (PR #76446)

@@ -1072,16 +1146,36 @@ Static Analyzer Read the PR for the details. (`#66086 `_) +- Other taint-related improvements. + (`#66358 `_, + `#66074

[clang] [analyzer][docs] Update the release notes for llvm-18 (PR #76446)

https://github.com/Xazax-hun edited https://github.com/llvm/llvm-project/pull/76446 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [analyzer][docs] Update the release notes for llvm-18 (PR #76446)

@@ -1052,18 +1052,92 @@ libclang Static Analyzer --- +- Implemented the ``[[clang::suppress]]`` attribute for suppressing diagnostics + of static analysis tools, such as the Clang Static Analyzer. + `Documentation

[clang] [analyzer][NFC] Cleanup BugType lazy-init patterns (PR #76655)

@@ -31,14 +31,14 @@ class InvalidatedIteratorChecker check::PreStmt, check::PreStmt> { - std::unique_ptr InvalidatedBugType; + const BugType InvalidatedBugType{this, "Iterator invalidated", + "Misuse of

[clang] [analyzer][NFC] Cleanup BugType lazy-init patterns (PR #76655)

@@ -17,19 +17,18 @@ #include "MPITypes.h" #include "clang/StaticAnalyzer/Core/BugReporter/BugType.h" +#include "llvm/ADT/StringRef.h" namespace clang { namespace ento { namespace mpi { class MPIBugReporter { public: - MPIBugReporter(const CheckerBase &CB) { -Unma

[clang] [analyzer][NFC] Cleanup BugType lazy-init patterns (PR #76655)

@@ -52,10 +52,13 @@ class SimpleStreamChecker : public Checker { - CallDescription OpenFn, CloseFn; + const CallDescription OpenFn{{"fopen"}, 2}; + const CallDescription CloseFn{{"fclose"}, 1}; Xazax-hun wrote: Since we mostly use `CallDescription`s with compi

[clang] [analyzer][NFC] Cleanup BugType lazy-init patterns (PR #76655)

https://github.com/Xazax-hun approved this pull request. https://github.com/llvm/llvm-project/pull/76655 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [analyzer][NFC] Take small objects by value (PR #76688)

https://github.com/Xazax-hun approved this pull request. LGTM! Thanks! https://github.com/llvm/llvm-project/pull/76688 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][dataflow] Fix bug in `Value` comparison. (PR #76746)

@@ -27,9 +27,13 @@ static bool areEquivalentIndirectionValues(const Value &Val1, } bool areEquivalentValues(const Value &Val1, const Value &Val2) { - return &Val1 == &Val2 || (Val1.getKind() == Val2.getKind() && -(isa(&Val1) || -

[clang] [clang][dataflow] Fix bug in `Value` comparison. (PR #76746)

https://github.com/Xazax-hun approved this pull request. https://github.com/llvm/llvm-project/pull/76746 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][dataflow] Add an early-out to `flowConditionImplies()` / `flowConditionAllows()`. (PR #77453)

https://github.com/Xazax-hun approved this pull request. https://github.com/llvm/llvm-project/pull/77453 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][dataflow] Make cap on block visits configurable by caller. (PR #77481)

https://github.com/Xazax-hun approved this pull request. https://github.com/llvm/llvm-project/pull/77481 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][dataflow] Model assignment to derived class from base. (PR #85064)

@@ -212,8 +212,23 @@ TEST(TransferTest, CopyRecordFromDerivedToBase) { // [[p]] } )"; + auto SyntheticFieldCallback = [](QualType Ty) -> llvm::StringMap { +CXXRecordDecl *ADecl = nullptr; +if (Ty.getAsString() == "A") + ADecl = Ty->getAsCXXRecordDecl()

[clang] [clang][dataflow] Model assignment to derived class from base. (PR #85064)

@@ -14,18 +14,52 @@ #define DEBUG_TYPE "dataflow" -void clang::dataflow::copyRecord(RecordStorageLocation &Src, - RecordStorageLocation &Dst, Environment &Env) { +namespace clang::dataflow { + +static void copyField(const ValueDecl *Field, Sto

  1   2   3   4   5   6   >