summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema
Commit message (Collapse)AuthorAgeFilesLines
...
* [ObjC] Pick a 'readwrite' property when synthesizing ambiguousAlex Lorenz2017-07-131-27/+160
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | property and check for incompatible attributes This commit changes the way ambiguous property synthesis (i.e. when synthesizing a property that's declared in multiple protocols) is performed. Previously, Clang synthesized the first property that was found. This lead to problems when the property was synthesized in a class that conformed to two protocols that declared that property and a second protocols had a 'readwrite' declaration - the setter was not synthesized so the class didn't really conform to the second protocol and user's code would crash at runtime when they would try to set the property. This commit ensures that a first readwrite property is selected. This is a semantic change that changes users code in this manner: ``` @protocol P @property(readonly) int p; @end @protocol P2 @property(readwrite) id p; @end @interface I <P2> @end @implementation I @syntesize p; // Users previously got a warning here, and Clang synthesized // readonly 'int p' here. Now Clang synthesizes readwrite 'id' p.. @end ``` To ensure that this change is safe, the warning about incompatible types is promoted to an error when this kind of readonly/readwrite ambiguity is detected in the @implementation. This will ensure that previous code that had this subtle bug and ignored the warning now will fail to compile with an error, and users should not get suprises at runtime once they resolve the error. The commit also extends the ambiguity checker, and now it can detect conflicts among the different property attributes. An error diagnostic is used for conflicting attributes, to ensure that the user won't get "suprises" at runtime. ProtocolPropertyMap is removed in favour of a a set + vector because the map's order of iteration is non-deterministic, so it couldn't be used to select the readwrite property. rdar://31579994 Differential Revision: https://reviews.llvm.org/D35268 llvm-svn: 307903
* [Sema] Mark a virtual CXXMethodDecl as used if a call to it can beAkira Hatanaka2017-07-132-20/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | devirtualized. The code to detect devirtualized calls is already in IRGen, so move the code to lib/AST and make it a shared utility between Sema and IRGen. This commit fixes a linkage error I was seeing when compiling the following code: $ cat test1.cpp struct Base { virtual void operator()() {} }; template<class T> struct Derived final : Base { void operator()() override {} }; Derived<int> *d; int main() { if (d) (*d)(); return 0; } rdar://problem/33195657 Differential Revision: https://reviews.llvm.org/D34301 llvm-svn: 307883
* [OPENMP] Skip BuildMemberExpr() in BuildFieldReferenceExpr(), NFC, by Kai NodaAlexey Bataev2017-07-111-5/+4
| | | | | | | | | In the OpenMP mode, we don't need to call BuildMemberExpr() only to discard its return value. BuildDeclRefExpr() is called instead. Differential revision: https://reviews.llvm.org/D35201 llvm-svn: 307697
* [OPENMP] Add restriction for reduction clause in taskloop directives.Alexey Bataev2017-07-111-0/+43
| | | | | | | | Added checks for the reduction clauses in the taskloop directives: 1. Only addressable items must be used in reduction clauses. 2. Reduction clauses cannot be used with nogroup clauses. llvm-svn: 307693
* [ObjC] Check that a subscript methods is declared for a qualified id typeAlex Lorenz2017-07-111-7/+2
| | | | | | | | | | | | Objective-C subscript expressions report errors when a subscript method is not declared in the base class. However, prior to this commit, qualified id types were not checked. This commit ensures that an appropriate error is reported when a subscript method is not declared in any of the protocols that are included in the qualified id type. rdar://33213924 llvm-svn: 307642
* Remove incorrect FIXME comment; the FIXME was addressed before the changes ↵Eric Fiselier2017-07-101-2/+0
| | | | | | were committed llvm-svn: 307515
* Remove non-ascii characters introduced in r307513Eric Fiselier2017-07-101-4/+4
| | | | llvm-svn: 307514
* [coroutines] Include the implicit object parameter type when looking up ↵Eric Fiselier2017-07-101-15/+39
| | | | | | | | | coroutine_traits for member functions. This patch was originally from Toby Allsopp, but I hijacked it and fixed it up with his permission. llvm-svn: 307513
* [MS] Don't statically initialize dllimport member function pointersReid Kleckner2017-07-071-40/+40
| | | | | | | | | | | | | | | | | | | | Summary: r306137 made dllimport pointers to member functions non-constant. This is correct because a load must be executed to resolve any dllimported data. However, r306137 did not account for the use of dllimport member function pointers used as template arguments. This change re-lands r306137 with a template instantiation fix. This fixes PR33570. Reviewers: rnk, majnemer Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D34714 llvm-svn: 307446
* Fix crash parsing invalid codeOlivier Goffart2017-07-071-0/+2
| | | | | | | | | | | | | | | | | | | | | The code in the test caused a crash with this backtrace: RecordLayoutBuilder.cpp:2934: const clang::ASTRecordLayout &clang::ASTContext::getASTRecordLayout(const clang::RecordDecl *) const: Assertion `!D->isInvalidDecl() && "Cannot get layout of invalid decl!"' failed. [...] #7 0x00007f63963d845a __assert_fail_base (/usr/lib/libc.so.6+0x2c45a) #8 0x00007f63963d84d2 (/usr/lib/libc.so.6+0x2c4d2) #9 0x00007f63937a0631 clang::ASTContext::getASTRecordLayout(clang::RecordDecl const*) const /home/olivier/prog/llvm/tools/clang/lib/AST/RecordLayoutBuilder.cpp:2935:3 #10 0x00007f63937a1ad5 getFieldOffset(clang::ASTContext const&, clang::FieldDecl const*) /home/olivier/prog/llvm/tools/clang/lib/AST/RecordLayoutBuilder.cpp:3057:37 #11 0x00007f6391869f14 clang::Sema::RefersToMemberWithReducedAlignment(clang::Expr*, llvm::function_ref<void (clang::Expr*, clang::RecordDecl*, clang::FieldDecl*, clang::CharUnits)>) /home/olivier/prog/llvm/tools/clang/lib/Sema/SemaChecking.cpp:12139:23 #12 0x00007f639186a2f8 clang::Sema::CheckAddressOfPackedMember(clang::Expr*) /home/olivier/prog/llvm/tools/clang/lib/Sema/SemaChecking.cpp:12190:1 #13 0x00007f6391a7a81c clang::Sema::CheckAddressOfOperand(clang::ActionResult<clang::Expr*, true>&, clang::SourceLocation) /home/olivier/prog/llvm/tools/clang/lib/Sema/SemaExpr.cpp:11111:10 #14 0x00007f6391a7f5d2 clang::Sema::CreateBuiltinUnaryOp(clang::SourceLocation, clang::UnaryOperatorKind, clang::Expr*) /home/olivier/prog/llvm/tools/clang/lib/Sema/SemaExpr.cpp:11932:18 Fixing by bailing out for invalid classes. Differential Revision: https://reviews.llvm.org/D35108 llvm-svn: 307371
* [ObjC] Avoid the -Wunguarded-availability warnings for protocolAlex Lorenz2017-07-072-4/+12
| | | | | | | | | | | | | | | requirements in protocol/class/category declarations The unguarded availability warnings in the protocol requirements of a protocol /class/category declaration can be avoided. This matches the behaviour of Swift's diagnostics. The warnings for deprecated/unavailable protocols are preserved. rdar://33156429 Differential Revision: https://reviews.llvm.org/D35061 llvm-svn: 307368
* Fix test case in pre-C++11 mode; address Aaron Ballman's code review.Douglas Gregor2017-07-051-2/+2
| | | | llvm-svn: 307202
* Cope with Range-v3's CONCEPT_REQUIRES idiomDouglas Gregor2017-07-051-0/+34
| | | | llvm-svn: 307197
* Customize the SFINAE diagnostics for enable_if to provide the failed condition.Douglas Gregor2017-07-052-7/+140
| | | | | | | | | | | | | | | | | | | | When enable_if disables a particular overload resolution candidate, rummage through the enable_if condition to find the specific condition that caused the failure. For example, if we have something like: template< typename Iter, typename = std::enable_if_t<Random_access_iterator<Iter> && Comparable<Iterator_value_type<Iter>>>> void mysort(Iter first, Iter last) {} and we call "mysort" with "std::list<int>" iterators, we'll get a diagnostic saying that the "Random_access_iterator<Iter>" requirement failed. If we call "mysort" with "std::vector<something_not_comparable>", we'll get a diagnostic saying that the "Comparable<...>" requirement failed. llvm-svn: 307196
* [Sema] Don't allow -Wunguarded-availability to be silenced with redeclsErik Pilkington2017-07-053-104/+114
| | | | | | Differential revision: https://reviews.llvm.org/D33816 llvm-svn: 307175
* Address comments that escaped D33333Erich Keane2017-07-051-7/+12
| | | | | | | | Patch By: Jen Yu Differential Revision:https://reviews.llvm.org/D34671 llvm-svn: 307172
* [modules ts] Improve merging of module-private declarations.Richard Smith2017-07-051-32/+60
| | | | | | | | | | These cases occur frequently for declarations in the global module (above the module-declaration) in a Modules TS module interface. When we merge a definition from another module into such a module-private definition, ensure that we transitively make everything lexically within that definition visible to that translation unit. llvm-svn: 307129
* fix trivial typos in comments; NFCHiroshi Inoue2017-07-051-1/+1
| | | | llvm-svn: 307123
* [modules ts] Declarations from a module interface unit are only visible outsideRichard Smith2017-07-053-18/+57
| | | | | | the module if declared in an export block. llvm-svn: 307115
* [OpenCL] Rename err_opencl_enqueue_kernel_expected_typeJoey Gouly2017-07-041-15/+18
| | | | | | | | | Rename err_opencl_enqueue_kernel_expected_type so that other builtins can use the same diagnostic. https://reviews.llvm.org/D34948 llvm-svn: 307067
* [Sema] Make BreakContinueFinder handle nested loops.Eli Friedman2017-07-041-6/+61
| | | | | | | | | | | | We don't care about break or continue statements that aren't associated with the current loop, so make sure the visitor doesn't find them. Fixes https://bugs.llvm.org/show_bug.cgi?id=32648 . Differential Revision: https://reviews.llvm.org/D34568 llvm-svn: 307051
* [clang] Implement -Wcast-qual for C++Roman Lebedev2017-07-031-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: mclow.lists, cfe-commits, alexfh, rnk Differential Revision: https://reviews.llvm.org/D33102 llvm-svn: 307045
* Add a fixit for -Wobjc-protocol-property-synthesisAlex Lorenz2017-07-031-4/+10
| | | | | | | | rdar://32132756 Differential Revision: https://reviews.llvm.org/D34886 llvm-svn: 307014
* [modules] Teach clang how to merge typedef over anonymous structs in C mode.Vassil Vassilev2017-07-011-3/+2
| | | | | | | | | | In C mode clang fails to merge the textually included definition with the one imported from a module. The C lookup rules fail to find the imported definition because its linkage is internal in non C++ mode. This patch reinstates some of the ODR merging rules for typedefs of anonymous tags for languages other than C++. Patch by Raphael Isemann and me (D34510). llvm-svn: 306964
* [OpenMP] Fix mapping of scalars for combined directivesJonas Hahnfeld2017-07-011-3/+26
| | | | | | | | | | | | | | | | Combined directives like 'target parallel' have two captured statements. Sema has to check the right one from the right direction. Previously, Sema::IsOpenMPCapturedByRef would return false for mapped scalars on combined directives. This results in a wrong signature of the outlined function which triggers an assertion: void llvm::CallInst::init(llvm::FunctionType *, llvm::Value *, ArrayRef<llvm::Value *>, ArrayRef<OperandBundleDef>, const llvm::Twine &): Assertion `(i >= FTy->getNumParams() || FTy->getParamType(i) == Args[i]->getType()) && "Calling a function with a bad signature!"' failed. Fixes PR30975 (and PR31985). New function was taken from clang-ykt. Differential Revision: https://reviews.llvm.org/D34888 llvm-svn: 306956
* fix trivial typos; NFCHiroshi Inoue2017-07-011-1/+1
| | | | llvm-svn: 306954
* [Modules] Implement ODR-like semantics for tag types in C/ObjCBruno Cardoso Lopes2017-07-012-6/+92
| | | | | | | | | | | | | | | | | | | | | | Allow ODR for ObjC/C in the sense that we won't keep more that one definition around (merge them). However, ensure the decl pass the structural compatibility check in C11 6.2.7/1, for that, reuse the structural equivalence checks used by the ASTImporter. Few other considerations: - Create error diagnostics for tag types mismatches and thread them into the structural equivalence checks. - Note that by doing this we only support redefinition between types that are considered "compatible types" by C. This is mixed approach of the suggestions discussed in http://lists.llvm.org/pipermail/cfe-dev/2017-March/053257.html Differential Revision: https://reviews.llvm.org/D31778 rdar://problem/31909368 llvm-svn: 306918
* [OpenCL] Add function name to extension diagnosticJoey Gouly2017-06-301-2/+3
| | | | | | Slightly improve the diagnostic by including the function name. llvm-svn: 306827
* fix trivial typos, NFCHiroshi Inoue2017-06-301-1/+1
| | | | llvm-svn: 306789
* [Sema] Issue diagnostics if a new/delete expression generates a call toAkira Hatanaka2017-06-291-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | a c++17 aligned allocation/deallocation function that is unavailable in the standard library on Apple platforms. The aligned functions are implemented only in the following versions or later versions of the OSes, so clang issues diagnostics if the deployment target being targeted is older than these: macosx: 10.13 ios: 11.0 tvos: 11.0 watchos: 4.0 The diagnostics are issued whenever the aligned functions are selected except when the selected function has a definition in the same file. If there is a user-defined function available somewhere else, option -Wno-aligned-allocation-unavailable can be used to silence the diagnostics. rdar://problem/32664169 Differential Revision: https://reviews.llvm.org/D34574 llvm-svn: 306722
* 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
* Revert r306653, "[OpenCL] Allow function declaration with empty argument list."NAKAMURA Takumi2017-06-291-1/+1
| | | | | | It broke bots. llvm-svn: 306660
* [OpenCL] Allow function declaration with empty argument list.Alexey Bader2017-06-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: does it make sense to enable K&R function declaration style for OpenCL? clang throws following error message for the declaration w/o arguments: ``` int my_func(); error: function with no prototype cannot use the spir_function calling convention ``` Current way to fix this issue is to specify that parameter list is empty by using 'void': ``` int my_func(void); ``` Let me know what do you think about this patch. Reviewers: Anastasia, yaxunl Reviewed By: Anastasia Subscribers: cfe-commits, echuraev Differential Revision: https://reviews.llvm.org/D33681 llvm-svn: 306653
* Fix crash in clang while handling __has_trivial_destructor.Karthik Bhat2017-06-281-9/+11
| | | | | | | | | Fix crash in clang when an array of unknown bounds of an incomplete type is passed to __has_trivial_destructor. Patch by Puneetha https://reviews.llvm.org/D34198 llvm-svn: 306519
* [Sema] Allow unmarked overloadable functions.George Burgess IV2017-06-271-24/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch extends the `overloadable` attribute to allow for one function with a given name to not be marked with the `overloadable` attribute. The overload without the `overloadable` attribute will not have its name mangled. So, the following code is now legal: void foo(void) __attribute__((overloadable)); void foo(int); void foo(float) __attribute__((overloadable)); In addition, this patch fixes a bug where we'd accept code with `__attribute__((overloadable))` inconsistently applied. In other words, we used to accept: void foo(void); void foo(void) __attribute__((overloadable)); But we will do this no longer, since it defeats the original purpose of requiring `__attribute__((overloadable))` on all redeclarations of a function. This breakage seems to not be an issue in practice, since the only code I could find that had this pattern often looked like: void foo(void); void foo(void) __attribute__((overloadable)) __asm__("foo"); void foo(int) __attribute__((overloadable)); ...Which can now be simplified by simply removing the asm label and overloadable attribute from the redeclaration of `void foo(void);` Differential Revision: https://reviews.llvm.org/D32332 llvm-svn: 306467
* Recommit r306103: PR26195: Set correct NestedNameSpecifierLoc for theAlex Lorenz2017-06-271-0/+9
| | | | | | | | | | | | | | | | | | | | dependent initializer 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: 306392
* Revert r301742, which caused us to try to evaluate all full-expressions.Richard Smith2017-06-261-1/+23
| | | | | | | | | | | | | | Also add testcases for a bunch of expression forms that cause our evaluator to crash. See PR33140 and PR32864 for crashes that this was causing. This reverts r305287, which reverted r305239, which reverted r301742. The previous revert claimed that buildbots were broken, but did not add any testcases and the buildbots have lost all memory of what was wrong here. Changes to test/OpenMP are not reverted; another change has triggered those tests to change their output in the same way that r301742 did. llvm-svn: 306346
* [clang] Enable printf check for CFIndexAlexander Shaposhnikov2017-06-261-0/+1
| | | | | | | | | | | | | | According to https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/Strings/Articles/formatSpecifiers.html CFIndex and NSInteger should be treated the same way (see the section Platform Dependencies). This diff changes the function shouldNotPrintDirectly in SemaChecking.cpp accordingly and adds tests for the "fixit" and the warning. Differential revision: https://reviews.llvm.org/D34496 Test plan: make check-all llvm-svn: 306343
* Check that the initializer of a non-dependent constexpr variable is constant ↵Richard Smith2017-06-261-3/+1
| | | | | | even within templates. llvm-svn: 306327
* [Sema] Fix a crash-on-invalid when a template parameter list has a classAkira Hatanaka2017-06-263-6/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | definition or non-reference class type. The crash occurs when there is a template parameter list in a class that is missing the closing angle bracket followed by a definition of a struct. For example: class C0 { public: template<typename T, typename T1 = T // missing closing angle bracket struct S0 {}; C0() : m(new S0<int>) {} S0<int> *m; }; This happens because the parsed struct is added to the scope of the enclosing class without having its access specifier set, which results in an assertion failure in SemaAccess.cpp later. This commit fixes the crash by adding the parsed struct to the enclosing file scope and marking structs as invalid if they are defined in template parameter lists. rdar://problem/31783961 rdar://problem/19570630 Differential Revision: https://reviews.llvm.org/D33606 llvm-svn: 306317
* 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
OpenPOWER on IntegriCloud