summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/AnalysisBasedWarnings.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Thread safety analysis: Improve diagnostics for double lockingAaron Puchert2019-01-291-14/+17
| | | | | | | | | | | | | | | | Summary: We use the existing diag::note_locked_here to tell the user where we saw the first locking. Reviewers: aaron.ballman, delesley Reviewed By: aaron.ballman Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D56967 llvm-svn: 352549
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | 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
* [AST] RecursiveASTVisitor visits lambda classes when implicit visitation is on.Sam McCall2019-01-141-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This fixes ASTContext's parent map for nodes in such classes (e.g. operator()). https://bugs.llvm.org/show_bug.cgi?id=39949 This also changes the observed shape of the AST for implicit RAVs. - this includes AST MatchFinder: cxxRecordDecl() now matches lambda classes, functionDecl() matches the call operator, and the parent chain is body -> call operator -> lambda class -> lambdaexpr rather than body -> lambdaexpr. - this appears not to matter for the ASTImporterLookupTable builder - this doesn't matter for the other RAVs in-tree. In order to do this, we remove the TraverseLambdaBody hook. The problem is it's hard/weird to ensure this hook is called when traversing via the implicit class. There were just two users of this hook in-tree, who use it to skip bodies. I replaced these with explicitly traversing the captures only. Another approach would be recording the bodies when the lambda is visited, and then recognizing them later. I'd be open to suggestion on how to preserve this hook, instead. Reviewers: aaron.ballman, JonasToth Subscribers: cfe-commits, rsmith, jdennett Differential Revision: https://reviews.llvm.org/D56444 llvm-svn: 351047
* Revert "Revert r347417 "Re-Reinstate 347294 with a fix for the failures.""Fangrui Song2018-11-301-4/+3
| | | | | | | | | It seems the two failing tests can be simply fixed after r348037 Fix 3 cases in Analysis/builtin-functions.cpp Delete the bad CodeGen/builtin-constant-p.c for now llvm-svn: 348053
* Revert r347417 "Re-Reinstate 347294 with a fix for the failures."Fangrui Song2018-11-301-3/+4
| | | | | | | | | | Kept the "indirect_builtin_constant_p" test case in test/SemaCXX/constant-expression-cxx1y.cpp while we are investigating why the following snippet fails: extern char extern_var; struct { int a; } a = {__builtin_constant_p(extern_var)}; llvm-svn: 348039
* Re-commit r347417 "Re-Reinstate 347294 with a fix for the failures."Hans Wennborg2018-11-281-4/+3
| | | | | | | This was reverted in r347656 due to me thinking it caused a miscompile of Chromium. Turns out it was the Chromium code that was broken. llvm-svn: 347756
* Revert r347417 "Re-Reinstate 347294 with a fix for the failures."Hans Wennborg2018-11-271-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This caused a miscompile in Chrome (see crbug.com/908372) that's illustrated by this small reduction: static bool f(int *a, int *b) { return !__builtin_constant_p(b - a) || (!(b - a)); } int arr[] = {1,2,3}; bool g() { return f(arr, arr + 3); } $ clang -O2 -S -emit-llvm a.cc -o - g() should return true, but after r347417 it became false for some reason. This also reverts the follow-up commits. r347417: > Re-Reinstate 347294 with a fix for the failures. > > Don't try to emit a scalar expression for a non-scalar argument to > __builtin_constant_p(). > > Third time's a charm! r347446: > The result of is.constant() is unsigned. r347480: > A __builtin_constant_p() returns 0 with a function type. r347512: > isEvaluatable() implies a constant context. > > Assume that we're in a constant context if we're asking if the expression can > be compiled into a constant initializer. This fixes the issue where a > __builtin_constant_p() in a compound literal was diagnosed as not being > constant, even though it's always possible to convert the builtin into a > constant. r347531: > A "constexpr" is evaluated in a constant context. Make sure this is reflected > if a __builtin_constant_p() is a part of a constexpr. llvm-svn: 347656
* Re-Reinstate 347294 with a fix for the failures.Bill Wendling2018-11-211-4/+3
| | | | | | | | | Don't try to emit a scalar expression for a non-scalar argument to __builtin_constant_p(). Third time's a charm! llvm-svn: 347417
* Revert r347364 again, the fix was incomplete.Nico Weber2018-11-211-3/+4
| | | | llvm-svn: 347389
* Reinstate 347294 with a fix for the failures.Bill Wendling2018-11-201-4/+3
| | | | | | | EvaluateAsInt() is sometimes called in a constant context. When that's the case, we need to specify it as so. llvm-svn: 347364
* llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)Fangrui Song2018-09-261-1/+1
| | | | | | | | | | | | | | Summary: The convenience wrapper in STLExtras is available since rL342102. Reviewers: rsmith, #clang, dblaikie Reviewed By: rsmith, #clang Subscribers: mgrang, arphaman, kadircet, cfe-commits Differential Revision: https://reviews.llvm.org/D52576 llvm-svn: 343147
* Port getLocEnd -> getEndLocStephen Kelly2018-08-091-7/+7
| | | | | | | | | | Reviewers: teemperor! Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D50351 llvm-svn: 339386
* Port getLocStart -> getBeginLocStephen Kelly2018-08-091-52/+49
| | | | | | | | | | Reviewers: teemperor! Subscribers: jholewinski, whisperity, jfb, cfe-commits Differential Revision: https://reviews.llvm.org/D50350 llvm-svn: 339385
* Use Optional instead of unique_ptr; NFCGeorge Burgess IV2018-08-051-3/+3
| | | | | | | | Looks like the only reason we use a unique_ptr here is so that we can conditionally construct a LogicalErrorHandler. It's a small type, and Optional can do the same thing with 100% fewer heap allocations. llvm-svn: 338962
* Remove trailing spaceFangrui Song2018-07-301-26/+26
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
* Implement cpu_dispatch/cpu_specific MultiversioningErich Keane2018-07-201-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As documented here: https://software.intel.com/en-us/node/682969 and https://software.intel.com/en-us/node/523346. cpu_dispatch multiversioning is an ICC feature that provides for function multiversioning. This feature is implemented with two attributes: First, cpu_specific, which specifies the individual function versions. Second, cpu_dispatch, which specifies the location of the resolver function and the list of resolvable functions. This is valuable since it provides a mechanism where the resolver's TU can be specified in one location, and the individual implementions each in their own translation units. The goal of this patch is to be source-compatible with ICC, so this implementation diverges from the ICC implementation in a few ways: 1- Linux x86/64 only: This implementation uses ifuncs in order to properly dispatch functions. This is is a valuable performance benefit over the ICC implementation. A future patch will be provided to enable this feature on Windows, but it will obviously more closely fit ICC's implementation. 2- CPU Identification functions: ICC uses a set of custom functions to identify the feature list of the host processor. This patch uses the cpu_supports functionality in order to better align with 'target' multiversioning. 1- cpu_dispatch function def/decl: ICC's cpu_dispatch requires that the function marked cpu_dispatch be an empty definition. This patch supports that as well, however declarations are also permitted, since the linker will solve the issue of multiple emissions. Differential Revision: https://reviews.llvm.org/D47474 llvm-svn: 337552
* Change \t to spacesFangrui Song2018-07-201-3/+4
| | | | llvm-svn: 337530
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-091-2/+2
| | | | | | | | | | | | | | | | | | | This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
* Track the result of evaluating a computed noexcept specification on theRichard Smith2018-05-031-1/+1
| | | | | | | | | | | | | | FunctionProtoType. We previously re-evaluated the expression each time we wanted to know whether the type is noexcept or not. We now evaluate the expression exactly once. This is not quite "no functional change": it fixes a crasher bug during AST deserialization where we would try to evaluate the noexcept specification in a situation where we have not deserialized sufficient portions of the AST to permit such evaluation. llvm-svn: 331428
* Fix some handling of AST nodes with diagnostics.Richard Trieu2018-03-281-8/+7
| | | | | | | | | The diagnostic system for Clang can already handle many AST nodes. Instead of converting them to strings first, just hand the AST node directly to the diagnostic system and let it handle the output. Minor changes in some diagnostic output. llvm-svn: 328688
* [clang] Change std::sort to llvm::sort in response to r327219Mandeep Singh Grang2018-03-271-4/+4
| | | | | | | | | | | r327219 added wrappers to std::sort which randomly shuffle the container before sorting. This will help in uncovering non-determinism caused due to undefined sorting order of objects having the same key. To make use of that infrastructure we need to invoke llvm::sort instead of std::sort. llvm-svn: 328636
* Improve -Winfinite-recursionRobert Widmann2018-03-221-47/+24
| | | | | | | | | | | | | | Summary: Rewrites -Winfinite-recursion to remove the state dictionary and explore paths in loops - especially infinite loops. The new check now detects recursion in loop bodies dominated by a recursive call. Reviewers: rsmith, rtrieu Reviewed By: rtrieu Subscribers: lebedev.ri, cfe-commits Differential Revision: https://reviews.llvm.org/D43737 llvm-svn: 328173
* Re-land "[Sema] Make getCurFunction() return null outside function parsing"Reid Kleckner2018-03-121-6/+7
| | | | | | | | | | | | | | This relands r326965. There was a null dereference in typo correction that was triggered in Sema/diagnose_if.c. We are not always in a function scope when doing typo correction. The fix is to add a null check. LLVM's optimizer made it hard to find this bug. I wrote it up in a not-very-well-editted blog post here: http://qinsb.blogspot.com/2018/03/ub-will-delete-your-null-checks.html llvm-svn: 327334
* Revert "[Sema] Make getCurFunction() return null outside function parsing"Reid Kleckner2018-03-081-7/+6
| | | | | | | | | | This reverts r326965. It seems to have caused repeating test failures in clang/test/Sema/diagnose_if.c on some buildbots. I cannot reproduce the problem, and it's not immediately obvious what the problem is, so let's revert to green. llvm-svn: 326974
* [Sema] Make getCurFunction() return null outside function parsingReid Kleckner2018-03-081-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Before this patch, Sema pre-allocated a FunctionScopeInfo and kept it in the first, always present element of the FunctionScopes stack. This meant that Sema::getCurFunction would return a pointer to this pre-allocated object when parsing code outside a function body. This is pretty much always a bug, so this patch moves the pre-allocated object into a separate unique_ptr. This should make bugs like PR36536 a lot more obvious. As you can see from this patch, there were a number of places that unconditionally assumed they were always called inside a function. However, there are also many places that null checked the result of getCurFunction(), so I think this is a reasonable direction. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D44039 llvm-svn: 326965
* [Sema] Fix -Wunused-variableSam McCall2018-02-201-1/+0
| | | | llvm-svn: 325553
* Fix some -Wexceptions false positives.Richard Smith2018-02-201-71/+48
| | | | | | | | | Reimplement the "noexcept function actually throws" warning to properly handle nested try-blocks. In passing, change 'throw;' handling to treat any enclosing try block as being sufficient to suppress the warning rather than requiring a 'catch (...)'; the warning is intended to be conservatively-correct. llvm-svn: 325545
* DR126: partially implement the const-correct rules for exception handler ↵Richard Smith2018-01-131-40/+13
| | | | | | | | | matching. While here, fix up the myriad other ways in which Sema's two "can this handler catch that exception?" implementations get things wrong and unify them. llvm-svn: 322431
* Now that C++17 is official (https://www.iso.org/standard/68564.html), start ↵Aaron Ballman2017-12-041-1/+1
| | | | | | changing the C++1z terminology over to C++17. NFC intended, these are all mechanical changes. llvm-svn: 319688
* Do not perform the analysis based warning if the warnings are ignoredOlivier Goffart2017-11-231-4/+4
| | | | | | | | | | | | | This saves some cycles when compiling with "-w". (Also fix a potential crash on invalid code for tools that tries to recover from some errors, because analysis might compute the CFG which crashes if the code contains invalid declaration. This does not happen normally with because we also don't perform these analysis if there was an error.) Differential Revision: https://reviews.llvm.org/D40242 llvm-svn: 318900
* Enable support for the [[fallthrough]] attribute from WG14 N2052 when ↵Aaron Ballman2017-10-181-8/+7
| | | | | | enabling double square bracket attributes in C code. llvm-svn: 316083
* [CFG] Relax Wexceptions warning on rethrow Erich Keane2017-10-171-3/+3
| | | | | | | | | | | | As reported here: https://bugs.llvm.org/show_bug.cgi?id=34973 "catch(...)" should catch EVERYTHING, even a rethrow. This patch changes the order in which things are checked to ensure that a '...' catch will get a rethrow. Differential Revision: https://reviews.llvm.org/D39013 llvm-svn: 316030
* Replace use of SmallVector::back + pop_back with pop_back_valErich Keane2017-10-171-2/+1
| | | | | | | | | I ran across an instance where the value was being loaded out via back, then immediately popped. Since pop_back_val is more efficient at this (it moves out), replace this instance. llvm-svn: 316015
* [Sema] Corrected the warn-on-throw-from-noexcept behavior to include nothrowErich Keane2017-09-261-1/+1
| | | | | | | | | | Discovered that 'nothrow' (which is supposed to be an alias for noexcept) was not warning with a throw inside of it. This patch corrects the behavior previously created to add 'nothrow' to this list. Differential Revision: https://reviews.llvm.org/D38203 llvm-svn: 314229
* [CSA] [NFC] Move AnalysisContext.h to AnalysisDeclContext.hGeorge Karpenkov2017-09-061-1/+1
| | | | | | | | | | | | | | The implementation is in AnalysisDeclContext.cpp and the class is called AnalysisDeclContext. Making those match up has numerous benefits, including: - Easier jump from header to/from implementation. - Easily identify filename from class. Differential Revision: https://reviews.llvm.org/D37500 llvm-svn: 312671
* Address comments that escaped D33333Erich Keane2017-07-051-7/+12
| | | | | | | | Patch By: Jen Yu Differential Revision:https://reviews.llvm.org/D34671 llvm-svn: 307172
* Fixed -Wexceptions derived-to-base false positivesStephan Bergmann2017-06-291-1/+5
| | | | | | | | | | | | | ...as introduced with recent <https://reviews.llvm.org/D33333> "Emit warning when throw exception in destruct or dealloc functions which has a (possible implicit) noexcept specifier". (The equivalent of the goodReference case hit when building LibreOffice.) (These warnings are apparently only emitted when no errors have yet been encountered, so it didn't work to add the test code to the end of the existing clang/test/SemaCXX/exceptions.cpp.) llvm-svn: 306715
* Emit warning when throw exception in destruct or dealloc functions which has a Erich Keane2017-06-231-0/+150
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (possible implicit) noexcept specifier Throwing in the destructor is not good (C++11 change try to not allow see below). But in reality, those codes are exist. C++11 [class.dtor]p3: A declaration of a destructor that does not have an exception-specification is implicitly considered to have the same exception specification as an implicit declaration. With this change, the application worked before may now run into runtime termination. My goal here is to emit a warning to provide only possible info to where the code may need to be changed. First there is no way, in compile time to identify the “throw” really throw out of the function. Things like the call which throw out… To keep this simple, when “throw” is seen, checking its enclosing function(only destructor and dealloc functions) with noexcept(true) specifier emit warning. Here is implementation detail: A new member function CheckCXXThrowInNonThrowingFunc is added for class Sema in Sema.h. It is used in the call to both BuildCXXThrow and TransformCXXThrowExpr. The function basic check if the enclosing function with non-throwing noexcept specifer, if so emit warning for it. The example of warning message like: k1.cpp:18:3: warning: ''~dependent_warn'' has a (possible implicit) non-throwing noexcept specifier. Throwing exception may cause termination. [-Wthrow-in-dtor] throw 1; ^ k1.cpp:43:30: note: in instantiation of member function 'dependent_warn<noexcept_fun>::~dependent_warn' requested here dependent_warn<noexcept_fun> f; // cause warning Differential Revision: https://reviews.llvm.org/D33333 llvm-svn: 306149
* [coroutines] Fix fallthrough diagnostics for coroutinesEric Fiselier2017-05-251-17/+13
| | | | | | | | | | | | | | | | | | | | Summary: This patch fixes a number of issues with the analysis warnings emitted when a coroutine may reach the end of the function w/o returning. * Fix bug where coroutines with `return_value` are incorrectly diagnosed as missing `co_return`'s. * Rework diagnostic message to no longer say "non-void coroutine", because that implies the coroutine doesn't have a void return type, which it might. In this case a non-void coroutine is one who's promise type does not contain `return_void()` As a side-effect of this patch, coroutine bodies that contain an invalid coroutine promise objects are marked as invalid. Reviewers: GorNishanov, rsmith, aaron.ballman, majnemer Reviewed By: GorNishanov Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D33532 llvm-svn: 303831
* [coroutines] Build GRO declaration and return GRO statementGor Nishanov2017-05-221-1/+5
| | | | | | | | | | | | | | | | | | Summary: 1. build declaration of the gro local variable that keeps the result of get_return_object. 2. build return statement returning the gro variable 3. emit them during CodeGen 4. sema and CodeGen tests updated Reviewers: EricWF, rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D31646 llvm-svn: 303573
* Suppress warning on unreachable [[clang::fallthrough]] within a template ↵Richard Smith2017-03-221-4/+13
| | | | | | | | | | | | | instantiation. We don't know whether some other instantiation of the template might be able to reach the annotation, so warning on it has a high chance of false positives. Patch by Ahmed Asadi! Differential Revision: https://reviews.llvm.org/D31069 llvm-svn: 298477
* Avoid multiple -Wunreachable-code diagnostics that are triggered byAlex Lorenz2017-01-121-0/+10
| | | | | | | | | | | the same source range and use the unary operator fixit only when it actually silences the warning. rdar://24570531 Differential Revision: https://reviews.llvm.org/D28231 llvm-svn: 291757
* [coroutines] Build fallthrough and set_exception statements.Eric Fiselier2016-10-271-12/+43
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds semantic checking and building of the fall-through `co_return;` statement as well as the `p.set_exception(std::current_exception())` call for handling uncaught exceptions. The fall-through statement is built and checked according to: > [dcl.fct.def.coroutine]/4 > The unqualified-ids return_void and return_value are looked up in the scope of class P. If > both are found, the program is ill-formed. If the unqualified-id return_void is found, flowing > off the end of a coroutine is equivalent to a co_return with no operand. Otherwise, flowing off > the end of a coroutine results in undefined behavior. Similarly the `set_exception` call is only built when that unqualified-id is found in the scope of class P. Additionally this patch adds fall-through warnings for non-void returning coroutines. Since it's surprising undefined behavior I thought it would be important to add the warning right away. Reviewers: majnemer, GorNishanov, rsmith Subscribers: mehdi_amini, cfe-commits Differential Revision: https://reviews.llvm.org/D25349 llvm-svn: 285271
* [NFC] Header cleanupMehdi Amini2016-07-181-5/+0
| | | | | | | | | | Summary: Removed unused headers, replaced some headers with forward class declarations Patch by: Eugene <claprix@yandex.ru> Differential Revision: https://reviews.llvm.org/D20100 llvm-svn: 275882
* [PCH/preamble] Make sure that if the preamble/PCH was serialized with errors ↵Argyrios Kyrtzidis2016-07-131-1/+1
| | | | | | | | | | that we set diagnostic engine state appropriately. Otherwise there can be a crash with CFG analysis warnings doing work on invalid AST. Fixes crash of rdar://26224134 llvm-svn: 275313
* Rename a variable to avoid shadowing function parameter. NFC.Bob Wilson2016-05-251-7/+7
| | | | llvm-svn: 270666
* arc-repeated-use-of-weak should not warn about IBOutlet propertiesBob Wilson2016-05-251-0/+6
| | | | | | | | | | | | | | Revision r211132 was supposed to disable -Warc-repeated-use-of-weak for Objective-C properties marked with the IBOutlet attribute. Those properties are supposed to be weak but they are only accessed from the main thread so there is no risk of asynchronous updates setting them to nil. That combination makes -Warc-repeated-use-of-weak very noisy. The previous change only handled one kind of access to weak IBOutlet properties. Instead of trying to add checks for all the different kinds of property accesses, this patch removes the previous special case check and adds a check at the point where the diagnostic is reported. rdar://21366461 llvm-svn: 270665
* Avoid -Wshadow warnings about constructor parameters named after fieldsReid Kleckner2016-04-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Usually these parameters are used solely to initialize the field in the initializer list, and there is no real shadowing confusion. There is a new warning under -Wshadow called -Wshadow-field-in-constructor-modified. It attempts to find modifications of such constructor parameters that probably intended to modify the field. It has some false negatives, though, so there is another warning group, -Wshadow-field-in-constructor, which always warns on this special case. For users who just want the old behavior and don't care about these fine grained groups, we have a new warning group called -Wshadow-all that activates everything. Fixes PR16088. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D18271 llvm-svn: 267957
* P0188R1: add support for standard [[fallthrough]] attribute. This is almostRichard Smith2016-03-081-11/+32
| | | | | | | | | | | | | | exactly the same as clang's existing [[clang::fallthrough]] attribute, which has been updated to have the same semantics. The one significant difference is that [[fallthrough]] is ill-formed if it's not used immediately before a switch label (even when -Wimplicit-fallthrough is disabled). To support that, we now build a CFG of any function that uses a '[[fallthrough]];' statement to check. In passing, fix some bugs with our support for statement attributes -- in particular, diagnose their use on declarations, rather than asserting. llvm-svn: 262881
* [Sema] Replace pointer-to-map with a map. NFC.George Burgess IV2015-12-101-12/+6
| | | | llvm-svn: 255288
OpenPOWER on IntegriCloud