| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[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 年前 | |
[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][NFC] Take SVal and NonLoc by value | 2 年前 | |
Fix the warning in RefCntblBaseVirtualDtorChecker.cpp:61 (#93403) | 2 年前 | |
[clang][analyzer] Move checker 'cert.pos.34c' (in alpha.security) into 'PutenvStackArray' (#92424) The "cert" package looks not useful and the checker has not a meaningful name with the old naming scheme. Additionally tests and documentation is updated. | 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] Enable constructor support in evalCall event. Pass EvalCallOptions via runCheckersForEvalCall into defaultEvalCall. Update the AnalysisOrderChecker to support evalCall for testing. Differential Revision: https://reviews.llvm.org/D82256 | 5 年前 | |
[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] 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] 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 年前 | |
[analyzer] Use CDM::CLibrary instead of isGlobalCFunction() (#88267) This commit updates several checkers to use call descriptions with the matching mode CDM::CLibrary instead of checking Call.isGlobalCFunction() after performing the match. This resolves several TODOs in various checkers. Note that both matching with CDM::CLibrary and calling isGlobalCFunction leads to CheckerContext::isCLibraryFunction() checks (so this change is close to being NFC), but if it is used via the matching mode then the checker can automatically recognize the builtin variants of the matched functions. I'll also make similar changes in GenericTaintChecker, but that checker has separate and inconsistent rules for handling the normal and the builtin variant of several functions (e.g. memcpy and __builtin_memcpy), so I'll put those changes into a separate commit. | 2 年前 | |
[analyzer][NFC] Simplify BugType handling in core.BitwiseShift (#74609) Eliminate the mutable unique_ptr hack because it's no longer needed. (This cleanup could be done anywhere, I'm doing it here now because it was me who published this checker with the old hack when it was already superfluous.) | 2 年前 | |
[analyzer] Restore recognition of mutex methods (#101511) Before commit 705788c the checker alpha.unix.BlockInCriticalSection "recognized" the methods std::mutex::lock and std::mutex::unlock with an extremely trivial check that accepted any function (or method) named lock/unlock. To avoid matching unrelated user-defined function, this was refined to a check that also requires the presence of "std" and "mutex" as distinct parts of the qualified name. However, as #99628 reported, there are standard library implementations where some methods of std::mutex are inherited from an implementation detail base class and the new code wasn't able to recognize these methods, which led to emitting false positive reports. As a workaround, this commit partially restores the old behavior by omitting the check for the class name. In the future, it would be good to replace this hack with a solution which ensures that CallDescription understands inherited methods. (cherry picked from commit 99ae2edc2592e602b0eb5a287f4d003aa3902440) | 1 年前 | |
[clang][analyzer] Reformat code of BoolAssignmentChecker (NFC). (#81461) This is only a code reformatting and rename of variables to the newer format. | 2 年前 | |
[analyzer] Model builtin-like functions as builtin functions (#99886) Some template function instantiations don't have a body, even though their templates did have a body. Examples are: std::move, std::forward, std::addressof etc. They had bodies before https://github.com/llvm/llvm-project/commit/72315d02c432a0fe0acae9c96c69eac8d8e1a9f6 After that change, the sentiment was that these special functions should be considered and treated as builtin functions. Fixes #94193 CPP-5358 | 1 年前 | |
[analyzer] Finish moving alpha.core.SizeofPtr to clang-tidy (#95118) The checker alpha.core.SizeofPtr was a very simple checker that did not rely on path sensitive analysis and was very similar to the (more complex and refined) clang-tidy check bugprone-sizeof-expression. As there is no reason to maintain two separate implementations for the same goal (and clang-tidy is more lightweight and accessible than the Analyzer) I decided to move this functionality from the Static Analyzer to clang-tidy. Recently my commit 546c816a529835a4cf89deecff957ea336a94fa2 reimplemented the advantageous parts of alpha.core.SizeofPtr within clang-tidy; now this commit finishes the transfer by deleting alpha.core.SizeofPtr. | 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 年前 | |
[analyzer][NFC] Change LangOptions to CheckerManager in the shouldRegister* functions Some checkers may not only depend on language options but also analyzer options. To make this possible this patch changes the parameter of the shouldRegister* function to CheckerManager to be able to query the analyzer options when deciding whether the checker should be registered. Differential Revision: https://reviews.llvm.org/D75271 | 6 年前 | |
[clang][analyzer] Bring cplusplus.ArrayDelete out of alpha (#83985) The checker finds a type of undefined behavior, where if the type of a pointer to an object-array is different from the objects' underlying type, calling delete[] is undefined, as the size of the two objects might be different. The checker has been in alpha for a while now, it is a simple checker that causes no crashes, and considering the severity of the issue, it has a low result-count on open-source projects (in my last test-run on my usual projects, it had 0 results). This commit cleans up the documentation and adds docs for the limitation related to tracking through references, in addition to moving it to cplusplus. --------- Co-authored-by: Balazs Benics <benicsbalazs@gmail.com> Co-authored-by: whisperity <whisperity@gmail.com> | 2 年前 | |
[analyzer][NFC] Change LangOptions to CheckerManager in the shouldRegister* functions Some checkers may not only depend on language options but also analyzer options. To make this possible this patch changes the parameter of the shouldRegister* function to CheckerManager to be able to query the analyzer options when deciding whether the checker should be registered. Differential Revision: https://reviews.llvm.org/D75271 | 6 年前 | |
[analyzer][NFC] Take SVal and NonLoc by value | 2 年前 | |
[NFC] Refactor ConstantArrayType size storage (#85716) In PR #79382, I need to add a new type that derives from ConstantArrayType. This means that ConstantArrayType can no longer use llvm::TrailingObjects to store the trailing optional Expr*. This change refactors ConstantArrayType to store a 60-bit integer and 4-bits for the integer size in bytes. This replaces the APInt field previously in the type but preserves enough information to recreate it where needed. To reduce the number of places where the APInt is re-constructed I've also added some helper methods to the ConstantArrayType to allow some common use cases that operate on either the stored small integer or the APInt as appropriate. Resolves #85124. | 2 年前 | |
[analyzer][NFC] Change LangOptions to CheckerManager in the shouldRegister* functions Some checkers may not only depend on language options but also analyzer options. To make this possible this patch changes the parameter of the shouldRegister* function to CheckerManager to be able to query the analyzer options when deciding whether the checker should be registered. Differential Revision: https://reviews.llvm.org/D75271 | 6 年前 | |
[analyzer] Use explicit call description mode (easy cases) (#88879) This commit explicitly specifies the matching mode (C library function, any non-method function, or C++ method) for the CallDescriptions constructed in various checkers where this transition was easy and straightforward. This change won't cause major functional changes, but isn't NFC because it ensures that e.g. call descriptions for a non-method function won't accidentally match a method that has the same name. Separate commits will perform (or have already performed) this change in other checkers. My goal is to ensure that the call description mode is always explicitly specified and eliminate (or strongly restrict) the vague "may be either a method or a simple function" mode that's the current default. | 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 年前 | |
[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 年前 | |
[analyzer] DynamicSize: Rename 'size' to 'extent' | 5 年前 | |
[clang] Upstream XROS support in Clang (#78392) Upstream XROS support in the clang frontend and driver. | 2 年前 | |
| 2 年前 | ||
[analyzer] Use explicit call description mode (easy cases) (#88879) This commit explicitly specifies the matching mode (C library function, any non-method function, or C++ method) for the CallDescriptions constructed in various checkers where this transition was easy and straightforward. This change won't cause major functional changes, but isn't NFC because it ensures that e.g. call descriptions for a non-method function won't accidentally match a method that has the same name. Separate commits will perform (or have already performed) this change in other checkers. My goal is to ensure that the call description mode is always explicitly specified and eliminate (or strongly restrict) the vague "may be either a method or a simple function" mode that's the current default. | 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] Use explicit call description mode in iterator checkers (#88913) This commit explicitly specifies the matching mode (C library function, any non-method function, or C++ method) for the CallDescriptions constructed in the iterator/container checkers. This change won't cause major functional changes, but isn't NFC because it ensures that e.g. call descriptions for a non-method function won't accidentally match a method that has the same name. Separate commits will perform (or have already performed) this change in other checkers. My goal is to ensure that the call description mode is always explicitly specified and eliminate (or strongly restrict) the vague "may be either a method or a simple function" mode that's the current default. I'm handling the iterator checkers in this separate commit because they're infamously complex; but I don't expect any trouble because this transition doesn't interact with the "central" logic of iterator handling. | 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 年前 | |
[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] Remove useless class BuiltinBug ...because it provides no useful functionality compared to its base class BugType. A long time ago there were substantial differences between BugType and BuiltinBug, but they were eliminated by commit 1bd58233 in 2009 (!). Since then the only functionality provided by BuiltinBug was that it specified categories::LogicError as the bug category and it stored an extra data member desc. This commit sets categories::LogicError as the default value of the third argument (bug category) in the constructors of BugType and replaces use of the desc field with simpler logic. Note that BugType has a data member Description and a non-virtual method BugType::getDescription() which queries it; these are distinct from the member desc of BuiltinBug and the identically named method BuiltinBug::getDescription() which queries it. This confusing name collision was a major motivation for the elimination of BuiltinBug. As this commit touches many files, I avoided functional changes and left behind FIXME notes to mark minor issues that should be fixed later. Differential Revision: https://reviews.llvm.org/D158855 | 2 年前 | |
[analyzer] Use explicit call description mode in iterator checkers (#88913) This commit explicitly specifies the matching mode (C library function, any non-method function, or C++ method) for the CallDescriptions constructed in the iterator/container checkers. This change won't cause major functional changes, but isn't NFC because it ensures that e.g. call descriptions for a non-method function won't accidentally match a method that has the same name. Separate commits will perform (or have already performed) this change in other checkers. My goal is to ensure that the call description mode is always explicitly specified and eliminate (or strongly restrict) the vague "may be either a method or a simple function" mode that's the current default. I'm handling the iterator checkers in this separate commit because they're infamously complex; but I don't expect any trouble because this transition doesn't interact with the "central" logic of iterator handling. | 2 年前 | |
[analyzer] Use explicit call description mode in iterator checkers (#88913) This commit explicitly specifies the matching mode (C library function, any non-method function, or C++ method) for the CallDescriptions constructed in the iterator/container checkers. This change won't cause major functional changes, but isn't NFC because it ensures that e.g. call descriptions for a non-method function won't accidentally match a method that has the same name. Separate commits will perform (or have already performed) this change in other checkers. My goal is to ensure that the call description mode is always explicitly specified and eliminate (or strongly restrict) the vague "may be either a method or a simple function" mode that's the current default. I'm handling the iterator checkers in this separate commit because they're infamously complex; but I don't expect any trouble because this transition doesn't interact with the "central" logic of iterator handling. | 2 年前 | |
| 2 年前 | ||
[clang][NFC] Trim license header comments to 81 characters (#82919) clang-format would format these headers poorly by splitting it into multiple lines. | 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] 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 年前 | |
[clang][NFC] Refactor CXXConstructExpr::ConstructionKind This patch converts CXXConstructExpr::ConstructionKind into a scoped enum in namespace scope, making it eligible for forward declaring. This is useful in cases like annotating bit-fields with preferred_type. | 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] Refactor recognition of the errno getter functions (#91531) There are many environments where errno is a macro that expands to something like (*__errno()) (different standard library implementations use different names instead of "__errno"). In these environments the ErrnoModeling checker creates a symbolic region which will be used to represent the return value of this "get the location of errno" function. Previously this symbol was only created when the checker was able to find the declaration of the "get the location of errno" function; but this commit eliminates the complex logic that was responsible for this and always creates the symbolic region when errno is not available as a "regular" global variable. This significantly simplifies a code and only introduces a minimal performance reduction (one extra symbol) in the case when errno is not declared (neither as a variable nor as a function). In addition to this simplification, this commit specifies that the CallDescriptions for the "get the location of errno" functions are matched in CDM::CLibrary mode. (This was my original goal, but I was sidetracked by resolving a FIXME above the CallDescriptionSet in ErrnoModeling.cpp.) This change is very close to being NFC, but it fixes weird corner cases like the handling of a C++ method that happens to be named "__errno()" (previously it could've been recognized as an errno location getter function). | 2 年前 | |
[analyzer] Refactor recognition of the errno getter functions (#91531) There are many environments where errno is a macro that expands to something like (*__errno()) (different standard library implementations use different names instead of "__errno"). In these environments the ErrnoModeling checker creates a symbolic region which will be used to represent the return value of this "get the location of errno" function. Previously this symbol was only created when the checker was able to find the declaration of the "get the location of errno" function; but this commit eliminates the complex logic that was responsible for this and always creates the symbolic region when errno is not available as a "regular" global variable. This significantly simplifies a code and only introduces a minimal performance reduction (one extra symbol) in the case when errno is not declared (neither as a variable nor as a function). In addition to this simplification, this commit specifies that the CallDescriptions for the "get the location of errno" functions are matched in CDM::CLibrary mode. (This was my original goal, but I was sidetracked by resolving a FIXME above the CallDescriptionSet in ErrnoModeling.cpp.) This change is very close to being NFC, but it fixes weird corner cases like the handling of a C++ method that happens to be named "__errno()" (previously it could've been recognized as an errno location getter function). | 2 年前 | |
[analyzer] Refactor recognition of the errno getter functions (#91531) There are many environments where errno is a macro that expands to something like (*__errno()) (different standard library implementations use different names instead of "__errno"). In these environments the ErrnoModeling checker creates a symbolic region which will be used to represent the return value of this "get the location of errno" function. Previously this symbol was only created when the checker was able to find the declaration of the "get the location of errno" function; but this commit eliminates the complex logic that was responsible for this and always creates the symbolic region when errno is not available as a "regular" global variable. This significantly simplifies a code and only introduces a minimal performance reduction (one extra symbol) in the case when errno is not declared (neither as a variable nor as a function). In addition to this simplification, this commit specifies that the CallDescriptions for the "get the location of errno" functions are matched in CDM::CLibrary mode. (This was my original goal, but I was sidetracked by resolving a FIXME above the CallDescriptionSet in ErrnoModeling.cpp.) This change is very close to being NFC, but it fixes weird corner cases like the handling of a C++ method that happens to be named "__errno()" (previously it could've been recognized as an errno location getter function). | 2 年前 | |
[analyzer] Use explicit call description mode (easy cases) (#88879) This commit explicitly specifies the matching mode (C library function, any non-method function, or C++ method) for the CallDescriptions constructed in various checkers where this transition was easy and straightforward. This change won't cause major functional changes, but isn't NFC because it ensures that e.g. call descriptions for a non-method function won't accidentally match a method that has the same name. Separate commits will perform (or have already performed) this change in other checkers. My goal is to ensure that the call description mode is always explicitly specified and eliminate (or strongly restrict) the vague "may be either a method or a simple function" mode that's the current default. | 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] 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 年前 | |
[NFC] Remove unused variables declared in conditions D152495 makes clang warn on unused variables that are declared in conditions like if (int var = init) {} This patch is an NFC fix to suppress the new warning in llvm,clang,lld builds to pass CI in the above patch. Differential Revision: https://reviews.llvm.org/D158016 | 2 年前 | |
[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 年前 | |
[StaticAnalyzer] Modernize GTestChecker (NFC) | 2 年前 | |
[analyzer] Split TaintPropagation checker into reporting and modeling checkers (#98157) Taint propagation is a a generic modeling feature of the Clang Static Analyzer which many other checkers depend on. Therefore GenericTaintChecker is split into a TaintPropagation modeling checker and a GenericTaint reporting checker. | 1 年前 | |
[NFC] Generalize ArraySections to work for OpenACC in the future (#89639) OpenACC is going to need an array sections implementation that is a simpler version/more restrictive version of the OpenMP version. This patch moves OMPArraySectionExpr to Expr.h and renames it ArraySectionExpr, then adds an enum to choose between the two. This also fixes a couple of 'drive-by' issues that I discovered on the way, but leaves the OpenACC Sema parts reasonably unimplemented (no semantic analysis implementation), as that will be a followup patch. | 2 年前 | |
[analyzer] Use explicit call description mode in more checkers (#90974) This commit explicitly specifies the matching mode (C library function, any non-method function, or C++ method) for the CallDescriptions constructed in various checkers. Some code was simplified to use CallDescriptionSets instead of individual CallDescriptions. This change won't cause major functional changes, but isn't NFC because it ensures that e.g. call descriptions for a non-method function won't accidentally match a method that has the same name. Separate commits have already performed this change in other checkers: - easy cases: e2f1cbae45f81f3cd9a4d3c2bcf69a094eb060fa - MallocChecker: d6d84b5d1448e4f2e24b467a0abcf42fe9d543e9 - iterator checkers: 06eedffe0d2782922e63cc25cb927f4acdaf7b30 - InvalidPtr checker: 024281d4d26344f9613b9115ea1fcbdbdba23235 ... and follow-up commits will handle the remaining checkers. My goal is to ensure that the call description mode is always explicitly specified and eliminate (or strongly restrict) the vague "may be either a method or a simple function" mode that's the current default. | 2 年前 | |
[analyzer][MallocChecker][NFC] Communicate the allocation family to auxiliary functions with parameters The following series of refactoring patches aim to fix the horrible mess that MallocChecker.cpp is. I genuinely hate this file. It goes completely against how most of the checkers are implemented, its by far the biggest headache regarding checker dependencies, checker options, or anything you can imagine. On top of all that, its just bad code. Its seriously everything that you shouldn't do in C++, or any other language really. Bad variable/class names, in/out parameters... Apologies, rant over. So: there are a variety of memory manipulating function this checker models. One aspect of these functions is their AllocationFamily, which we use to distinguish between allocation kinds, like using free() on an object allocated by operator new. However, since we always know which function we're actually modeling, in fact we know it compile time, there is no need to use tricks to retrieve this information out of thin air n+1 function calls down the line. This patch changes many methods of MallocChecker to take a non-optional AllocationFamily template parameter (which also makes stack dumps a bit nicer!), and removes some no longer needed auxiliary functions. Differential Revision: https://reviews.llvm.org/D68162 | 6 年前 | |
[NFC] Fix various unintentional //namespace formatting | 2 年前 | |
[analyzer][NFC] Take SVal and NonLoc by value | 2 年前 | |
[analyzer][NFC] Take SVal and NonLoc by value | 2 年前 | |
[analyzer] Use explicit call description mode in iterator checkers (#88913) This commit explicitly specifies the matching mode (C library function, any non-method function, or C++ method) for the CallDescriptions constructed in the iterator/container checkers. This change won't cause major functional changes, but isn't NFC because it ensures that e.g. call descriptions for a non-method function won't accidentally match a method that has the same name. Separate commits will perform (or have already performed) this change in other checkers. My goal is to ensure that the call description mode is always explicitly specified and eliminate (or strongly restrict) the vague "may be either a method or a simple function" mode that's the current default. I'm handling the iterator checkers in this separate commit because they're infamously complex; but I don't expect any trouble because this transition doesn't interact with the "central" logic of iterator handling. | 2 年前 | |
[analyzer] Use explicit call description mode in iterator checkers (#88913) This commit explicitly specifies the matching mode (C library function, any non-method function, or C++ method) for the CallDescriptions constructed in the iterator/container checkers. This change won't cause major functional changes, but isn't NFC because it ensures that e.g. call descriptions for a non-method function won't accidentally match a method that has the same name. Separate commits will perform (or have already performed) this change in other checkers. My goal is to ensure that the call description mode is always explicitly specified and eliminate (or strongly restrict) the vague "may be either a method or a simple function" mode that's the current default. I'm handling the iterator checkers in this separate commit because they're infamously complex; but I don't expect any trouble because this transition doesn't interact with the "central" logic of iterator handling. | 2 年前 | |
[StaticAnalyzer] Modernize InvalidationInfo (NFC) | 2 年前 | |
[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] 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 年前 | |
[analyzer] Use explicit call description mode in MIGChecker (#91331) This commit explicitly specifies the matching mode (C library function, any non-method function, or C++ method) for the CallDescriptions constructed in the checker osx.MIG. The code was simplified to use a CallDescriptionMap instead of a raw vector of pairs. This change won't cause major functional changes, but isn't NFC because it ensures that e.g. call descriptions for a non-method function won't accidentally match a method that has the same name. Separate commits have already performed this change in other checkers: - easy cases: e2f1cbae45f81f3cd9a4d3c2bcf69a094eb060fa, 6d64f8e1feee014e72730a78b62d9d415df112ff - MallocChecker: d6d84b5d1448e4f2e24b467a0abcf42fe9d543e9 - iterator checkers: 06eedffe0d2782922e63cc25cb927f4acdaf7b30 - InvalidPtr checker: 024281d4d26344f9613b9115ea1fcbdbdba23235 - apiModeling.llvm.ReturnValue: 97dd8e3c4f38ef345b01fbbf0a2052c7875ff7e0 ... and follow-up commits will handle the remaining few checkers. My goal is to ensure that the call description mode is always explicitly specified and eliminate (or strongly restrict) the vague "may be either a method or a simple function" mode that's the current default. | 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] 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] Factor out NoOwnershipChangeVisitor (#94357) In preparation for adding essentially the same visitor to StreamChecker, this patch factors this visitor out to a common header. I'll be the first to admit that the interface of these classes are not terrific, but it rather tightly held back by its main technical debt, which is NoStoreFuncVisitor, the main descendant of NoStateChangeVisitor. Change-Id: I99d73ccd93a18dd145bbbc83afadbb432dd42b90 | 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 年前 | |
[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] Take SVal and NonLoc by value | 2 年前 | |
[analyzer] Use explicit call description mode (easy cases) (#88879) This commit explicitly specifies the matching mode (C library function, any non-method function, or C++ method) for the CallDescriptions constructed in various checkers where this transition was easy and straightforward. This change won't cause major functional changes, but isn't NFC because it ensures that e.g. call descriptions for a non-method function won't accidentally match a method that has the same name. Separate commits will perform (or have already performed) this change in other checkers. My goal is to ensure that the call description mode is always explicitly specified and eliminate (or strongly restrict) the vague "may be either a method or a simple function" mode that's the current default. | 2 年前 | |
[analyzer] PR41269: Add a bit of C++ smart pointer modeling. Implement cplusplus.SmartPtrModeling, a new checker that doesn't emit any warnings but models methods of smart pointers more precisely. For now the only thing it does is make (bool) P return false when P is a freshly moved pointer. This addresses a false positive in the use-after-move-checker. Differential Revision: https://reviews.llvm.org/D60796 llvm-svn: 358944 | 7 年前 | |
[analyzer] Fix crash in MoveChecker when it tries to report duplicate issue The 'MoveChecker' was missing the check if the error node was successfully generated (non-null value was returned). This happens if duplicate of the report is emitted. This patch contains NFC, where 'reportBug' is renamed to 'tryReportBug', to better indicate conditional behavior of function. Author: Arseniy Zaostrovnykh <arseniy.zaostrovnykh@sonarsource.com> Reviewed By: xazax.hun Differential Revision: https://reviews.llvm.org/D155084 | 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 年前 | |
[StaticAnalyzer] Modernize NSErrorMethodChecker (NFC) | 2 年前 | |
[analyzer] Add an ownership change visitor to StreamChecker (#94957) This is very similar to https://reviews.llvm.org/D105553, in fact, I barely made any changes from MallocChecker's ownership visitor to this one. The new visitor emits a diagnostic note for function where a change in stream ownership was expected (for example, it had a fclose() call), but the ownership remained unchanged. This is similar to messages regarding ordinary values ("Returning without writing to x"). | 1 年前 | |
[analyzer][NFC] Factor out NoOwnershipChangeVisitor (#94357) In preparation for adding essentially the same visitor to StreamChecker, this patch factors this visitor out to a common header. I'll be the first to admit that the interface of these classes are not terrific, but it rather tightly held back by its main technical debt, which is NoStoreFuncVisitor, the main descendant of NoStateChangeVisitor. Change-Id: I99d73ccd93a18dd145bbbc83afadbb432dd42b90 | 2 年前 | |
Fix false positive related to handling of [[noreturn]] function pointers Before this change, the NoReturnFunctionChecker was missing function pointers with a [[noreturn]] attribute, while CFG was constructed taking that into account, which leads CSA to take impossible paths. The reason was that the NoReturnFunctionChecker was looking for the attribute in the type of the entire call expression rather than the type of the function being called. This change makes the [[noreturn]] attribute of a function pointer visible to NoReturnFunctionChecker. This leads to a more coherent behavior of the CSA on the AST involving. Reviewed By: xazax.hun Differential Revision: https://reviews.llvm.org/D135682 | 3 年前 | |
[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 年前 | |
[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 年前 | |
[NFC][Clang] Improve const correctness for IdentifierInfo (#79365) The IdentifierInfo isn't typically modified. Use 'const' wherever possible. | 2 年前 | |
[clang] Implement ElaboratedType sugaring for types written bare Without this patch, clang will not wrap in an ElaboratedType node types written without a keyword and nested name qualifier, which goes against the intent that we should produce an AST which retains enough details to recover how things are written. The lack of this sugar is incompatible with the intent of the type printer default policy, which is to print types as written, but to fall back and print them fully qualified when they are desugared. An ElaboratedTypeLoc without keyword / NNS uses no storage by itself, but still requires pointer alignment due to pre-existing bug in the TypeLoc buffer handling. --- Troubleshooting list to deal with any breakage seen with this patch: 1) The most likely effect one would see by this patch is a change in how a type is printed. The type printer will, by design and default, print types as written. There are customization options there, but not that many, and they mainly apply to how to print a type that we somehow failed to track how it was written. This patch fixes a problem where we failed to distinguish between a type that was written without any elaborated-type qualifiers, such as a 'struct'/'class' tags and name spacifiers such as 'std::', and one that has been stripped of any 'metadata' that identifies such, the so called canonical types. Example: namespace foo { struct A {}; A a; }; If one were to print the type of foo::a, prior to this patch, this would result in foo::A. This is how the type printer would have, by default, printed the canonical type of A as well. As soon as you add any name qualifiers to A, the type printer would suddenly start accurately printing the type as written. This patch will make it print it accurately even when written without qualifiers, so we will just print A for the initial example, as the user did not really write that foo:: namespace qualifier. 2) This patch could expose a bug in some AST matcher. Matching types is harder to get right when there is sugar involved. For example, if you want to match a type against being a pointer to some type A, then you have to account for getting a type that is sugar for a pointer to A, or being a pointer to sugar to A, or both! Usually you would get the second part wrong, and this would work for a very simple test where you don't use any name qualifiers, but you would discover is broken when you do. The usual fix is to either use the matcher which strips sugar, which is annoying to use as for example if you match an N level pointer, you have to put N+1 such matchers in there, beginning to end and between all those levels. But in a lot of cases, if the property you want to match is present in the canonical type, it's easier and faster to just match on that... This goes with what is said in 1), if you want to match against the name of a type, and you want the name string to be something stable, perhaps matching on the name of the canonical type is the better choice. 3) This patch could expose a bug in how you get the source range of some TypeLoc. For some reason, a lot of code is using getLocalSourceRange(), which only looks at the given TypeLoc node. This patch introduces a new, and more common TypeLoc node which contains no source locations on itself. This is not an inovation here, and some other, more rare TypeLoc nodes could also have this property, but if you use getLocalSourceRange on them, it's not going to return any valid locations, because it doesn't have any. The right fix here is to always use getSourceRange() or getBeginLoc/getEndLoc which will dive into the inner TypeLoc to get the source range if it doesn't find it on the top level one. You can use getLocalSourceRange if you are really into micro-optimizations and you have some outside knowledge that the TypeLocs you are dealing with will always include some source location. 4) Exposed a bug somewhere in the use of the normal clang type class API, where you have some type, you want to see if that type is some particular kind, you try a dyn_cast such as dyn_cast<TypedefType> and that fails because now you have an ElaboratedType which has a TypeDefType inside of it, which is what you wanted to match. Again, like 2), this would usually have been tested poorly with some simple tests with no qualifications, and would have been broken had there been any other kind of type sugar, be it an ElaboratedType or a TemplateSpecializationType or a SubstTemplateParmType. The usual fix here is to use getAs instead of dyn_cast, which will look deeper into the type. Or use getAsAdjusted when dealing with TypeLocs. For some reason the API is inconsistent there and on TypeLocs getAs behaves like a dyn_cast. 5) It could be a bug in this patch perhaps. Let me know if you need any help! Signed-off-by: Matheus Izvekov <mizvekov@gmail.com> Differential Revision: https://reviews.llvm.org/D112374 | 3 年前 | |
[analyzer] Support allocClassWithName in OSObjectCStyleCast checker allocClassWithName allocates an object with the given type. The type is actually provided as a string argument (type's name). This creates a possibility for not particularly useful warnings from the analyzer. In order to combat with those, this patch checks for casts of the allocClassWithName results to types mentioned directly as its argument. All other uses of this method should be reasoned about as before. rdar://72165694 Differential Revision: https://reviews.llvm.org/D99500 | 5 年前 | |
[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 年前 | |
[clang][NFC] Trim license header comments to 81 characters (#82919) clang-format would format these headers poorly by splitting it into multiple lines. | 2 年前 | |
[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] 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 年前 | |
[NFC][Clang] Improve const correctness for IdentifierInfo (#79365) The IdentifierInfo isn't typically modified. Use 'const' wherever possible. | 2 年前 | |
[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 年前 | |
[NFC][Clang] Improve const correctness for IdentifierInfo (#79365) The IdentifierInfo isn't typically modified. Use 'const' wherever possible. | 2 年前 | |
[clang][NFC] Fix FieldDecl::isUnnamedBitfield() capitalization (#89048) We always capitalize bitfield as "BitField". | 2 年前 | |
[NFC] Refactor ConstantArrayType size storage (#85716) In PR #79382, I need to add a new type that derives from ConstantArrayType. This means that ConstantArrayType can no longer use llvm::TrailingObjects to store the trailing optional Expr*. This change refactors ConstantArrayType to store a 60-bit integer and 4-bits for the integer size in bytes. This replaces the APInt field previously in the type but preserves enough information to recreate it where needed. To reduce the number of places where the APInt is re-constructed I've also added some helper methods to the ConstantArrayType to allow some common use cases that operate on either the stored small integer or the APInt as appropriate. Resolves #85124. | 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] Change LangOptions to CheckerManager in the shouldRegister* functions Some checkers may not only depend on language options but also analyzer options. To make this possible this patch changes the parameter of the shouldRegister* function to CheckerManager to be able to query the analyzer options when deciding whether the checker should be registered. Differential Revision: https://reviews.llvm.org/D75271 | 6 年前 | |
Add some explicit use of TK_AsIs | 5 年前 | |
[clang][analyzer] Add notes to PointerSubChecker (#95899) Notes are added to indicate the array declarations of the arrays in a found invalid pointer subtraction. | 1 年前 | |
[analyzer] Use CDM::CLibrary instead of isGlobalCFunction() (#88267) This commit updates several checkers to use call descriptions with the matching mode CDM::CLibrary instead of checking Call.isGlobalCFunction() after performing the match. This resolves several TODOs in various checkers. Note that both matching with CDM::CLibrary and calling isGlobalCFunction leads to CheckerContext::isCLibraryFunction() checks (so this change is close to being NFC), but if it is used via the matching mode then the checker can automatically recognize the builtin variants of the matched functions. I'll also make similar changes in GenericTaintChecker, but that checker has separate and inconsistent rules for handling the normal and the builtin variant of several functions (e.g. memcpy and __builtin_memcpy), so I'll put those changes into a separate commit. | 2 年前 | |
[clang][analyzer] PutenvStackArrayChecker: No warning from 'main' (#93299) | 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] 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] Clean up apiModeling.llvm.ReturnValue (#91231) This commit heavily refactors and simplifies the small and trivial checker apiModeling.llvm.ReturnValue, which is responsible for modeling the peculiar coding convention that in the LLVM/Clang codebase certain Error() methods always return true. Changes included in this commit: - The call description mode is now specified explicitly (this is not the most significant change, but it was the original reason for touching this checker). - Previously the code provided support for modeling functions that always return false; but there was no need for that, so this commit hardcodes that the return value is true. - The overcomplicated constraint/state handling logic was simplified. - The separate checkEndFunction callback was removed to simplify the code. Admittedly this means that the note tag for the "<method> returns false, breaking the convention" case is placed on the method call instead of the return statement; but that case will _never_ appear in practice, so this difference is mostly academical. - The text of the note tags was clarified. - The descriptions in the header comment and Checkers.td were clarified. - Some minor cleanup was applied in the associated test file. This change is very close to NFC because it only affects a hidden apiModeling.llvm checker that's only relevant during the analysis of the LLVM/Clang codebase, and even there it doesn't affect the normal behavior of the checker. | 2 年前 | |
Correct Doxygen syntax for inline code There is no syntax like {@code ...} in Doxygen, @code is a block command that ends with @endcode, and generally these are not enclosed in braces. The correct syntax for inline code snippets is @c <code>. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D98665 | 5 年前 | |
[analyzer] Use explicit call description mode in iterator checkers (#88913) This commit explicitly specifies the matching mode (C library function, any non-method function, or C++ method) for the CallDescriptions constructed in the iterator/container checkers. This change won't cause major functional changes, but isn't NFC because it ensures that e.g. call descriptions for a non-method function won't accidentally match a method that has the same name. Separate commits will perform (or have already performed) this change in other checkers. My goal is to ensure that the call description mode is always explicitly specified and eliminate (or strongly restrict) the vague "may be either a method or a simple function" mode that's the current default. I'm handling the iterator checkers in this separate commit because they're infamously complex; but I don't expect any trouble because this transition doesn't interact with the "central" logic of iterator handling. | 2 年前 | |
[clang][analyzer] Add checker 'security.SetgidSetuidOrder' (#91445) | 2 年前 | |
[analyzer] Use CDM::CLibrary instead of isGlobalCFunction() (#88267) This commit updates several checkers to use call descriptions with the matching mode CDM::CLibrary instead of checking Call.isGlobalCFunction() after performing the match. This resolves several TODOs in various checkers. Note that both matching with CDM::CLibrary and calling isGlobalCFunction leads to CheckerContext::isCLibraryFunction() checks (so this change is close to being NFC), but if it is used via the matching mode then the checker can automatically recognize the builtin variants of the matched functions. I'll also make similar changes in GenericTaintChecker, but that checker has separate and inconsistent rules for handling the normal and the builtin variant of several functions (e.g. memcpy and __builtin_memcpy), so I'll put those changes into a separate commit. | 2 年前 | |
[StaticAnalyzer] Remove redundant declaration isStdSmartPtr (NFC) An identical declaration is present just a couple of lines above the line being removed in this patch. Identified with readability-redundant-declaration. | 4 年前 | |
[Analyzer] Support note tags for smart ptr checker Summary: Added support for note tags for null smart_ptr reporting Reviewers: NoQ, Szelethus, vsavchenko, xazax.hun Reviewed By: NoQ, vsavchenko, xazax.hun Subscribers: martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D84600 | 5 年前 | |
[analyzer] Use explicit call description mode in more checkers (#90974) This commit explicitly specifies the matching mode (C library function, any non-method function, or C++ method) for the CallDescriptions constructed in various checkers. Some code was simplified to use CallDescriptionSets instead of individual CallDescriptions. This change won't cause major functional changes, but isn't NFC because it ensures that e.g. call descriptions for a non-method function won't accidentally match a method that has the same name. Separate commits have already performed this change in other checkers: - easy cases: e2f1cbae45f81f3cd9a4d3c2bcf69a094eb060fa - MallocChecker: d6d84b5d1448e4f2e24b467a0abcf42fe9d543e9 - iterator checkers: 06eedffe0d2782922e63cc25cb927f4acdaf7b30 - InvalidPtr checker: 024281d4d26344f9613b9115ea1fcbdbdba23235 ... and follow-up commits will handle the remaining checkers. My goal is to ensure that the call description mode is always explicitly specified and eliminate (or strongly restrict) the vague "may be either a method or a simple function" mode that's the current default. | 2 年前 | |
[analyzer] Fix StackAddrEscapeChecker crash on temporary object fields (#66493) Basically, the issue was that we should have unwrapped the base region before we special handle temp object regions. Fixes https://github.com/llvm/llvm-project/issues/66221 I also decided to add some extra range information to the diagnostics to make it consistent with the other reporting path. | 2 年前 | |
| 1 年前 | ||
[analyzer] Use explicit call description mode (easy cases) (#88879) This commit explicitly specifies the matching mode (C library function, any non-method function, or C++ method) for the CallDescriptions constructed in various checkers where this transition was easy and straightforward. This change won't cause major functional changes, but isn't NFC because it ensures that e.g. call descriptions for a non-method function won't accidentally match a method that has the same name. Separate commits will perform (or have already performed) this change in other checkers. My goal is to ensure that the call description mode is always explicitly specified and eliminate (or strongly restrict) the vague "may be either a method or a simple function" mode that's the current default. | 2 年前 | |
[analyzer] Fix crash in Stream checker when using void pointers (#97199) We can get zero type size (thus div by zero crash) if the region is for a 'void*' pointer. In this patch, let's just override the void type with a char type to avoid the crash. Fixes https://github.com/llvm/llvm-project/pull/93408#issuecomment-2189766510 | 1 年前 | |
[analyzer] Use explicit call description mode (easy cases) (#88879) This commit explicitly specifies the matching mode (C library function, any non-method function, or C++ method) for the CallDescriptions constructed in various checkers where this transition was easy and straightforward. This change won't cause major functional changes, but isn't NFC because it ensures that e.g. call descriptions for a non-method function won't accidentally match a method that has the same name. Separate commits will perform (or have already performed) this change in other checkers. My goal is to ensure that the call description mode is always explicitly specified and eliminate (or strongly restrict) the vague "may be either a method or a simple function" mode that's the current default. | 2 年前 | |
[analyzer] Remove superfluous #include "CallDescription.h" (NFC) (#82614) To fix https://github.com/llvm/llvm-project/issues/81597, I'm planning to refactor the usage of CallDescription; and as I was preparing for this I noticed that there are two superfluous references to this header. | 2 年前 | |
[analyzer] Limit isTainted() by skipping complicated symbols (#105493) As discussed in https://discourse.llvm.org/t/rfc-make-istainted-and-complex-symbols-friends/79570/10 Some isTainted() queries can blow up the analysis times, and effectively halt the analysis under specific workloads. We don't really have the time now to do a caching re-implementation of isTainted(), so we need to workaround the case. The workaround with the smallest blast radius was to limit what symbols isTainted() does the query (by walking the SymExpr). So far, the threshold 10 worked for us, but this value can be overridden using the "max-tainted-symbol-complexity" config value. This new option is "deprecated" from the getgo, as I expect this issue to be fixed within the next few months and I don't want users to override this value anyways. If they do, this message will let them know that they are on their own, and the next release may break them (as we no longer recognize this option if we drop it). Mitigates #89720 CPP-5414 (cherry picked from commit 848658955a9d2d42ea3e319d191e2dcd5d76c837) | 1 年前 | |
[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] 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] Change LangOptions to CheckerManager in the shouldRegister* functions Some checkers may not only depend on language options but also analyzer options. To make this possible this patch changes the parameter of the shouldRegister* function to CheckerManager to be able to query the analyzer options when deciding whether the checker should be registered. Differential Revision: https://reviews.llvm.org/D75271 | 6 年前 | |
[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] Add support for __attribute__((returns_nonnull)). Differential Revision: https://reviews.llvm.org/D118657 | 4 年前 | |
[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] 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] 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] 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] 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] Warn if the size of the array in new[] is undefined This patch introduces a new checker, called NewArraySize checker, which detects if the expression that yields the element count of the array in new[], results in an Undefined value. Differential Revision: https://reviews.llvm.org/D131299 | 3 年前 | |
[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 年前 | |
| 2 年前 | ||
[analyzer] Fix core.VLASize checker false positive taint reports (#68140) The checker reported a false positive on this code void testTaintedSanitizedVLASize(void) { int x; scanf("%d", &x); if (x<1) return; int vla[x]; // no-warning } After the fix, the checker only emits tainted warning if the vla size is coming from a tainted source and it cannot prove that it is positive. | 2 年前 | |
[analyzer] Use CDM::CLibrary instead of isGlobalCFunction() (#88267) This commit updates several checkers to use call descriptions with the matching mode CDM::CLibrary instead of checking Call.isGlobalCFunction() after performing the match. This resolves several TODOs in various checkers. Note that both matching with CDM::CLibrary and calling isGlobalCFunction leads to CheckerContext::isCLibraryFunction() checks (so this change is close to being NFC), but if it is used via the matching mode then the checker can automatically recognize the builtin variants of the matched functions. I'll also make similar changes in GenericTaintChecker, but that checker has separate and inconsistent rules for handling the normal and the builtin variant of several functions (e.g. memcpy and __builtin_memcpy), so I'll put those changes into a separate commit. | 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 年前 | |
[Clang][NFC] Rename CXXMethodDecl::isPure -> is VirtualPure (#78463) To avoid any possible confusion with the notion of pure function and the gnu::pure attribute. | 2 年前 | |
[NFC] Remove unused variables declared in conditions D152495 makes clang warn on unused variables that are declared in conditions like if (int var = init) {} This patch is an NFC fix to suppress the new warning in llvm,clang,lld builds to pass CI in the above patch. Differential Revision: https://reviews.llvm.org/D158016 | 2 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 2 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 7 年前 | ||
| 5 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 6 年前 | ||
| 2 年前 | ||
| 6 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 6 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 4 年前 | ||
| 5 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 6 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 7 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 5 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 6 年前 | ||
| 5 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 5 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 4 年前 | ||
| 5 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 6 年前 | ||
| 2 年前 | ||
| 4 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 |