summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaOverload.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Fix a typo. NFC.George Burgess IV2017-01-141-1/+1
| | | | llvm-svn: 291997
* PR31606: Generalize our tentative DR resolution for inheriting copy/moveRichard Smith2017-01-131-26/+28
| | | | | | constructors to better match the pre-P0136R1 behavior. llvm-svn: 291955
* Don't try to check implicit conversion sequences for an object argument ifRichard Smith2017-01-101-2/+8
| | | | | | | there is no object argument, when early checking of implicit conversion sequences for a function template fails. llvm-svn: 291597
* Fix conversion index / argument index mismatch when diagnosing overload ↵Richard Smith2017-01-101-32/+18
| | | | | | resolution failure. llvm-svn: 291596
* Implement C++ DR1391 (wg21.link/cwg1391)Richard Smith2017-01-091-77/+184
| | | | | | | | | | | | | | Check for implicit conversion sequences for non-dependent function template parameters between deduction and substitution. The idea is to accept as many cases as possible, on the basis that substitution failure outside the immediate context is much more common during substitution than during implicit conversion sequence formation. This re-commits r290808, reverted in r290811 and r291412, with a couple of fixes for handling of explicitly-specified non-trailing template argument packs. llvm-svn: 291427
* Add the diagnose_if attribute to clang.George Burgess IV2017-01-091-78/+266
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `diagnose_if` can be used to have clang emit either warnings or errors for function calls that meet user-specified conditions. For example: ``` constexpr int foo(int a) __attribute__((diagnose_if(a > 10, "configurations with a > 10 are " "expensive.", "warning"))); int f1 = foo(9); int f2 = foo(10); // warning: configuration with a > 10 are expensive. int f3 = foo(f2); ``` It currently only emits diagnostics in cases where the condition is guaranteed to always be true. So, the following code will emit no warnings: ``` constexpr int bar(int a) { foo(a); return 0; } constexpr int i = bar(10); ``` We hope to support optionally emitting diagnostics for cases like that (and emitting runtime checks) in the future. Release notes will appear shortly. :) Differential Revision: https://reviews.llvm.org/D27424 llvm-svn: 291418
* Revert r291410 and r291411.Richard Smith2017-01-091-183/+75
| | | | | | The test-suite bots are still failing even after r291410's fix. llvm-svn: 291412
* Implement C++ DR1391 (wg21.link/cwg1391)Richard Smith2017-01-091-75/+183
| | | | | | | | | | | | | Check for implicit conversion sequences for non-dependent function template parameters between deduction and substitution. The idea is to accept as many cases as possible, on the basis that substitution failure outside the immediate context is much more common during substitution than during implicit conversion sequence formation. This re-commits r290808, reverted in r290811, with a fix for handling of explicitly-specified template argument packs. llvm-svn: 291410
* PR30305: Implement proposed DR resolution to prevent slicing via inherited ↵Richard Smith2017-01-081-0/+31
| | | | | | | | | | | | constructor. The rule we use is that a construction of a class type T from an argument of type U cannot use an inherited constructor if U is the same as T or is derived from T (or if the initialization would first convert it to such a type). This (approximately) matches the rule in use by GCC, and matches the current proposed DR resolution. llvm-svn: 291403
* Add missing "original call argument has same type as deduced parameter type"Richard Smith2017-01-051-6/+18
| | | | | | check for deductions from elements of a braced-init-list. llvm-svn: 291190
* Fix failure to treat overloaded function in braced-init-list as a ↵Richard Smith2017-01-041-26/+0
| | | | | | | | | | | | | non-deduced context. Previously, if an overloaded function in a braced-init-list was encountered in template argument deduction, and the overload set couldn't be resolved to a particular function, we'd immediately produce a deduction failure. That's not correct; this situation is supposed to result in that particular P/A pair being treated as a non-deduced context, and deduction can still succeed if the type can be deduced from elsewhere. llvm-svn: 291014
* [Sema] Replace remove_if+erase with erase_if. NFC.George Burgess IV2017-01-041-3/+1
| | | | llvm-svn: 290991
* Revert "DR1391: Check for implicit conversion sequences for non-dependent ↵Renato Golin2017-01-021-182/+75
| | | | | | | | | | | | | | function template parameters between deduction and substitution. The idea is to accept as many cases as possible, on the basis that substitution failure outside the immediate context is much more common during substitution than during implicit conversion sequence formation." This reverts commit r290808, as it broken all ARM and AArch64 test-suite test: MultiSource/UnitTests/C++11/frame_layout Also, please, next time, try to write a commit message in according to our guidelines: http://llvm.org/docs/DeveloperPolicy.html#commit-messages llvm-svn: 290811
* DR1391: Check for implicit conversion sequences for non-dependent functionRichard Smith2017-01-021-75/+182
| | | | | | | | | | | | template parameters between deduction and substitution. The idea is to accept as many cases as possible, on the basis that substitution failure outside the immediate context is much more common during substitution than during implicit conversion sequence formation. This does not implement the partial ordering portion of DR1391, which so far appears to be misguided. llvm-svn: 290808
* Check and build conversion sequences for non-type template arguments inRichard Smith2016-12-271-1/+1
| | | | | | | dependent contexts when processing the template in C++11 and C++14, just like we do in C++98 and C++1z. This allows us to diagnose invalid templates earlier. llvm-svn: 290567
* Fix problems in "[OpenCL] Enabling the usage of CLK_NULL_QUEUE as compare ↵Egor Churaev2016-12-231-0/+6
| | | | | | | | | | | | | | operand." Summary: Fixed warnings in commit: https://reviews.llvm.org/rL290171 Reviewers: djasper, Anastasia Subscribers: yaxunl, cfe-commits, bader Differential Revision: https://reviews.llvm.org/D27981 llvm-svn: 290431
* When merging two deduced non-type template arguments for the same parameter,Richard Smith2016-12-231-2/+18
| | | | | | | | | | | | | | | | | | | fail the merge if the arguments have different types (except if one of them was deduced from an array bound, in which case take the type from the other). This is correct because (except in the array bound case) the type of the template argument in each deduction must match the type of the parameter, so at least one of the two deduced arguments must have a mismatched type. This is necessary because we would otherwise lose the type information for the discarded template argument in the merge, and fail to diagnose the mismatch. In order to power this, we now properly retain the type of a deduced non-type template argument deduced from a declaration, rather than giving it the type of the template parameter; we'll convert it to the template parameter type when checking the deduced arguments. llvm-svn: 290399
* Sema: print qualified name for overload candidatesSaleem Abdulrasool2016-12-221-1/+1
| | | | | | | | | | | | | Print the fully qualified names for the overload candidates. This makes it easier to tell what the ambiguity is. Especially if a template is instantiated after a using namespace, it will not inherit the namespace where it was declared. The specialization will give a message about a partial order being ambiguous for the same (unqualified) name, which does not help identify the failure. Addresses PR31450! llvm-svn: 290315
* Perform type-checking for a converted constant expression in a templateRichard Smith2016-12-211-0/+23
| | | | | | | | | | | argument even if the expression is value-dependent (we need to suppress the final portion of the narrowing check, but the rest of the checking can still be done eagerly). This affects template template argument validity and partial ordering under p0522r0. llvm-svn: 290276
* [c++1z] P0195R2: Support pack-expansion of using-declarations.Richard Smith2016-12-201-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. This is a re-commit of r290080 (reverted in r290092) with a fix for a use-after-lifetime bug. llvm-svn: 290203
* 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
OpenPOWER on IntegriCloud