summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaOverload.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Revert "[OpenCL] Enabling the usage of CLK_NULL_QUEUE as compare operand."Daniel Jasper2016-12-201-6/+0
| | | | | | | | | | This reverts commit r290171. It triggers a bunch of warnings, because the new enumerator isn't handled in all switches. We want a warning-free build. Replied on the commit with more details. llvm-svn: 290173
* [OpenCL] Enabling the usage of CLK_NULL_QUEUE as compare operand.Egor Churaev2016-12-201-0/+6
| | | | | | | | | | | | Summary: Enabling the compression of CLK_NULL_QUEUE to variable of type queue_t. Reviewers: Anastasia Subscribers: cfe-commits, yaxunl, bader Differential Revision: https://reviews.llvm.org/D27569 llvm-svn: 290171
* Revert "[c++1z] P0195R2: Support pack-expansion of using-declarations."Daniel Jasper2016-12-191-7/+1
| | | | | | | This reverts commit r290080 as it leads to many Clang crashes, e.g.: http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/1814 llvm-svn: 290092
* [c++1z] P0195R2: Support pack-expansion of using-declarations.Richard Smith2016-12-191-1/+7
| | | | | | | | | | | This change introduces UsingPackDecl as a marker for the set of UsingDecls produced by pack expansion of a single (unresolved) using declaration. This is not strictly necessary (we just need to be able to map from the original using declaration to its expansions somehow), but it's useful to maintain the invariant that each declaration reference instantiates to refer to one declaration. llvm-svn: 290080
* Fix some interactions between C++11 and C++14 features and using-declarations:Richard Smith2016-12-181-1/+8
| | | | | | | | | | | * a dependent non-type using-declaration within a function template can be valid, as it can refer to an enumerator, so don't reject it in the template definition * we can partially substitute into a dependent using-declaration if it appears within a (local class in a) generic lambda within a function template, which means an UnresolvedUsing*Decl doesn't necessarily instantiate to a UsingDecl. llvm-svn: 290071
* Recommit r289979 [OpenCL] Allow disabling types and declarations associated ↵Yaxun Liu2016-12-181-0/+16
| | | | | | | | with extensions Fixed undefined behavior due to cast integer to bool in initializer list. llvm-svn: 290056
* Revert r289979 due to regressionsYaxun Liu2016-12-161-16/+0
| | | | llvm-svn: 289991
* [OpenCL] Allow disabling types and declarations associated with extensionsYaxun Liu2016-12-161-0/+16
| | | | | | | | | | | | | | | | | | Added a map to associate types and declarations with extensions. Refactored existing diagnostic for disabled types associated with extensions and extended it to declarations for generic situation. Fixed some bugs for types associated with extensions. Allow users to use pragma to declare types and functions for supported extensions, e.g. #pragma OPENCL EXTENSION the_new_extension_name : begin // declare types and functions associated with the extension here #pragma OPENCL EXTENSION the_new_extension_name : end Differential Revision: https://reviews.llvm.org/D21698 llvm-svn: 289979
* Replace APFloatBase static fltSemantics data members with getter functionsStephan Bergmann2016-12-141-1/+1
| | | | | | | | | | | | | At least the plugin used by the LibreOffice build (<https://wiki.documentfoundation.org/Development/Clang_plugins>) indirectly uses those members (through inline functions in LLVM/Clang include files in turn using them), but they are not exported by utils/extract_symbols.py on Windows, and accessing data across DLL/EXE boundaries on Windows is generally problematic. Differential Revision: https://reviews.llvm.org/D26671 llvm-svn: 289647
* [Sema] Prefer SmallVector over `new`ed memory blocks. NFC.George Burgess IV2016-12-131-6/+4
| | | | llvm-svn: 289571
* DR1295 and cleanup for P0135R1: Make our initialization code more directlyRichard Smith2016-12-091-0/+3
| | | | | | | | | | | | | | | mirror the description in the standard. Per DR1295, this means that binding a const / rvalue reference to a bit-field no longer "binds directly", and per P0135R1, this means that we materialize a temporary in reference binding after adjusting cv-qualifiers and before performing a derived-to-base cast. In C++11 onwards, this should have fixed the last case where we would materialize a temporary of the wrong type (with a subobject adjustment inside the MaterializeTemporaryExpr instead of outside), but we still have to deal with that possibility in C++98, unless we want to start using xvalues to represent materialized temporaries there too. llvm-svn: 289250
* [CUDA] Improve target attribute checking for function templates.Artem Belevich2016-12-071-10/+12
| | | | | | | | | | | | * __host__ __device__ functions are no longer considered to be redeclarations of __host__ or __device__ functions. This prevents unintentional merging of target attributes across them. * Function target attributes are not considered (and must match) during explicit instantiation and specialization of function templates. Differential Revision: https://reviews.llvm.org/D25809 llvm-svn: 288962
* [c++17] P0135R1: Guaranteed copy elision.Richard Smith2016-12-061-1/+1
| | | | | | | | When an object of class type is initialized from a prvalue of the same type (ignoring cv qualifications), use the prvalue to initialize the object directly instead of inserting a redundant elidable call to a copy constructor. llvm-svn: 288866
* [Sema] Reset a BumpPtrAllocator on clear(). NFC.George Burgess IV2016-12-021-0/+1
| | | | | | Looks like the reset() call was omitted by accident. llvm-svn: 288534
* PR31081: ignore exception specifications when deducing function templateRichard Smith2016-12-011-2/+2
| | | | | | | arguments from a declaration; despite what the standard says, this form of deduction should not be considering exception specifications. llvm-svn: 288301
* Use the member function location in enable_if diagnostics.George Burgess IV2016-11-161-2/+2
| | | | | | | | | | | | | | Before: <stdin>:3:3: error: no matching member function for call to 'bar' Foo().bar(); ^ After: <stdin>:3:9: error: no matching member function for call to 'bar' Foo().bar(); ^ llvm-svn: 287154
* [Sema] Range-ify for loop, add period to comment. NFC.George Burgess IV2016-11-101-1/+1
| | | | llvm-svn: 286506
* p0012: Teach resolving address of overloaded function with dependent exceptionRichard Smith2016-11-011-6/+23
| | | | | | | | specification to resolve the exception specification as part of the type check, in C++1z onwards. This is not actually part of P0012 / CWG1330 rules for when an exception specification is "needed", but is necessary for sanity. llvm-svn: 285663
* Make a function static. NFC.George Burgess IV2016-10-281-4/+3
| | | | llvm-svn: 285458
* [c++1z] P0012R1: Implement a few remaining pieces: downgrade diagnostic forRichard Smith2016-10-221-0/+10
| | | | | | | | | | | | | | mismatched dynamic exception specifications in expressions from an error to a warning, since this is no longer ill-formed in C++1z. Allow reference binding of a reference-to-non-noexcept function to a noexcept function lvalue. As defect resolutions, also allow a conditional between noexcept and non-noexcept function lvalues to produce a non-noexcept function lvalue (rather than decaying to a function pointer), and allow function template argument deduction to deduce a reference to non-noexcept function when binding to a noexcept function type. llvm-svn: 284905
* Remove unnecessary distinction between Ref_Compatible andRichard Smith2016-10-211-8/+5
| | | | | | | Ref_Compatible_With_Added_Qualification. We always treated these two values the same way. llvm-svn: 284895
* DR583, DR1512: Implement a rewrite to C++'s 'composite pointer type' rules.Richard Smith2016-10-211-17/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | This has two significant effects: 1) Direct relational comparisons between null pointer constants (0 and nullopt) and pointers are now ill-formed. This was always the case for C, and it appears that C++ only ever permitted by accident. For instance, cases like nullptr < &a are now rejected. 2) Comparisons and conditional operators between differently-cv-qualified pointer types now work, and produce a composite type that both source pointer types can convert to (when possible). For instance, comparison between 'int **' and 'const int **' is now valid, and uses an intermediate type of 'const int *const *'. Clang previously supported #2 as an extension. We do not accept the cases in #1 as an extension. I've tested a fair amount of code to check that this doesn't break it, but if it turns out that someone is relying on this, we can easily add it back as an extension. This is a re-commit of r284800. llvm-svn: 284890
* Revert "DR583, DR1512: Implement a rewrite to C++'s 'composite pointer type' ↵Renato Golin2016-10-211-15/+17
| | | | | | | | rules." This reverts commit r284800, as it failed all ARM/AArch64 bots. llvm-svn: 284811
* DR583, DR1512: Implement a rewrite to C++'s 'composite pointer type' rules.Richard Smith2016-10-211-17/+15
| | | | | | | | | | | | | | | | | | | | | | | | This has two significant effects: 1) Direct relational comparisons between null pointer constants (0 and nullopt) and pointers are now ill-formed. This was always the case for C, and it appears that C++ only ever permitted by accident. For instance, cases like nullptr < &a are now rejected. 2) Comparisons and conditional operators between differently-cv-qualified pointer types now work, and produce a composite type that both source pointer types can convert to (when possible). For instance, comparison between 'int **' and 'const int **' is now valid, and uses an intermediate type of 'const int *const *'. Clang previously supported #2 as an extension. We do not accept the cases in #1 as an extension. I've tested a fair amount of code to check that this doesn't break it, but if it turns out that someone is relying on this, we can easily add it back as an extension. llvm-svn: 284800
* Re-commit r284753, reverted in r284778, with a fix for PR30749.Richard Smith2016-10-201-25/+29
| | | | | | | | | | Original commit message: [c++1z] Teach composite pointer type computation how to compute the composite pointer type of two function pointers with different noexcept specifications. While I'm here, also teach it how to merge dynamic exception specifications. llvm-svn: 284785
* Revert r284753 "[c++1z] Teach composite pointer type computation how to ↵Hans Wennborg2016-10-201-29/+25
| | | | | | | | compute the composite" It caused PR30749. llvm-svn: 284778
* [c++1z] Teach composite pointer type computation how to compute the compositeRichard Smith2016-10-201-25/+29
| | | | | | | pointer type of two function pointers with different noexcept specifications. While I'm here, also teach it how to merge dynamic exception specifications. llvm-svn: 284753
* Fix crash on noreturn conversion in unprototyped function type. Thanks to KeithRichard Smith2016-10-201-2/+2
| | | | | | Walker for spotting the bug. llvm-svn: 284673
* Resolve exception specifications when selecting an overloaded operator.Richard Smith2016-10-191-0/+2
| | | | llvm-svn: 284556
* DR1330: instantiate exception-specifications when "needed". We previously didRichard Smith2016-10-181-0/+7
| | | | | | | | | | | | | | | | | | | | not instantiate exception specifications of functions if they were only used in unevaluated contexts (other than 'noexcept' expressions). In C++17 onwards, this becomes essential since the exception specification is now part of the function's type. Note that this means that constructs like the following no longer work: struct A { static T f() noexcept(...); decltype(f()) *p; }; ... because the decltype expression now needs the exception specification of 'f', which has not yet been parsed. llvm-svn: 284549
* P0012R1: Make exception specifications be part of the type system. ThisRichard Smith2016-10-161-14/+54
| | | | | | | implements the bulk of the change (modifying the type system to include exception specifications), but not all the details just yet. llvm-svn: 284337
* Re-commit r283722, reverted in r283750, with a fix for a CUDA-specific use ofRichard Smith2016-10-101-5/+6
| | | | | | | | | | | past-the-end iterator. Original commit message: P0035R4: Semantic analysis and code generation for C++17 overaligned allocation. llvm-svn: 283789
* Revert "P0035R4: Semantic analysis and code generation for C++17 overaligned ↵Daniel Jasper2016-10-101-6/+5
| | | | | | | | | | | | allocation." This reverts commit r283722. Breaks: Clang.SemaCUDA.device-var-init.cu Clang.CodeGenCUDA.device-var-init.cu http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-expensive/884/ llvm-svn: 283750
* P0035R4: Semantic analysis and code generation for C++17 overalignedRichard Smith2016-10-101-5/+6
| | | | | | allocation. llvm-svn: 283722
* PR25890: Fix incoherent error handling in PerformImplicitConversion andRichard Smith2016-10-061-1/+2
| | | | | | | | | | | | CheckSingleAssignmentConstraints. These no longer produce ExprError() when they have not emitted an error, and reliably inform the caller when they *have* emitted an error. This fixes some serious issues where we would fail to emit any diagnostic for invalid code and then attempt to emit code for an invalid AST, and conversely some issues where we would emit two diagnostics for the same problem. llvm-svn: 283508
* [CUDA] Clean up some comments in Sema::IsOverload. NFCJustin Lebar2016-10-031-7/+7
| | | | llvm-svn: 283121
* [CUDA] Disallow overloading destructors.Justin Lebar2016-10-031-0/+5
| | | | | | | | | | | | | | | | | | | | | | Summary: We'd attempted to allow this, but turns out we were doing a very bad job. :) Making this work properly would be a giant change in clang. For example, we'd need to make CXXRecordDecl::getDestructor() context-sensitive, because the destructor you end up with depends on where you're calling it from. For now (and hopefully for ever), just disallow overloading of destructors in CUDA. Reviewers: rsmith Subscribers: cfe-commits, tra Differential Revision: https://reviews.llvm.org/D24571 llvm-svn: 283120
* [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
* [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-021-15/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* 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
* 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
* [CUDA] Raise an error if a wrong-side call is codegen'ed.Justin Lebar2016-08-151-13/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [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
* [CUDA] Print a "previous-decl" note when calling an illegal member fn.Justin Lebar2016-08-101-0/+1
| | | | | | | | | | | | | | | Summary: When we emit err_ref_bad_target, we should emit a "'method' declared here" note. We already do so in most places, just not in BuildCallToMemberFunction. Reviewers: tra Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D23240 llvm-svn: 278195
* [CUDA] Rename CheckCUDATarget to IsAllowedCUDACall. NFCJustin Lebar2016-08-101-4/+4
| | | | | | | | | | | | | | Summary: I want to reuse "CheckCUDAFoo" in a later patch. Also, I think IsAllowedCUDACall gets the point across more clearly. Reviewers: tra Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D23238 llvm-svn: 278193
* [CUDA] Minor comment nits.Justin Lebar2016-08-101-2/+2
| | | | llvm-svn: 278183
* [Sema] Replace mem_fn with lambdas. NFC.George Burgess IV2016-07-241-4/+6
| | | | | | | | | I'm told that some optimizers like lambdas a lot more than mem_fn. Given that the readability difference is basically nil, and we seem to use lambdas basically everywhere else, it seems sensible to just use lambdas. llvm-svn: 276577
OpenPOWER on IntegriCloud