summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema
Commit message (Collapse)AuthorAgeFilesLines
* [Sema] Compare bad conversions in overload resolution.George Burgess IV2016-09-071-3/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | r280553 introduced an issue where we'd emit ambiguity errors for code like: ``` void foo(int *, int); void foo(unsigned int *, unsigned int); void callFoo() { unsigned int i; foo(&i, 0); // ambiguous: int->unsigned int is worse than int->int, // but unsigned int*->unsigned int* is better than // int*->int*. } ``` This patch fixes this issue by changing how we handle ill-formed (but valid) implicit conversions. Candidates with said conversions now always rank worse than candidates without them, and two candidates are considered to be equally bad if they both have these conversions for the same argument. Additionally, this fixes a case in C++11 where we'd complain about an ambiguity in a case like: ``` void f(char *, int); void f(const char *, unsigned); void g() { f("abc", 0); } ``` ...Since conversion to char* from a string literal is considered ill-formed in C++11 (and deprecated in C++03), but we accept it as an extension. llvm-svn: 280847
* Try contextually converting condition of constexpr if to Boolean valueIsmail Pazarbasi2016-09-071-5/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: C++1z 6.4.1/p2: If the if statement is of the form if constexpr, the value of the condition shall be a contextually converted constant expression of type bool [...] C++1z 5.20/p4: [...] A contextually converted constant expression of type bool is an expression, contextually converted to bool (Clause4), where the converted expression is a constant expression and the conversion sequence contains only the conversions above. [...] Contextually converting result of an expression `e` to a Boolean value requires `bool t(e)` to be well-formed. An explicit conversion function is only considered as a user-defined conversion for direct-initialization, which is essentially what //contextually converted to bool// requires. Also, fixes PR28470. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D24158 llvm-svn: 280838
* [OpenCL] Fix pipe built-in functions return type.Alexey Bader2016-09-071-0/+2
| | | | | | | | | | | | | | | By default return type of call expressions calling built-in functions is set to bool. Fixes https://llvm.org/bugs/show_bug.cgi?id=30219. Reviewers: Anastasia Subscribers: dmitry, cfe-commits, yaxunl Differential Revision: https://reviews.llvm.org/D24136 llvm-svn: 280800
* Fix clang's handling of the copy performed in the second phase of classRichard Smith2016-09-071-119/+106
| | | | | | | | | | | | | | | | | | | | | | | copy-initialization. We previously got this wrong in a couple of ways: - we only looked for copy / move constructors and constructor templates for this copy, and thus would fail to copy in cases where doing so should use some other constructor (but see core issue 670), - we mishandled the special case for disabling user-defined conversions that blocks infinite recursion through repeated application of a copy constructor (applying it in slightly too many cases) -- though as far as I can tell, this does not ever actually affect the result of overload resolution, and - we misapplied the special-case rules for constructors taking a parameter whose type is a (reference to) the same class type by incorrectly assuming that only happens for copy/move constructors (it also happens for constructors instantiated from templates and those inherited from base classes). These changes should only affect strange corner cases (for instance, where the copy constructor exists but has a non-const-qualified parameter type), so for the most part it only causes us to produce more 'candidate' notes, but see the test changes for other cases whose behavior is affected. llvm-svn: 280776
* [Sema] Fix how we set implicit conversion kinds.George Burgess IV2016-09-031-9/+15
| | | | | | | | | | | | We have invariants we like to guarantee for the `ImplicitConversionKind`s in a `StandardConversionSequence`. These weren't being upheld in code that r280553 touched, so Richard suggested that we should fix that. See D24113. I'm not entirely sure how to go about testing this, so no test case is included. Suggestions welcome. llvm-svn: 280562
* [Sema] Relax overloading restrictions in C.George Burgess IV2016-09-022-15/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch allows us to perform incompatible pointer conversions when resolving overloads in C. So, the following code will no longer fail to compile (though it will still emit warnings, assuming the user hasn't opted out of them): ``` void foo(char *) __attribute__((overloadable)); void foo(int) __attribute__((overloadable)); void callFoo() { unsigned char bar[128]; foo(bar); // selects the char* overload. } ``` These conversions are ranked below all others, so: A. Any other viable conversion will win out B. If we had another incompatible pointer conversion in the example above (e.g. `void foo(int *)`), we would complain about an ambiguity. Differential Revision: https://reviews.llvm.org/D24113 llvm-svn: 280553
* Implement __attribute__((require_constant_initialization)) for safe static ↵Eric Fiselier2016-09-022-24/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | initialization. Summary: This attribute specifies expectations about the initialization of static and thread local variables. Specifically that the variable has a [constant initializer](http://en.cppreference.com/w/cpp/language/constant_initialization) according to the rules of [basic.start.static]. Failure to meet this expectation will result in an error. Static objects with constant initializers avoid hard-to-find bugs caused by the indeterminate order of dynamic initialization. They can also be safely used by other static constructors across translation units. This attribute acts as a compile time assertion that the requirements for constant initialization have been met. Since these requirements change between dialects and have subtle pitfalls it's important to fail fast instead of silently falling back on dynamic initialization. ```c++ // -std=c++14 #define SAFE_STATIC __attribute__((require_constant_initialization)) static struct T { constexpr T(int) {} ~T(); }; SAFE_STATIC T x = {42}; // OK. SAFE_STATIC T y = 42; // error: variable does not have a constant initializer // copy initialization is not a constant expression on a non-literal type. ``` This attribute can only be applied to objects with static or thread-local storage duration. Reviewers: majnemer, rsmith, aaron.ballman Subscribers: jroelofs, cfe-commits Differential Revision: https://reviews.llvm.org/D23385 llvm-svn: 280525
* Revert r280516 since it contained accidental changes.Eric Fiselier2016-09-022-53/+24
| | | | llvm-svn: 280521
* Based on post-commit feedback over IRC with dblaikie, ideally, we should ↵Aaron Ballman2016-09-021-2/+2
| | | | | | | | have a SmallVector constructor that accepts anything which can supply a range via ADL begin()/end() calls so that we can construct the SmallVector directly from anything range-like. Since that doesn't exist right now, use a local variable instead of calling getAssocExprs() twice; NFC. llvm-svn: 280520
* Implement __attribute__((require_constant_initialization)) for safe static ↵Eric Fiselier2016-09-022-24/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | initialization. Summary: This attribute specifies expectations about the initialization of static and thread local variables. Specifically that the variable has a [constant initializer](http://en.cppreference.com/w/cpp/language/constant_initialization) according to the rules of [basic.start.static]. Failure to meet this expectation will result in an error. Static objects with constant initializers avoid hard-to-find bugs caused by the indeterminate order of dynamic initialization. They can also be safely used by other static constructors across translation units. This attribute acts as a compile time assertion that the requirements for constant initialization have been met. Since these requirements change between dialects and have subtle pitfalls it's important to fail fast instead of silently falling back on dynamic initialization. ```c++ // -std=c++14 #define SAFE_STATIC __attribute__((require_constant_initialization)) static struct T { constexpr T(int) {} ~T(); }; SAFE_STATIC T x = {42}; // OK. SAFE_STATIC T y = 42; // error: variable does not have a constant initializer // copy initialization is not a constant expression on a non-literal type. ``` This attribute can only be applied to objects with static or thread-local storage duration. Reviewers: majnemer, rsmith, aaron.ballman Subscribers: jroelofs, cfe-commits Differential Revision: https://reviews.llvm.org/D23385 llvm-svn: 280516
* Allow a C11 generic selection expression to select a function with the ↵Aaron Ballman2016-09-021-0/+25
| | | | | | overloadable attribute as the result expression without crashing. This fixes PR30201. llvm-svn: 280483
* Remove excessive padding from MismatchingNewDeleteDetectorAlexander Shaposhnikov2016-09-011-2/+2
| | | | | | | | | | | The class MismatchingNewDeleteDetector is in lib/Sema/SemaExprCXX.cpp inside the anonymous namespace. This diff reorders the fields and removes the excessive padding. Test plan: make -j8 check-clang Differential revision: https://reviews.llvm.org/D23898 llvm-svn: 280426
* When we reach the end of a #include of a header of a local submodule that weRichard Smith2016-09-011-7/+17
| | | | | | | | | | textually included, create an ImportDecl just as we would if we reached a #include of any other modular header. This is necessary in order to correctly determine the set of variables to initialize for an imported module. This should hopefully make the modules selfhost buildbot green again. llvm-svn: 280409
* Fix typos in comments.George Burgess IV2016-09-011-3/+3
| | | | llvm-svn: 280333
* [Sema] Don't diagnose an array type mismatch when the new or previousAkira Hatanaka2016-09-011-2/+2
| | | | | | | | | | | | declaration has a dependent type. This fixes a bug where clang errors out on a valid code. rdar://problem/28051467 Differential Revision: https://reviews.llvm.org/D24110 llvm-svn: 280330
* DR259: Demote the pedantic error for an explicit instantiation after anRichard Smith2016-08-311-7/+1
| | | | | | | | | explicit specialization to a warning for C++98 mode (this is a defect report resolution, so per our informal policy it should apply in C++98), and turn the warning on by default for C++11 and later. In all cases where it fires, the right thing to do is to remove the pointless explicit instantiation. llvm-svn: 280308
* Don't diagnoes a mismatch between implicit and explicit exceptionRichard Smith2016-08-311-1/+1
| | | | | | | specifications under -fno-exceptions, just as we don't diagnose other exception specification mismatch errors. llvm-svn: 280289
* Fix mishandling of deletedness for assignment operators of classes withRichard Smith2016-08-311-3/+4
| | | | | | | | indirect virtual bases. We don't need to be able to invoke such an assignment operator from the derived class, and we shouldn't delete the derived assignment op if we can't do so. llvm-svn: 280288
* PR12298 et al: don't recursively instantiate a template specialization fromRichard Smith2016-08-315-22/+71
| | | | | | | | | | | | | | | within the instantiation of that same specialization. This could previously happen for eagerly-instantiated function templates, variable templates, exception specifications, default arguments, and a handful of other cases. We still have an issue here for default template arguments that recursively make use of themselves and likewise for substitution into the type of a non-type template parameter, but in those cases we're producing a different entity each time, so they should instead be caught by the instantiation depth limit. However, currently we will typically run out of stack before we reach it. :( llvm-svn: 280190
* C++ Modules TS: add frontend support for building pcm files from moduleRichard Smith2016-08-262-27/+63
| | | | | | | interface files. At the moment, all declarations (and no macros) are exported, and 'export' declarations are not supported yet. llvm-svn: 279794
* PR29097: add an update record when we instantiate the default memberRichard Smith2016-08-241-0/+4
| | | | | | initializer of an imported field. llvm-svn: 279667
* Fix member call on null pointer, found by sanitizer buildbot.Richard Smith2016-08-231-2/+4
| | | | llvm-svn: 279571
* Fix regression introduced by r279164: only pass definitions as the PatternDefRichard Smith2016-08-234-62/+62
| | | | | | | | | | | | | | | | | | | | | | | | | to DiagnoseUninstantiableTemplate, teach hasVisibleDefinition to correctly determine whether a function definition is visible, and mark both the function and the template as visible when merging function template definitions to provide hasVisibleDefinition with the relevant information. The change to always pass the right declaration as the PatternDef to DiagnoseUninstantiableTemplate also caused those checks to happen before other diagnostics in InstantiateFunctionDefinition, giving worse diagnostics for the same situations, so I sunk the relevant diagnostics into DiagnoseUninstantiableTemplate. Those parts of this patch are based on changes in reviews.llvm.org/D23492 by Vassil Vassilev. This reinstates r279486, reverted in r279500, with a fix to DiagnoseUninstantiableTemplate to only mark uninstantiable explicit instantiation declarations as invalid if we actually diagnosed them. (When we trigger an explicit instantiation of a class member from an explicit instantiation declaration for the class, it's OK if there is no corresponding definition and we certainly don't want to mark the member invalid in that case.) This previously caused a build failure during bootstrap. llvm-svn: 279557
* Revert r279486 "Fix regression introduced by r279164"Chandler Carruth2016-08-234-59/+59
| | | | | | | Build bots seem unhappy and as Richard was leaving he asked me to revert this for him. Doing so. llvm-svn: 279500
* Fix regression introduced by r279164: only pass definitions as the PatternDefRichard Smith2016-08-224-59/+59
| | | | | | | | | | | | | | | | to DiagnoseUninstantiableTemplate, teach hasVisibleDefinition to correctly determine whether a function definition is visible, and mark both the function and the template as visible when merging function template definitions to provide hasVisibleDefinition with the relevant information. The change to always pass the right declaration as the PatternDef to DiagnoseUninstantiableTemplate also caused those checks to happen before other diagnostics in InstantiateFunctionDefinition, giving worse diagnostics for the same situations, so I sunk the relevant diagnostics into DiagnoseUninstantiableTemplate. Those parts of this patch are based on changes in reviews.llvm.org/D23492 by Vassil Vassilev. llvm-svn: 279486
* [SemaObjC] Do not RebuildObjCMessageExpr without valid method declBruno Cardoso Lopes2016-08-221-0/+3
| | | | | | | | | | | | | | Fix crash-on-invalid in ObjC Sema by avoiding to rebuild a message expression to a 'super' class in case the method to call does not exist (i.e. comes from another missing identifier). In this case, the typo transform is invoked upon the message expression in an attempt to solve a typo in a 'super' call parameters, but it crashes since it assumes the method to call has a valid declaration. rdar://problem/27305403 llvm-svn: 279481
* PR28423: Compare primary declaration contexts.Vassil Vassilev2016-08-201-1/+2
| | | | | | | | | | | In certain cases (mostly coming from modules), Sema's idea of the StdNamespace does not point to the first declaration of namespace std. Patch by Cristina Cristescu! Reviewed by Richard Smith. llvm-svn: 279371
* C++ Modules TS: support parsing the 'module' declaration (including extensionsRichard Smith2016-08-191-1/+54
| | | | | | | | from p0273r0 approved by EWG). We'll eventually need to handle this from the lexer as well, in order to disallow preprocessor directives preceding the module declaration and to support macro import. llvm-svn: 279196
* PR28794: Don't try to instantiate function templates which are not visible.Vassil Vassilev2016-08-183-69/+87
| | | | | | Reviewed by Richard Smith. llvm-svn: 279164
* C++ Modules TS: Add parsing support for module import declaration.Richard Smith2016-08-181-3/+2
| | | | llvm-svn: 279163
* [MS] Silence -Wextern-init on const selectany variablesReid Kleckner2016-08-181-3/+10
| | | | | | | | | | | | In C, 'extern' is typically used to avoid tentative definitions when declaring variables in headers, but adding an intializer makes it a defintion. This is somewhat confusing, so GCC and Clang both warn on it. In C++, 'extern' is often used to give implictly static 'const' variables external linkage, so don't warn in that case. If selectany is present, this might be header code intended for C and C++ inclusion, so apply the C++ rules. llvm-svn: 279116
* Revert "[OpenMP] Sema and parsing for 'teams distribute simd’ pragma"Diana Picus2016-08-182-197/+1
| | | | | | | | | | | | | | | | | This reverts commit r279003 as it breaks some of our buildbots (e.g. clang-cmake-aarch64-quick, clang-x86_64-linux-selfhost-modules). The error is in OpenMP/teams_distribute_simd_ast_print.cpp: clang: /home/buildslave/buildslave/clang-cmake-aarch64-quick/llvm/include/llvm/ADT/DenseMap.h:527: bool llvm::DenseMapBase<DerivedT, KeyT, ValueT, KeyInfoT, BucketT>::LookupBucketFor(const LookupKeyT&, const BucketT*&) const [with LookupKeyT = clang::Stmt*; DerivedT = llvm::DenseMap<clang::Stmt*, long unsigned int>; KeyT = clang::Stmt*; ValueT = long unsigned int; KeyInfoT = llvm::DenseMapInfo<clang::Stmt*>; BucketT = llvm::detail::DenseMapPair<clang::Stmt*, long unsigned int>]: Assertion `!KeyInfoT::isEqual(Val, EmptyKey) && !KeyInfoT::isEqual(Val, TombstoneKey) && "Empty/Tombstone value shouldn't be inserted into map!"' failed. llvm-svn: 279045
* [OpenMP] Sema and parsing for 'teams distribute simd’ pragmaKelvin Li2016-08-172-1/+197
| | | | | | | | | | This patch is to implement sema and parsing for 'teams distribute simd’ pragma. This patch is originated by Carlo Bertolli. Differential Revision: https://reviews.llvm.org/D23528 llvm-svn: 279003
* [ObjC] Warn on unguarded use of partial declarationErik Pilkington2016-08-166-16/+164
| | | | | | | | | | | | | | This commit adds a traversal of the AST after Sema of a function that diagnoses unguarded references to declarations that are partially available (based on availability attributes). This traversal is only done when we would otherwise emit -Wpartial-availability. This commit is part of a feature I proposed here: http://lists.llvm.org/pipermail/cfe-dev/2016-July/049851.html Differential revision: https://reviews.llvm.org/D23003 llvm-svn: 278826
* Left shifts of negative values are defined if -fwrapv is setJames Molloy2016-08-161-1/+1
| | | | | | | This means we shouldn't emit ubsan detection code or warn. Fixes PR25552. llvm-svn: 278786
* [CUDA] Fix "declared here" note on deferred wrong-side errors.Justin Lebar2016-08-161-5/+10
| | | | | | | Previously we weren't deferring these "declared here" notes, which is obviously wrong. llvm-svn: 278767
* [CUDA] Raise an error if a wrong-side call is codegen'ed.Justin Lebar2016-08-154-80/+112
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Some function calls in CUDA are allowed to appear in semantically-correct programs but are an error if they're ever codegen'ed. Specifically, a host+device function may call a host function, but it's an error if such a function is ever codegen'ed in device mode (and vice versa). Previously, clang made no attempt to catch these errors. For the most part, they would be caught by ptxas, and reported as "call to unknown function 'foo'". Now we catch these errors and report them the same as we report other illegal calls (e.g. a call from a host function to a device function). This has a small change in error-message behavior for calls that were previously disallowed (e.g. calls from a host to a device function). Previously, we'd catch disallowed calls fairly early, before doing additional semantic checking e.g. of the call's arguments. Now we catch these illegal calls at the very end of our semantic checks, so we'll only emit a "illegal CUDA call" error if the call is otherwise well-formed. Reviewers: tra, rnk Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D23242 llvm-svn: 278759
* Disable lambda-capture of decomposition declaration bindings for now, until CWGRichard Smith2016-08-151-15/+20
| | | | | | agrees on how they're supposed to work. llvm-svn: 278648
* P0217R3: code generation support for decomposition declarations.Richard Smith2016-08-151-2/+4
| | | | llvm-svn: 278642
* Explicitly generate a reference variable to hold the initializer for aRichard Smith2016-08-141-3/+22
| | | | | | | | tuple-like decomposition declaration. This significantly simplifies the semantics of BindingDecls for AST consumers (they can now always be evalated at the point of use). llvm-svn: 278640
* Fix Wdocumentation unknown parameter warningSimon Pilgrim2016-08-121-116/+114
| | | | llvm-svn: 278503
* Fix For pr28288 - Error message in shift of vector valuesAndrey Bokhanko2016-08-121-11/+5
| | | | | | | | | | This fixes an error in type checking of shift of vector values. Patch by Vladimir Yakovlev. Differential Revision: https://reviews.llvm.org/D21678 llvm-svn: 278501
* This patch implements PR#22821.Roger Ferrer Ibanez2016-08-124-1/+79
| | | | | | | | | | | | | | | | | | Taking the address of a packed member is dangerous since the reduced alignment of the pointee is lost. This can lead to memory alignment faults in some architectures if the pointer value is dereferenced. This change adds a new warning to clang emitted when taking the address of a packed member. A packed member is either a field/data member declared as attribute((packed)) or belonging to a struct/class declared as such. The associated flag is -Waddress-of-packed-member. Conversions (either implicit or via a valid casting) to pointer types with lower or equal alignment requirements (e.g. void* or char*) will silence the warning. Differential Revision: https://reviews.llvm.org/D20561 llvm-svn: 278483
* [Sema] Fix the wording of a comment. NFC.George Burgess IV2016-08-121-1/+1
| | | | llvm-svn: 278472
* [Sema] Fix a crash on variadic enable_if functions.George Burgess IV2016-08-121-1/+5
| | | | | | | | | | | | | Currently, when trying to evaluate an enable_if condition, we try to evaluate all arguments a user passes to a function. Given that we can't use variadic arguments from said condition anyway, not converting them is a reasonable thing to do. So, this patch makes us ignore any varargs when attempting to check an enable_if condition. We'd crash because, in order to convert an argument, we need its ParmVarDecl. Variadic arguments don't have ParmVarDecls. llvm-svn: 278471
* P0217R3: template instantiation support for decomposition declarations.Richard Smith2016-08-125-27/+46
| | | | llvm-svn: 278458
* Remove unused and undesirable reference from BindingDecl to DecompositionDecl.Richard Smith2016-08-123-14/+5
| | | | llvm-svn: 278448
* P0217R3: Constant expression evaluation for decomposition declarations.Richard Smith2016-08-123-6/+16
| | | | llvm-svn: 278447
* P0217R3: Perform semantic checks and initialization for the bindings in aRichard Smith2016-08-119-223/+867
| | | | | | | decomposition declaration for arrays, aggregate-like structs, tuple-like types, and (as an extension) for complex and vector types. llvm-svn: 278435
* [Sema] Add more strict check for sizeof diagnostics for bzeroBruno Cardoso Lopes2016-08-111-0/+7
| | | | | | | | | | Follow-up from r278264 after Joerg's feedback. Since bzero is not standard, be more strict: also check if the first argument is a pointer, which harden the check for when it does not come originally from a builtin. llvm-svn: 278379
OpenPOWER on IntegriCloud