TTobias Hieta[clang][analyzer] Fix #embed crash (#107764)
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
Use APInt::getSignificantBits instead of APInt::getMinSignedBits (NFC) Note that getMinSignedBits has been soft-deprecated in favor of getSignificantBits. | 3 年前 | |
[analyzer][NFC] Move away from using raw-for loops inside StaticAnalyzer I'm involved with the Static Analyzer for the most part. I think we should embrace newer language standard features and gradually move forward. Differential Revision: https://reviews.llvm.org/D154325 | 2 年前 | |
[clang] Use std::optional instead of llvm::Optional (NFC) This patch replaces (llvm::|)Optional< with std::optional<. I'll post a separate patch to remove #include "llvm/ADT/Optional.h". This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716 | 3 年前 | |
[analyzer] Fix crash in BasicValueFactory.cpp with __int128_t integers (#67212) This change avoids a crash in BasicValueFactory by checking the bit width of an APSInt to avoid calling getZExtValue if greater than 64-bits. This was caught by our internal, randomized test generator. Clang invocation clang -cc1 -analyzer-checker=optin.portability.UnixAPI case.c <src-root>/llvm/include/llvm/ADT/APInt.h:1488: uint64_t llvm::APInt::getZExtValue() const: Assertion `getActiveBits() <= 64 && "Too many bits for uint64_t"' failed. ... #9 <address> llvm::APInt::getZExtValue() const <src-root>/llvm/include/llvm/ADT/APInt.h:1488:5 clang::BinaryOperatorKind, llvm::APSInt const&, llvm::APSInt const&) <src-root>/clang/lib/StaticAnalyzer/Core/BasicValueFactory.cpp:307:37 llvm::IntrusiveRefCntPtr<clang::ento::ProgramState const>, clang::BinaryOperatorKind, clang::ento::NonLoc, clang::ento::NonLoc, clang::QualType) <src-root>/clang/lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp:531:31 llvm::IntrusiveRefCntPtr<clang::ento::ProgramState const>, clang::BinaryOperatorKind, clang::ento::SVal, clang::ento::SVal, clang::QualType) <src-root>/clang/lib/StaticAnalyzer/Core/SValBuilder.cpp:532:26 ... | 2 年前 | |
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636 | 7 年前 | |
[analyzer] Improve bug report hashing, merge similar reports (#98621) Previously there were certain situations where alpha.security.ArrayBoundV2 produced lots of very similar and redundant reports that only differed in their full Description that contained the (negative) byte offset value. (See https://github.com/llvm/llvm-project/issues/86969 for details.) This change updates the Profile() method of PathSensitiveBugReport to ensure that it uses getShortDescription() instead of the full Description so the standard report deduplication eliminates most of these redundant reports. Note that the effects of this change are very limited because there are very few checkers that specify a separate short description, and so getShortDescription() practically always defaults to returning the full Description. For the sake of consistency BasicBugReport::Profile() is also updated to use the short description. (Right now there are no checkers that use BasicBugReport with separate long and short descriptions.) This commit also includes some small code quality improvements in ArrayBoundV2 that are IMO too trivial to be moved into a separate commit. | 1 年前 | |
Reland "[analyzer][NFC] Reorganize Z3 report refutation" (#97265) This is exactly as originally landed in #95128, but now the minimal Z3 version was increased to meet this change in #96682. https://discourse.llvm.org/t/bump-minimal-z3-requirements-from-4-7-1-to-4-8-9/79664/4 --- This change keeps existing behavior, namely that if we hit a Z3 timeout we will accept the report as "satisfiable". This prepares for the commit "Harden safeguards for Z3 query times". https://discourse.llvm.org/t/analyzer-rfc-taming-z3-query-times/79520 (cherry picked from commit 89c26f6c7b0a6dfa257ec090fcf5b6e6e0c89aab) | 1 年前 | |
[attributes][analyzer] Generalize [[clang::suppress]] to declarations. (#80371) The attribute is now allowed on an assortment of declarations, to suppress warnings related to declarations themselves, or all warnings in the lexical scope of the declaration. I don't necessarily see a reason to have a list at all, but it does look as if some of those more niche items aren't properly supported by the compiler itself so let's maintain a short safe list for now. The initial implementation raised a question whether the attribute should apply to lexical declaration context vs. "actual" declaration context. I'm using "lexical" here because it results in less warnings suppressed, which is the conservative behavior: we can always expand it later if we think this is wrong, without breaking any existing code. I also think that this is the correct behavior that we will probably never want to change, given that the user typically desires to keep the suppressions as localized as possible. | 2 年前 | |
Reland "[analyzer][NFC] Reorganize Z3 report refutation" (#97265) This is exactly as originally landed in #95128, but now the minimal Z3 version was increased to meet this change in #96682. https://discourse.llvm.org/t/bump-minimal-z3-requirements-from-4-7-1-to-4-8-9/79664/4 --- This change keeps existing behavior, namely that if we hit a Z3 timeout we will accept the report as "satisfiable". This prepares for the commit "Harden safeguards for Z3 query times". https://discourse.llvm.org/t/analyzer-rfc-taming-z3-query-times/79520 (cherry picked from commit 89c26f6c7b0a6dfa257ec090fcf5b6e6e0c89aab) | 1 年前 | |
[analyzer][NFC] Require explicit matching mode for CallDescriptions (#92454) This commit deletes the "simple" constructor of CallDescription which did not require a CallDescription::Mode argument and always used the "wildcard" mode CDM::Unspecified. A few months ago, this vague matching mode was used by many checkers, which caused bugs like https://github.com/llvm/llvm-project/issues/81597 and https://github.com/llvm/llvm-project/issues/88181. Since then, my commits improved the available matching modes and ensured that all checkers explicitly specify the right matching mode. After those commits, the only remaining references to the "simple" constructor were some unit tests; this commit updates them to use an explicitly specified matching mode (often CDM::SimpleFunc). The mode CDM::Unspecified was not deleted in this commit because it's still a reasonable choice in GenericTaintChecker and a few unit tests. | 2 年前 | |
[analyzer] Support C++23 static operator calls (#84972) Made by following: https://github.com/llvm/llvm-project/pull/83585#issuecomment-1980340866 Thanks for the details Tomek! CPP-5080 | 2 年前 | |
[analyzer][NFC] Fix inconsistent references to checkers as "checks" Traditionally, clang-tidy uses the term check, and the analyzer uses checker, but in the very early years, this wasn't the case, and code originating from the early 2010's still incorrectly refer to checkers as checks. This patch attempts to hunt down most of these, aiming to refer to checkers as checkers, but preserve references to callback functions (like checkPreCall) as checks. Differential Revision: https://reviews.llvm.org/D67140 llvm-svn: 371760 | 6 年前 | |
[clang] Use StringRef::operator== instead of StringRef::equals (NFC) (#91844) I'm planning to remove StringRef::equals in favor of StringRef::operator==. - StringRef::operator==/!= outnumber StringRef::equals by a factor of 24 under clang/ in terms of their usage. - The elimination of StringRef::equals brings StringRef closer to std::string_view, which has operator== but not equals. - S == "foo" is more readable than S.equals("foo"), especially for !Long.Expression.equals("str") vs Long.Expression != "str". | 2 年前 | |
[clang][analyzer] Model getline/getdelim preconditions and evaluation (#83027) According to POSIX 2018. 1. lineptr, n and stream can not be NULL. 2. If *n is non-zero, *lineptr must point to a region of at least *n bytes, or be a NULL pointer. Additionally, if *lineptr is not NULL, *n must not be undefined. | 2 年前 | |
[clang] Use std::optional instead of llvm::Optional (NFC) This patch replaces (llvm::|)Optional< with std::optional<. I'll post a separate patch to remove #include "llvm/ADT/Optional.h". This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716 | 3 年前 | |
[clang] Use StringRef::{starts,ends}_with (NFC) (#75149) This patch replaces uses of StringRef::{starts,ends}with with StringRef::{starts,ends}_with for consistency with std::{string,string_view}::{starts,ends}_with in C++20. I'm planning to deprecate and eventually remove StringRef::{starts,ends}with. | 2 年前 | |
[analyzer][NFC] Cleanup BugType lazy-init patterns (#76655) Cleanup most of the lazy-init BugType legacy. Some will be preserved, as those are slightly more complicated to refactor. Notice, that the default category for BugType is LogicError. I omitted setting this explicitly where I could. Please, actually have a look at the diff. I did this manually, and we rarely check the bug type descriptions and stuff in tests, so the testing might be shallow on this one. | 2 年前 | |
[analyzer][NFC] Workaround miscompilation on recent MSVC SVal argument 'Cond' passed in is corrupted in release mode with exception handling enabled (result in an UndefinedSVal), or changing lambda capture inside the callee can workaround this. Known problematic VS Versions: - VS 2022 17.4.4 - VS 2022 17.5.4 - VS 2022 17.7.2 Verified working VS Version: - VS 2019 16.11.25 Fixes https://github.com/llvm/llvm-project/issues/62130 Reviewed By: steakhal Differential Revision: https://reviews.llvm.org/D159163 | 2 年前 | |
[analyzer][NFC] Turn NodeBuilderContext into a class (#84638) From issue #73088. I changed NodeBuilderContext into a class. Additionally, there were some other mentions of the former being a struct which I also changed into a class. This is my first time working with an issue so I will be open to hearing any advice or changes that need to be done. | 2 年前 | |
[analyzer] Fix a few size-type inconsistency relating to DynamicExtent Size-type inconsistency (signedness) causes confusion and even bugs. For example when signed compared to unsigned the result might not be expected. Summary of this commit: Related APIs changes: 1. getDynamicExtent() returns signed version of extent; 2. Add getDynamicElementCountWithOffset() for offset version of element count; 3. getElementExtent() could be 0, add defensive checking for getDynamicElementCount(), if element is of zero-length, try ConstantArrayType::getSize() as element count; Related checker changes: 1. ArrayBoundCheckerV2: add testcase for signed <-> unsigned comparison from type-inconsistency results by getDynamicExtent() 2. ExprInspection: use more general API to report more results Fixes https://github.com/llvm/llvm-project/issues/64920 Reviewed By: donat.nagy, steakhal Differential Revision: https://reviews.llvm.org/D158499 | 2 年前 | |
[clang] Add a raw_ostream operator<< overload for QualType Under the hood this prints the same as QualType::getAsString() but cuts out the middle-man when that string is sent to another raw_ostream. Also cleaned up all the call sites where this occurs. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D123926 | 4 年前 | |
Fix analyzer crash on 'StructuralValue' (#79764) OpaqueValueExpr doesn't necessarily contain a source expression. Particularly, after #78041, it is used to carry the type and the value kind of a non-type template argument of floating-point type or referring to a subobject (those are so called StructuralValue arguments). This fixes #79575. | 2 年前 | |
[analyzer][NFC] Move away from using raw-for loops inside StaticAnalyzer I'm involved with the Static Analyzer for the most part. I think we should embrace newer language standard features and gradually move forward. Differential Revision: https://reviews.llvm.org/D154325 | 2 年前 | |
| 1 年前 | ||
[HLSL] Implement array temporary support (#79382) HLSL constant sized array function parameters do not decay to pointers. Instead constant sized array types are preserved as unique types for overload resolution, template instantiation and name mangling. This implements the change by adding a new ArrayParameterType which represents a non-decaying ConstantArrayType. The new type behaves the same as ConstantArrayType except that it does not decay to a pointer. Values of ConstantArrayType in HLSL decay during overload resolution via a new HLSLArrayRValue cast to ArrayParameterType. ArrayParamterType values are passed indirectly by-value to functions in IR generation resulting in callee generated memcpy instructions. The behavior of HLSL function calls is documented in the [draft language specification](https://microsoft.github.io/hlsl-specs/specs/hlsl.pdf) under the Expr.Post.Call heading. Additionally the design of this implementation approach is documented in [Clang's documentation](https://clang.llvm.org/docs/HLSL/FunctionCalls.html) Resolves #70123 | 2 年前 | |
Fix typos (#88565) | 2 年前 | |
[analyzer] Support C++23 static operator calls (#84972) Made by following: https://github.com/llvm/llvm-project/pull/83585#issuecomment-1980340866 Thanks for the details Tomek! CPP-5080 | 2 年前 | |
[analyzer] Remove rdar links from static analyzer and libAnalysis sources. NFC. I actually visited each link and added relevant context directly to the code. This is related to the effort to eliminate internal bug tracker links (d618f1c, e0ac46e). Test files still have a lot of rdar links and ids in them. I haven't touched them yet. | 2 年前 | |
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636 | 7 年前 | |
[analyzer][HTMLRewriter] Cache partial rewrite results. (#80220) This is a follow-up for 721dd3bc2 [analyzer] NFC: Don't regenerate duplicate HTML reports. Because HTMLRewriter re-runs the Lexer for syntax highlighting and macro expansion purposes, it may get fairly expensive when the rewriter is invoked multiple times on the same file. In the static analyzer (which uses HTMLRewriter for HTML output mode) we only get away with this because there are usually very few reports emitted per file. But if loud checkers are enabled, such as webkit.*, this may explode in complexity and even cause the compiler to run over the 32-bit SourceLocation addressing limit. This patch caches intermediate results so that re-lexing only needed to happen once. As the clever __COUNTER__ test demonstrates, "once" is still too many. Ideally we shouldn't re-lex anything at all, which remains a TODO. | 2 年前 | |
| 2 年前 | ||
[analyzer] Loop should contain CXXForRangeStmt (#70190) Static analyze can't report diagnose when statement after a CXXForRangeStmt and enable widen, because ExprEngine::processCFGBlockEntrance lacks of CXXForRangeStmt and when AMgr.options.maxBlockVisitOnPath - 1 equals to blockCount, it can't widen. After next iteration, BlockCount >= AMgr.options.maxBlockVisitOnPath holds and generate a sink node. Add CXXForRangeStmt makes it work. Co-authored-by: huqizhi <836744285@qq.com> | 2 年前 | |
[analyzer] Check the correct first and last elements in cstring.UninitializedRead (#95408) I intend to fix this checker up so that we can move it out of alpha. I made a bunch of analyses, and found many similar false positives: c++ int t[] = {1,2,3}; memcpy(dst, t, sizeof(t) / sizeof(t[0])); // warn The problem here is the way CStringChecker checks whether the destination and source buffers are initialized: heuristically, it only checks the first and last element. This is fine, however, it retrieves these elements as characters, even if the underlaying object is not a character array. Reading the last byte of an integer is undefined, so the checker emits a bug here. A quick search tells you the rationale: "Both objects are reinterpreted as arrays of unsigned char.". But the static analyzer right now can't check byte-by-byte if a memory region is _initialized_, it can only check if its a well-defined character or not. In this patch, I pry the original array out of the arguments to memcpy (and similar functions), and retrieve the actual first and last elements according to the array's actual element type. Currently, my improvements reduced the number of reports to 29 on these projects: memcached,tmux,curl,twin,vim,openssl,sqlite,ffmpeg,postgres https://codechecker-demo.eastus.cloudapp.azure.com/Default/reports?detection-status=New&detection-status=Reopened&detection-status=Unresolved&is-unique=on&run=%2acstring_uninit_upper_bound_patched&newcheck=%2acstring_uninit_upper_bounds_patched&diff-type=New&checker-name=alpha.unix.cstring.UninitializedRead&items-per-page=100 Before my patch, there were 87. https://codechecker-demo.eastus.cloudapp.azure.com/Default/reports?detection-status=New&detection-status=Reopened&detection-status=Unresolved&is-unique=on&run=%2acstring_uninit_baseline&newcheck=%2acstring_uninit_upper_bounds_patched&diff-type=New&checker-name=alpha.unix.cstring.UninitializedRead&items-per-page=100 | 1 年前 | |
Reapply "[clang] NFCI: Adopt SourceManager::getFileEntryRefForID()" This reapplies ddbcc10b9e26b18f6a70e23d0611b9da75ffa52f, except for a tiny part that was reverted separately: 65331da0032ab4253a4bc0ddcb2da67664bd86a9. That will be reapplied later on, since it turned out to be more involved. This commit is enabled by 5523fefb01c282c4cbcaf6314a9aaf658c6c145f and f0f548a65a215c450d956dbcedb03656449705b9, specifically the part that makes 'clang-tidy/checkers/misc/header-include-cycle.cpp' separator agnostic. | 2 年前 | |
[analyzer] print() JSONify: Environment implementation Summary: - Reviewers: NoQ, xazax.hun, ravikandhadai, baloghadamsoftware, Szelethus Reviewed By: NoQ Subscribers: szepet, rnkovacs, a.sidorin, mikhail.ramalho, donat.nagy, dkrupp Tags: #clang Differential Revision: https://reviews.llvm.org/D62081 llvm-svn: 361976 | 6 年前 | |
[analyzer] Wrap SymbolicRegions by ElementRegions before getting a FieldRegion (#85211) Inside the ExprEngine when we process the initializers, we create a PostInitializer program-point, which will refer to the field being initialized, see FieldLoc inside ExprEngine::ProcessInitializer. When a constructor (of which we evaluate the initializer-list) is analyzed in top-level context, then the this pointer will be represented by a SymbolicRegion, (as it should be). This means that we will form a FieldRegion{SymbolicRegion{.}} as the initialized region. c++ class Bear { public: void brum() const; }; class Door { public: // PostInitializer would refer to "FieldRegion{SymRegion{this}}" // whereas in the store and everywhere else it would be: // "FieldRegion{ELementRegion{SymRegion{Ty*, this}, 0, Ty}". Door() : ptr(nullptr) { ptr->brum(); // Bug } private: Bear* ptr; }; We (as CSA folks) decided to avoid the creation of FieldRegions directly of symbolic regions in the past: https://github.com/llvm/llvm-project/commit/f8643a9b31c4029942f67d4534c9139b45173504 --- In this patch, I propose to also canonicalize it as in the mentioned patch, into this: FieldRegion{ElementRegion{SymbolicRegion{Ty*, .}, 0, Ty} This would mean that FieldRegions will/should never simply wrap a SymbolicRegion directly, but rather an ElementRegion that is sitting in between. This patch should have practically no observable effects, as the store (due to the mentioned patch) was made resilient to this issue, but we use PostInitializer::getLocationValue() for an alternative reporting, where we faced this issue. Note that in really rare cases it suppresses now dereference bugs, as demonstrated in the test. It is because in the past we failed to follow the region of the PostInitializer inside the StoreSiteFinder visitor - because it was using this code: c++ // If this is a post initializer expression, initializing the region, we // should track the initializer expression. if (std::optional<PostInitializer> PIP = Pred->getLocationAs<PostInitializer>()) { const MemRegion *FieldReg = (const MemRegion *)PIP->getLocationValue(); if (FieldReg == R) { StoreSite = Pred; InitE = PIP->getInitializer()->getInit(); } } Notice that the equality check didn't pass for the regions I'm canonicalizing in this patch. Given the nature of this change, we would rather upstream this patch. CPP-4954 | 2 年前 | |
[clang][StaticAnalyzer] Avoid 'raw_string_ostream::str' (NFC) Since raw_string_ostream doesn't own the string buffer, it is desirable (in terms of memory safety) for users to directly reference the string buffer rather than use raw_string_ostream::str(). Work towards TODO comment to remove raw_string_ostream::str(). | 1 年前 | |
[analyzer] Fix crash in RangedConstraintManager.cpp This change fixes a crash in RangedConstraintManager.cpp:assumeSym due to an unhandled BO_Div case. clang: <root>clang/lib/StaticAnalyzer/Core/RangedConstraintManager.cpp:51: virtual clang::ento::ProgramStateRef clang::ento::RangedConstraintManager::assumeSym(clang::ento::ProgramStateRef, clang::ento::SymbolRef, bool): Assertion `BinaryOperator::isComparisonOp(Op)' failed. Reviewed By: NoQ Differential Revision: https://reviews.llvm.org/D122277 | 4 年前 | |
[analyzer] Fix stores through label locations (#89265) Interestingly, this case crashed from the very beginning of the project, at least starting by clang-3. As a "fix" I just do the same thing as we do for concrete integers. It might not be the best we could do, but arguably, it's still better than crashing. Fixes #89185 | 2 年前 | |
[llvm][clang][NFC] updates inline licence info Some files still contained the old University of Illinois Open Source Licence header. This patch replaces that with the Apache 2 with LLVM Exception licence. Differential Revision: https://reviews.llvm.org/D107528 | 4 年前 | |
[analyzer] Use AllocaRegion in MallocChecker (#72402) ...to model the results of alloca() and _alloca() calls. Previously it acted as if these functions were returning memory from the heap, which led to alpha.security.ArrayBoundV2 producing incorrect messages. | 2 年前 | |
[clang][StaticAnalyzer] Avoid 'raw_string_ostream::str' (NFC) Since raw_string_ostream doesn't own the string buffer, it is desirable (in terms of memory safety) for users to directly reference the string buffer rather than use raw_string_ostream::str(). Work towards TODO comment to remove raw_string_ostream::str(). | 1 年前 | |
Refactor StaticAnalyzer to use clang::SarifDocumentWriter Refactor StaticAnalyzer to use clang::SarifDocumentWriter for serializing sarif diagnostics. Uses clang::SarifDocumentWriter to generate SARIF output in the StaticAnalyzer. Various bugfixes are also made to clang::SarifDocumentWriter. Summary of changes: clang/lib/Basic/Sarif.cpp: * Fix bug in adjustColumnPos introduced from prev move, it now uses FullSourceLoc::getDecomposedExpansionLoc which provides the correct location (in the presence of macros) instead of FullSourceLoc::getDecomposedLoc. * Fix createTextRegion so that it handles caret ranges correctly, this should bring it to parity with the previous implementation. clang/test/Analysis/diagnostics/Inputs/expected-sarif: * Update the schema URL to the offical website * Add the emitted defaultConfiguration sections to all rules * Annotate results with the "level" property clang/lib/StaticAnalyzer/Core/SarifDiagnostics.cpp: * Update SarifDiagnostics class to hold a clang::SarifDocumentWriter that it uses to convert diagnostics to SARIF. | 3 年前 | |
[analyzer][NFC] Rework SVal kind representation (#71039) The goal of this patch is to refine how the SVal base and sub-kinds are represented by forming one unified enum describing the possible SVals. This means that the unsigned SVal::Kind and the attached bit-packing semantics would be replaced by a single unified enum. This is more conventional and leads to a better debugging experience by default. This eases the need of using debug pretty-printers, or the use of runtime functions doing the printing for us like we do today by calling Val.dump() whenever we inspect the values. Previously, the first 2 bits of the unsigned SVal::Kind discriminated the following quartet: UndefinedVal, UnknownVal, Loc, or NonLoc. The rest of the upper bits represented the sub-kind, where the value represented the index among only the Locs or NonLocs, effectively attaching 2 meanings of the upper bits depending on the base-kind. We don't need to pack these bits, as we have plenty even if we would use just a plan-old unsigned char. Consequently, in this patch, I propose to lay out all the (non-abstract) SVal kinds into a single enum, along with some metadata (BEGIN_Loc, END_Loc, BEGIN_NonLoc, END_NonLoc) artificial enum values, similar how we do with the MemRegions. Note that in the unified SVal::Kind enum, to differentiate nonloc::ConcreteInt from loc::ConcreteInt, I had to prefix them with Loc and NonLoc to resolve this ambiguity. This should not surface in general, because I'm replacing the nonloc::Kind enum items with inline constexpr global constants to mimic the original behavior - and offer nicer spelling to these enum values. Some SVal constructors were not marked explicit, which I now mark as such to follow best practices, and marked others as /*implicit*/ to clarify the intent. During refactoring, I also found at least one function not marked LLVM_ATTRIBUTE_RETURNS_NONNULL, so I did that. The TypeRetrievingVisitor visitor had some accidental dead code, namely: VisitNonLocConcreteInt and VisitLocConcreteInt. Previously, the SValVisitor expected visit handlers of VisitNonLocXXXXX(nonloc::XXXXX) and VisitLocXXXXX(loc::XXXXX), where I felt that envoding NonLoc and Loc in the name is not necessary as the type of the parameter would select the right overload anyways, so I simplified the naming of those visit functions. The rest of the diff is a lot of times just formatting, because getKind() by nature, frequently appears in switches, which means that the whole switch gets automatically reformatted. I could probably undo the formatting, but I didn't want to deviate from the rule unless explicitly requested. | 2 年前 | |
[analyzer] Let the checkers query upper and lower bounds on symbols (#74141) This commit extends the class SValBuilder with the methods getMinValue() and getMaxValue() to that work like SValBuilder::getKnownValue() but return the minimal/maximal possible value the SVal is not perfectly constrained. This extension of the ConstraintManager API is discussed at: https://discourse.llvm.org/t/expose-the-inferred-range-information-in-warning-messages/75192 As a simple proof-of-concept application of this new API, this commit extends a message from core.BitwiseShift with some range information that reports the assumptions of the analyzer. My main motivation for adding these methods is that I'll also want to use them in ArrayBoundCheckerV2 to make the error messages less awkward, but I'm starting with this simpler and less important usecase because I want to avoid merge conflicts with my other commit https://github.com/llvm/llvm-project/pull/72107 which is currently under review. The testcase too_large_right_operand_compound() shows a situation where querying the range information does not work (and the extra information is not added to the error message). This also affects the debug utility clang_analyzer_value(), so the problem isn't in the fresh code. I'll do some investigations to resolve this, but I think that this commit is a step forward even with this limitation. | 2 年前 | |
[analyzer] Fix crash on using bitcast(<type>, <array>) as array subscript (#101647) Current CSA logic does not expect LazyCompoundValKind as array index. This may happen if array is used as subscript to another, in case of bitcast to integer type. Catch such cases and return UnknownVal, since CSA cannot model array -> int casts. Closes #94496 (cherry picked from commit d96569ecc2807a13dab6495d8cc4e82775b00af1) | 1 年前 | |
[analyzer][NFC] Move away from using raw-for loops inside StaticAnalyzer I'm involved with the Static Analyzer for the most part. I think we should embrace newer language standard features and gradually move forward. Differential Revision: https://reviews.llvm.org/D154325 | 2 年前 | |
[analyzer][NFC] Move away from using raw-for loops inside StaticAnalyzer I'm involved with the Static Analyzer for the most part. I think we should embrace newer language standard features and gradually move forward. Differential Revision: https://reviews.llvm.org/D154325 | 2 年前 | |
Use llvm::less_second (NFC) | 3 年前 | |
Reland "[analyzer] Harden safeguards for Z3 query times" (#97298) This is exactly as originally landed in #95129, but now the minimal Z3 version was increased to meet this change in #96682. https://discourse.llvm.org/t/bump-minimal-z3-requirements-from-4-7-1-to-4-8-9/79664/4 --- This patch is a functional change. https://discourse.llvm.org/t/analyzer-rfc-taming-z3-query-times/79520 As a result of this patch, individual Z3 queries in refutation will be bound by 300ms. Every report equivalence class will be processed in at most 1 second. The heuristic should have only really marginal observable impact - except for the cases when we had big report eqclasses with long-running (15s) Z3 queries, where previously CSA effectively halted. After this patch, CSA will tackle such extreme cases as well. (cherry picked from commit eacc3b3504be061f7334410dd0eb599688ba103a) | 1 年前 |