summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* Revert r306103: "PR26195: Set correct NestedNameSpecifierLoc for theAlex Lorenz2017-06-231-9/+0
| | | | | | | | | dependent initializer" It caused buildbot failures such as this one: http://bb.pgr.jp/builders/test-clang-msc-x64-on-i686-linux-RA/builds/3777/steps/test_clang/logs/Clang%20%3A%3A%20Index__ctor-init-source-loc.cpp llvm-svn: 306111
* PR26195: Set correct NestedNameSpecifierLoc for the dependent initializerAlex Lorenz2017-06-231-0/+9
| | | | | | | | | | | | | | | | | | This commit fixes incorrect source positions of dependent c'tor initializers like in the following code: template<typename MyBase> struct Derived: MyBase::InnerIterator { Derived() : MyBase::InnerIterator() {} /// This line is problematic: all positions point to InnerIterator and nothing points to MyBase }; Patch by Serge Preis! Differential Revision: https://reviews.llvm.org/D32439 llvm-svn: 306103
* PR33552: Distinguish between declarations that are owned by no module andRichard Smith2017-06-235-10/+14
| | | | | | | | | | | | | | | | | | | declarations that are owned but unconditionally visible. This allows us to set declarations as visible even if they have a local owning module, without losing information. In turn, that means that our Objective-C support can keep on incorrectly assuming the "hidden" bit on the declaration is the whole story with regard to name visibility. This will also be useful once we support the C++ Modules TS export semantics. Objective-C name visibility is still incorrect in any case where the "hidden" bit is not the complete story: for instance, in Objective-C++ the set of visible categories will be wrong during template instantiation, and with local submodule visibility enabled it will be wrong when building modules. Fixing that will require a major overhaul of how visibility is handled for Objective-C (and particularly for categories). llvm-svn: 306075
* PR33002: When we instantiate the definition of a static data member, we mightRichard Smith2017-06-221-4/+0
| | | | | | | have attached an initializer to the in-class declaration. If so, include the initializer in the update record for the instantiation. llvm-svn: 306065
* [Sema] Add -Wunguarded-availability-newAlex Lorenz2017-06-221-5/+55
| | | | | | | | | | | | | | | The new compiler warning -Wunguarded-availability-new is a subset of -Wunguarded-availability. It is on by default. It only warns about uses of APIs that have been introduced in macOS >= 10.13, iOS >= 11, watchOS >= 4 and tvOS >= 11. We decided to use this kind of solution as we didn't want to turn on -Wunguarded-availability by default, because we didn't want our users to get warnings about uses of old APIs in their existing projects. rdar://31054725 Differential Revision: https://reviews.llvm.org/D34264 llvm-svn: 306033
* Function with unparsed body is a definitionSerge Pavlov2017-06-214-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While a function body is being parsed, the function declaration is not considered as a definition because it does not have a body yet. In some cases it leads to incorrect interpretation, the case is presented in https://bugs.llvm.org/show_bug.cgi?id=14785: ``` template<typename T> struct Somewhat { void internal() const {} friend void operator+(int const &, Somewhat<T> const &) {} }; void operator+(int const &, Somewhat<char> const &x) { x.internal(); } ``` When statement `x.internal()` in the body of global `operator+` is parsed, the type of `x` must be completed, so the instantiation of `Somewhat<char>` is started. It instantiates the declaration of `operator+` defined inline, and makes a check for redefinition. The check does not detect another definition because the declaration of `operator+` is still not defining as does not have a body yet. To solves this problem the function `isThisDeclarationADefinition` considers a function declaration as a definition if it has flag `WillHaveBody` set. This change fixes PR14785. Differential Revision: https://reviews.llvm.org/D30375 This is a recommit of 305379, reverted in 305381, with small changes. llvm-svn: 305903
* Prevent devirtualization of calls to un-instantiated functions.Sunil Srivastava2017-06-203-0/+8
| | | | | | | | PR 27895 Differential Revision: https://reviews.llvm.org/D22057 llvm-svn: 305862
* Fix for Bug 33471: Preventing operator auto from resolving to a template ↵Erich Keane2017-06-201-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | operator. As the bug report says, struct A { template<typename T> operator T(); }; void foo() { A().operator auto(); } causes: "undeduced type in IR-generation UNREACHABLE executed at llvm/tools/clang/lib/CodeGen/CodeGenFunction.cpp:208!" The problem is that in this case, "T" is being deduced as "auto", which I believe is incorrect. The 'operator auto' implementation in Clang is standards compliant, however there is a defect report against core (1670). Differential Revision: https://reviews.llvm.org/D34370 llvm-svn: 305812
* [OpenCL] Diagnose scoped address-space qualified variablesAnastasia Stulova2017-06-201-2/+16
| | | | | | | | | | | | Produce an error if variables qualified with a local or a constant address space are not declared in the outermost scope of a kernel. Patch by Simon Perretta. Differential Revision: https://reviews.llvm.org/D34024 llvm-svn: 305798
* [XRay][clang] Support capturing the implicit `this` argument to C++ class ↵Dean Michael Berris2017-06-161-6/+8
| | | | | | | | | | | | | | | | | | member functions Summary: Before this change, we couldn't capture the `this` pointer that's implicitly the first argument of class member functions. There are some interesting things we can do with capturing even just this single argument for zero-argument member functions. Reviewers: rnk, pelikan Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D34052 llvm-svn: 305544
* [Completion] Code complete the members for a dependent type after a '::'Alex Lorenz2017-06-151-3/+7
| | | | | | | | | | This commit is a follow up to r302797 which added support for dependent completions after the '.' and '->' operators. This commit adds support for dependent completions after the '::' operator. Differential Revision: https://reviews.llvm.org/D34173 llvm-svn: 305511
* [coroutines] Remove pass-through operator co_await; Replace it with the ↵Eric Fiselier2017-06-151-1/+7
| | | | | | | | | | | | input expression Reviewers: GorNishanov, rsmith Reviewed By: GorNishanov Differential Revision: https://reviews.llvm.org/D34216 llvm-svn: 305498
* Reverted 305379 (Function with unparsed body is a definition)Serge Pavlov2017-06-144-10/+7
| | | | | | It broke clang-x86_64-linux-selfhost-modules-2 and some other buildbots. llvm-svn: 305381
* Function with unparsed body is a definitionSerge Pavlov2017-06-144-7/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | While a function body is being parsed, the function declaration is not considered as a definition because it does not have a body yet. In some cases it leads to incorrect interpretation, the case is presented in https://bugs.llvm.org/show_bug.cgi?id=14785: ``` template<typename T> struct Somewhat { void internal() const {} friend void operator+(int const &, Somewhat<T> const &) {} }; void operator+(int const &, Somewhat<char> const &x) { x.internal(); } ``` When statement `x.internal()` in the body of global `operator+` is parsed, the type of `x` must be completed, so the instantiation of `Somewhat<char>` is started. It instantiates the declaration of `operator+` defined inline, and makes a check for redefinition. The check does not detect another definition because the declaration of `operator+` is still not defining as does not have a body yet. To solves this problem the function `isThisDeclarationADefinition` considers a function declaration as a definition if it has flag `WillHaveBody` set. This change fixes PR14785. Differential Revision: https://reviews.llvm.org/D30375 llvm-svn: 305379
* [coroutines] Fix co_await for range statementEric Fiselier2017-06-142-37/+50
| | | | | | | | | | | | | | | | | Summary: Currently we build the co_await expressions on the wrong implicit statements of the implicit ranged for; Specifically we build the co_await expression wrapping the range declaration, but it should wrap the begin expression. This patch fixes co_await on range for. Reviewers: rsmith, GorNishanov Reviewed By: GorNishanov Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D34021 llvm-svn: 305363
* Fix spurious Wunused-lambda-capture warningYi Kong2017-06-131-5/+11
| | | | | | | | | | | | | | | | | Summary: Clang emits unused-lambda-capture warning for captures in generic lambdas even though they are actually used. Fixes PR31815. Reviewers: malcolm.parsons, aaron.ballman, rsmith Reviewed By: malcolm.parsons Subscribers: ahatanak, cfe-commits Differential Revision: https://reviews.llvm.org/D33526 llvm-svn: 305315
* Revert "Revert r301742 which made ExprConstant checking apply to all ↵Diana Picus2017-06-131-23/+1
| | | | | | | | | full-exprs." This reverts commit r305239 because it broke the buildbots (the diag-flags.cpp test is failing). llvm-svn: 305287
* Revert r301742 which made ExprConstant checking apply to all full-exprs.Nick Lewycky2017-06-121-1/+23
| | | | | | This patch also exposed pre-existing bugs in clang, see PR32864 and PR33140#c3 . llvm-svn: 305239
* [Sema][C++1z] Ensure binding in dependent range for have non-null typeErik Pilkington2017-06-121-1/+5
| | | | | | | | Fixes PR32172 Differential revision: https://reviews.llvm.org/D34096 llvm-svn: 305195
* Don't crash when forming a destructor name on an incomplete type.John McCall2017-06-111-3/+6
| | | | | | | | Fixes PR25156. Patch by Don Hinton! llvm-svn: 305169
* Revert "[clang] Implement -Wcast-qual for C++"Roman Lebedev2017-06-101-70/+24
| | | | | | Breaks -Werror builders. llvm-svn: 305148
* [clang] Implement -Wcast-qual for C++Roman Lebedev2017-06-101-24/+70
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This way, the behavior of that warning flag more closely resembles that of GCC. Do note that there is at least one false-negative (see FIXME in tests). Fixes PR4802. Testing: ``` ninja check-clang-sema check-clang-semacxx ``` Reviewers: dblaikie, majnemer, rnk Reviewed By: dblaikie, rnk Subscribers: cfe-commits, alexfh, rnk Differential Revision: https://reviews.llvm.org/D33102 llvm-svn: 305147
* 27037: Use correct CVR qualifier on an upcast on method pointer callRichard Smith2017-06-091-1/+3
| | | | | | | | Patch by Taiju Tsuiki! Differential Revision: https://reviews.llvm.org/D33875 llvm-svn: 305126
* [modules] Fix that global delete operator get's assigned to a submodule.Vassil Vassilev2017-06-091-0/+2
| | | | | | | | | | | | | | | n the current local-submodule-visibility mode, as soon as we discover a virtual destructor, we declare on demand a global delete operator. However, this causes that this delete operator is owned by the submodule which contains said virtual destructor. This means that other modules no longer can see the global delete operator which is hidden inside another submodule and fail to compile. This patch unhides those global allocation function once they're created to prevent this issue. Patch by Raphael Isemann (D33366)! llvm-svn: 305118
* [DebugInfo] Add kind of ImplicitParamDecl for emission of FlagObjectPointer.Alexey Bataev2017-06-091-8/+12
| | | | | | | | | | | | | | | | | Summary: If the first parameter of the function is the ImplicitParamDecl, codegen automatically marks it as an implicit argument with `this` or `self` pointer. Added internal kind of the ImplicitParamDecl to separate 'this', 'self', 'vtt' and other implicit parameters from other kind of parameters. Reviewers: rjmccall, aaron.ballman Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D33735 llvm-svn: 305075
* [Sema] Refactor OverloadCandidate::BuiltinTypes. NFC.George Burgess IV2017-06-082-22/+20
| | | | | | As promised in r304996. llvm-svn: 305013
* Added llvm_unreachable to make sure the switch is always exhaustive.Galina Kistanova2017-06-081-0/+1
| | | | llvm-svn: 304997
* [Sema] Remove unused field from OverloadCandidate.George Burgess IV2017-06-081-144/+50
| | | | | | | | | | | | | | | | | | The only use in-tree I can find for BuiltinTypes.ResultTy is a single store to it. We otherwise just recompute what it should be later on (and sometimes do things like argument conversions in the process of recomputing it). Since it's impossible to test if the value stored there is sane, and we don't use it anyway, we should probably just drop the field. I'll do a follow-up patch to rename BuiltinTypes.ParamTypes -> BuiltinParamTypes in a bit. Wanted to keep this patch relatively minimal. Thanks to Petr Kudryavtsev for bringing this up! llvm-svn: 304996
* Do not inherit default arguments for friend function in class template.Serge Pavlov2017-06-081-11/+17
| | | | | | | | | | | | | | | | | | | A function declared in a friend declaration may have declarations prior to the containing class definition. If such declaration defines default argument, the friend function declaration inherits them. This behavior causes problems if the class where the friend is declared is a template: during the class instantiation the friend function looks like if it had default arguments, so error is triggered. With this change friend functions declared in class templates do not inherit default arguments. Actual set of them will be defined at the point where the containing class is instantiated. This change fixes PR12724. Differential Revision: https://reviews.llvm.org/D30393 llvm-svn: 304965
* Improve diagnostics if friend function redefines file-level function.Serge Pavlov2017-06-081-1/+6
| | | | | | | | | | | | | | | | | | | | | | Clang makes check for function redefinition after it merged the new declaration with the existing one. As a result, it produces poor diagnostics in the case of a friend function defined inline, as in the code: ``` void func() {} class C { friend void func() {} }; ``` Error message in this case states that `inline declaration of 'func' follows non-inline definition`, which is misleading, as `func` does not have explicit `inline` specifier. With this changes compiler reports function redefinition if the new function is a friend defined inline and it does not have explicit `inline` specifier. Differential Revision: https://reviews.llvm.org/D26065 llvm-svn: 304964
* Catch invalid bitwise operation on vector of floatsSerge Pavlov2017-06-081-10/+7
| | | | | | | | | | | | Bitwise complement applied to vector of floats described with attribute `ext_vector_type` is not diagnosed as error. Attempt to compile such construct causes assertion violation in Instruction.cpp. With this change the complement is treated similar to the case of vector type described with attribute `vector_size`. Differential Revision: https://reviews.llvm.org/D33732 llvm-svn: 304963
* Simplify.Richard Smith2017-06-081-8/+4
| | | | llvm-svn: 304960
* Weaken restriction in r304862 to allow implicit deduction guides to referenceRichard Smith2017-06-081-4/+6
| | | | | | | the injected-class-name of a specialization that uses a partial / explicit specialization. llvm-svn: 304957
* When determining the target function of an explicit instantiation, makeJohn McCall2017-06-071-19/+25
| | | | | | | | | | sure that non-template functions don't end up in the candidate set. Fixes PR14211. Patch by Don Hinton! llvm-svn: 304951
* [c++1z] Support deducing B in noexcept(B).Richard Smith2017-06-072-38/+100
| | | | | | | | This is not required by the standard (yet), but there seems to be reasonable support for this being a defect according to CWG discussion, and libstdc++ 7.1 relies on it working. llvm-svn: 304946
* [Sema] Silence unused variable warning.Benjamin Kramer2017-06-071-1/+1
| | | | llvm-svn: 304892
* Added LLVM_FALLTHROUGH to address warning: this statement may fall through. NFC.Galina Kistanova2017-06-071-0/+1
| | | | llvm-svn: 304872
* Added LLVM_FALLTHROUGH to address warning: this statement may fall through. NFC.Galina Kistanova2017-06-071-0/+3
| | | | llvm-svn: 304870
* Fix a couple of class template argument deduction crashes with libc++'s tuple.Richard Smith2017-06-072-1/+34
| | | | | | | | | | | | | | | | RecursiveASTVisitor was not properly recursing through a SubstTemplateTypeParmTypes, resulting in crashes in pack expansion where we couldn't always find an unexpanded pack within a pack expansion. We also have an issue where substitution of deduced template arguments for an implicit deduction guide creates the "impossible" case of naming a non-dependent member of the current instantiation, but within a specialization that is actually instantiated from a different (partial/explicit) specialization of the template. We resolve this by declaring that constructors that do so can only be used to deduce specializations of the primary template. I'm running this past CWG to see if people agree this is the right thing to do. llvm-svn: 304862
* Improve error recovery for missing 'template' keyword in contexts where theRichard Smith2017-06-071-0/+26
| | | | | | | | | | | | | | template is valid with or without it (with different meanings). If we see "dependent.x<...", and what follows the '<' is a valid expression, we must parse the '<' as a comparison rather than a template angle bracket. When we later come to instantiate, if we find that the LHS of the '<' actually names an overload set containing function templates, produce a diagnostic suggesting that the 'template' keyword was missed rather than producing a mysterious diagnostic saying that the function must be called (and pointing at what looks to already be a function call!). llvm-svn: 304852
* [clang] Remove double semicolons. NFC.Mandeep Singh Grang2017-06-061-1/+1
| | | | | | | | | | | | | | Reviewers: rsmith, craig.topper, efriedma Reviewed By: efriedma Subscribers: efriedma, cfe-commits Tags: #clang-c Differential Revision: https://reviews.llvm.org/D33926 llvm-svn: 304823
* PR33318: Add missing full-expression checking to static_assert expression.Richard Smith2017-06-061-0/+8
| | | | | | | This fixes missing lambda-captures for variables referenced only inside a static_assert (!), among other things. llvm-svn: 304760
* Fix crash when an 'import a module' TypoCorrection has its CorrectionDeclsRichard Smith2017-06-051-7/+6
| | | | | | | | | | | | replaced by visible decls. Make sure that all paths through checkCorrectionVisibility set the RequiresImport flag appropriately, so we don't end up using a stale value. Patch by Jorge Gorbe! Differential Revision: https://reviews.llvm.org/D30963 llvm-svn: 304745
* Add support for #pragma clang sectionJaved Absar2017-06-052-0/+55
| | | | | | | | | | | | | | | This patch provides a means to specify section-names for global variables, functions and static variables, using #pragma directives. This feature is only defined to work sensibly for ELF targets. One can specify section names as: #pragma clang section bss="myBSS" data="myData" rodata="myRodata" text="myText" One can "unspecify" a section name with empty string e.g. #pragma clang section bss="" data="" text="" rodata="" Reviewers: Roger Ferrer, Jonathan Roelofs, Reid Kleckner Differential Revision: https://reviews.llvm.org/D33412 llvm-svn: 304705
* Added LLVM_FALLTHROUGH to address warning: this statement may fall through. NFC.Galina Kistanova2017-06-039-0/+12
| | | | llvm-svn: 304651
* [coroutines] Fix rebuilding of dependent coroutine parametersEric Fiselier2017-06-033-9/+15
| | | | | | | | | | | | | | | | Summary: We were not handling correctly rebuilding of parameter and were not creating copies for them. Now we will always rebuild parameter moves in TreeTransform's TransformCoroutineBodyStmt. Reviewers: rsmith, GorNishanov Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D33797 llvm-svn: 304620
* Fix assertion failure if we can't deduce a template argument for a variableRichard Smith2017-06-021-1/+2
| | | | | | | | | | | | template partial specialization. In passing, fix the deduction-crash.cpp test to actually run all the tests. Due to a typo, the last third of the file was being skipped by the parser and some of the tests were not actually testing anything as a result. Switch from FileCheck to -verify to make the problem more obvious and prevent this happening again. llvm-svn: 304604
* [OpenCL] Harden function pointer diagnostics.Alexey Bader2017-06-022-1/+6
| | | | | | | | | | | | | | Summary: Improve OpenCL type checking by rejecting function pointer types. Reviewers: Anastasia, yaxunl Reviewed By: Anastasia Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D33821 llvm-svn: 304575
* Minor fixes to for-loop warning.Richard Trieu2017-06-021-29/+22
| | | | | | | | | | | | | The warning for unchanged loop variables outputted a diagnostic that was dependent on iteration order from a pointer set, which is not always deterministic. Switch to a set vector, which allows fast querying and preserves ordering. Also make other minor changes in this area. Use more range-based for-loops. Remove limitation on SourceRanges that no logner exists. llvm-svn: 304519
OpenPOWER on IntegriCloud