summaryrefslogtreecommitdiffstats
path: root/clang/test/CXX/over
Commit message (Collapse)AuthorAgeFilesLines
* PR44761: Fix fallback to later tiebreakers if two non-template functionsRichard Smith2020-02-041-0/+16
| | | | | | are equally constrained. (cherry picked from commit cfacf9ae20b8c97a428f118a2720bc109ba6a143)
* PR44627: Consider reversing == and <=> candidates found by ADL.Richard Smith2020-01-301-0/+12
| | | | (cherry picked from commit 1db66e705f4dbe7dbe17edac804289ef59d5f616)
* [Concepts] Deprecate -fconcepts-ts, enable Concepts under -std=c++2aSaar Raz2020-01-243-3/+3
| | | | | | | | | Now with concepts support merged and mostly complete, we do not need -fconcepts-ts (which was also misleading as we were not implementing the TS) and can enable concepts features under C++2a. A warning will be generated if users still attempt to use -fconcepts-ts. (cherry picked from commit 67c608a9695496cfc9d3fdf9d0b12b554ac6b4df)
* When diagnosing the lack of a viable conversion function, also listRichard Smith2020-01-091-3/+3
| | | | | | | | | | | | | | explicit functions that are not candidates. It's not always obvious that the reason a conversion was not possible is because the function you wanted to call is 'explicit', so explicitly say if that's the case. It would be nice to rank the explicit candidates higher in the diagnostic if an implicit conversion sequence exists for their arguments, but unfortunately we can't determine that without potentially triggering non-immediate-context errors that we're not permitted to produce.
* [Concepts] Fix failing test on WindowsSaar Raz2020-01-091-3/+2
| | | | Fix test failed by D43357 on Windows.
* [Concepts] Function trailing requires clausesSaar Raz2020-01-093-0/+238
| | | | | | Function trailing requires clauses now parsed, supported in overload resolution and when calling, referencing and taking the address of functions or function templates. Differential Revision: https://reviews.llvm.org/D43357
* When diagnosing an ambiguity, only note the candidates that contributeRichard Smith2019-10-241-1/+1
| | | | to the ambiguity, rather than noting all viable candidates.
* [c++20] Add rewriting from comparison operators to <=> / ==.Richard Smith2019-10-193-0/+280
| | | | | | | | | | | | | | | | | This adds support for rewriting <, >, <=, and >= to a normal or reversed call to operator<=>, for rewriting != to a normal or reversed call to operator==, and for rewriting <=> and == to reversed forms of those same operators. Note that this is a breaking change for various C++17 code patterns, including some in use in LLVM. The most common patterns (where an operator== becomes ambiguous with a reversed form of itself) are still accepted under this patch, as an extension (with a warning). I'm hopeful that we can get the language rules fixed before C++20 ships, and the extension warning is aimed primarily at providing data to inform that decision. llvm-svn: 375306
* Fix regression in r360311 caused by reversed bool arguments.Richard Smith2019-05-161-0/+21
| | | | llvm-svn: 360837
* DR1687: When overload resolution selects a built-in operator, implicitRichard Smith2018-06-271-26/+18
| | | | | | | | | | | conversions are only applied to operands of class type, and the second standard conversion sequence is not applied. When diagnosing an invalid builtin binary operator, talk about the original types rather than the converted types. If these differ by a user-defined conversion, tell the user what happened. llvm-svn: 335781
* [Sema] Improve diagnostics for const- and ref-qualified member functionsJacob Bandes-Storch2017-12-311-2/+36
| | | | | | | | | | | | | | | | | | | | | | | | (Re-submission of D39937 with fixed tests.) Adjust wording for const-qualification mismatch to be a little more clear. Also add another diagnostic for a ref qualifier mismatch, which previously produced a useless error (this error path is simply very old; see rL119336): Before: error: cannot initialize object parameter of type 'X0' with an expression of type 'X0' After: error: 'this' argument to member function 'rvalue' is an lvalue, but function has rvalue ref-qualifier Reviewers: aaron.ballman Reviewed By: aaron.ballman Subscribers: lebedev.ri, cfe-commits Differential Revision: https://reviews.llvm.org/D41646 llvm-svn: 321609
* Reverted 321592: [Sema] Improve diagnostics for const- and ref-qualified ↵Jacob Bandes-Storch2017-12-311-36/+2
| | | | | | | | member functions A few tests need to be fixed llvm-svn: 321593
* [Sema] Improve diagnostics for const- and ref-qualified member functionsJacob Bandes-Storch2017-12-311-2/+36
| | | | | | | | | | | | | | | | | | | | | | | Summary: Adjust wording for const-qualification mismatch to be a little more clear. Also add another diagnostic for a ref qualifier mismatch, which previously produced a useless error (this error path is simply very old; see rL119336): Before: error: cannot initialize object parameter of type 'X0' with an expression of type 'X0' After: error: 'this' argument to member function 'rvalue' is an lvalue, but function has rvalue ref-qualifier Reviewers: rsmith, aaron.ballman Reviewed By: aaron.ballman Subscribers: lebedev.ri, aaron.ballman, cfe-commits Differential Revision: https://reviews.llvm.org/D39937 llvm-svn: 321592
* [C++17] Fix PR34970 - tweak overload resolution for class template ↵Faisal Vali2017-10-222-6/+37
| | | | | | | | | | | | | | | | | | | deduction-guides in line with WG21's p0620r0. In order to identify the copy deduction candidate, I considered two approaches: - attempt to determine whether an implicit guide is a copy deduction candidate by checking certain properties of its subsituted parameter during overload-resolution. - using one of the many bits (WillHaveBody) from FunctionDecl (that CXXDeductionGuideDecl inherits from) that are otherwise irrelevant for deduction guides After some brittle gymnastics w the first strategy, I settled on the second, although to avoid confusion and to give that bit a better name, i turned it into a member of an anonymous union. Given this identification 'bit', the tweak to overload resolution was a simple reordering of the deduction guide checks (in SemaOverload.cpp::isBetterOverloadCandidate), in-line with Jason Merrill's p0620r0 drafting which made it into the working paper. Concordant with that, I made sure the copy deduction candidate is always added. References: See https://bugs.llvm.org/show_bug.cgi?id=34970 See http://wg21.link/p0620r0 llvm-svn: 316292
* P0702R1: in class template argument deduction from a list of one element, ifRichard Smith2017-09-071-0/+31
| | | | | | | that element's type is (or is derived from) a specialization of the deduced template, skip the std::initializer_list special case. llvm-svn: 312703
* [c++1z] Add some more tests for class template argument deduction, addRichard Smith2017-02-141-1/+23
| | | | | | feature-test macro, and mark feature as done on status page. llvm-svn: 295011
* [c++1z] Synthesize implicit deduction guides from constructors on demand. RankRichard Smith2017-02-141-15/+13
| | | | | | | | | | | | | | | | | | | such guides below explicit ones, and ensure that references to the class's template parameters are not treated as forwarding references. We make a few tweaks to the wording in the current standard: 1) The constructor parameter list is copied faithfully to the deduction guide, without losing default arguments or a varargs ellipsis (which the standard wording loses by omission). 2) If the class template declares no constructors, we add a T() -> T<...> guide (which will only ever work if T has default arguments for all non-pack template parameters). 3) If the class template declares nothing that looks like a copy or move constructor, we add a T(T<...>) -> T<...> guide. #2 and #3 follow from the "pretend we had a class type with these constructors" philosophy for deduction guides. llvm-svn: 295007
* [c++1z] P0512R0: support for 'explicit' specifier on deduction-guides.Richard Smith2017-02-102-2/+27
| | | | llvm-svn: 294693
* [c++1z] P0091R3: Basic support for deducing class template arguments via ↵Richard Smith2017-02-091-0/+43
| | | | | | deduction-guides. llvm-svn: 294613
* Add a note that points to the linkage specifier for the C++ linkage errorsAlex Lorenz2016-11-021-1/+3
| | | | | | | | | | | | This commit improves the "must have C++ linkage" error diagnostics that are emitted for C++ declarations like templates and literal operators by adding an additional note that points to the appropriate extern "C" linkage specifier. rdar://19021120 Differential Revision: https://reviews.llvm.org/D26189 llvm-svn: 285823
* [c++1z] P0012R1: Implement a few remaining pieces: downgrade diagnostic forRichard Smith2016-10-221-3/+18
| | | | | | | | | | | | | | 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
* DR583, DR1512: Implement a rewrite to C++'s 'composite pointer type' rules.Richard Smith2016-10-212-0/+158
| | | | | | | | | | | | | | | | | | | | | | | | | | 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-212-158/+0
| | | | | | | | 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-212-0/+158
| | | | | | | | | | | | | | | | | | | | | | | | 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
* P0012R1: Make exception specifications be part of the type system. ThisRichard Smith2016-10-162-3/+17
| | | | | | | implements the bulk of the change (modifying the type system to include exception specifications), but not all the details just yet. llvm-svn: 284337
* Improve diagnostics for ill-formed literal operator declarations.Richard Smith2016-02-172-7/+7
| | | | | | Patch by Erik Pilkington! llvm-svn: 261034
* When pretty-printing a C++11 literal operator, don't insert whitespace betweenRichard Smith2015-10-081-1/+1
| | | | | | | the "" and the suffix; that breaks names such as 'operator""if'. For symmetry, also remove the space between the 'operator' and the '""'. llvm-svn: 249641
* [Sema] Be consistent about diagnostic wording: always use "cannot".Davide Italiano2015-08-151-3/+3
| | | | | | Discussed with Richard Smith. llvm-svn: 245162
* Implement [over.match.oper]p3 properly, by filtering the non-candidates outRichard Smith2014-04-171-6/+4
| | | | | | | when building the candidate set, rather than trying to contort name lookup into handling this. llvm-svn: 206436
* PR19452: Implement more of [over.match.oper]p3's restrictions on which ↵Richard Smith2014-04-171-2/+28
| | | | | | non-member overloaded operators can be found when no operand is of class type. We used to fail to implement this rule if there was an operand of dependent type. llvm-svn: 206435
* Don't produce duplicate notes if we have deduction failure notes when resolvingRichard Smith2013-08-141-1/+1
| | | | | | the address of an overloaded function template. llvm-svn: 188334
* FIXME fix: improving diagnostics for template arguments deduction of class ↵Larisse Voufo2013-07-191-1/+2
| | | | | | | | templates and explicit specializations This patch essentially removes all the FIXMEs following calls to DeduceTemplateArguments() that want to keep track of deduction failure info. llvm-svn: 186730
* Revert "Use function overloading instead of template specialization for ↵Larisse Voufo2013-07-191-2/+1
| | | | | | | | diagnosis of bad template argument deductions." This reverts commit a730f548325756d050d4caaa28fcbffdae8dfe95. llvm-svn: 186729
* Use function overloading instead of template specialization for diagnosis of ↵Larisse Voufo2013-07-191-1/+2
| | | | | | bad template argument deductions. llvm-svn: 186727
* Bound member function diagnostic - suggest no-args calls and note overload ↵David Blaikie2013-06-041-1/+1
| | | | | | | | | | candidates Still missing cases for templates, but this is a step in the right direction. Also omits suggestions that would be ambiguous (eg: void func(int = 0); + void func(float = 0); func;) llvm-svn: 183173
* <rdar://problem/13605348> Don't consider invalid user-defined literal ↵Douglas Gregor2013-04-101-0/+9
| | | | | | operators during overload resolution. llvm-svn: 179150
* Handle universal character names and Unicode characters outside of literals.Jordan Rose2013-01-241-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | This is a missing piece for C99 conformance. This patch handles UCNs by adding a '\\' case to LexTokenInternal and LexIdentifier -- if we see a backslash, we tentatively try to read in a UCN. If the UCN is not syntactically well-formed, we fall back to the old treatment: a backslash followed by an identifier beginning with 'u' (or 'U'). Because the spelling of an identifier with UCNs still has the UCN in it, we need to convert that to UTF-8 in Preprocessor::LookUpIdentifierInfo. Of course, valid code that does *not* use UCNs will see only a very minimal performance hit (checks after each identifier for non-ASCII characters, checks when converting raw_identifiers to identifiers that they do not contain UCNs, and checks when getting the spelling of an identifier that it does not contain a UCN). This patch also adds basic support for actual UTF-8 in the source. This is treated almost exactly the same as UCNs except that we consider stray Unicode characters to be mistakes and offer a fixit to remove them. llvm-svn: 173369
* DR1473: Do not require a space between operator"" and the ud-suffix in aRichard Smith2012-10-201-3/+2
| | | | | | literal-operator-id. llvm-svn: 166373
* Prior to adding the new "expected-no-diagnostics" directive to ↵Andy Gibbs2012-10-197-0/+7
| | | | | | VerifyDiagnosticConsumer, make the necessary adjustment to 580 test-cases which will henceforth require this new directive. llvm-svn: 166280
* Fix a small bug in the way we handle builtin candidates forEli Friedman2012-09-182-16/+28
| | | | | | relational operators of enumeration type. From the gcc testsuite. llvm-svn: 164171
* When computing the conversion sequence in overload resolutionJohn McCall2012-04-041-0/+15
| | | | | | | | for converting an empty list to a scalar, be sure to initialize the source and destination types so that comparison of conversion sequences will work in case there are multiple viable candidates. llvm-svn: 153993
* Unpluralize -Wfoo-conversions warnings for consistency.David Blaikie2012-03-151-1/+1
| | | | | | | | | | | | Err on the side of brevity and rename (while providing aliases for the original name) -Wbool-conversions, -Wint-conversions, and -Wvector-conversions for consistency with constant, literal, string, and sign conversion warnings. And name the diagnostic groups explicitly while I'm here rather than rewriting the string in the groups and sema td files. Curiously, vector-conversion is not under -Wconversion. Perhaps it should be. llvm-svn: 152776
* PR12225: The requirement that literal operators be namespace-scope functionsRichard Smith2012-03-101-0/+2
| | | | | | does not imply that such functions can't be declared at block scope. llvm-svn: 152509
* Literal operator suffixes and regular names live in separate namespaces.Richard Smith2012-03-091-0/+6
| | | | llvm-svn: 152395
* Literal operators can't have default arguments.Richard Smith2012-03-091-0/+1
| | | | llvm-svn: 152394
* Implement C++11 [lex.ext]p10 for string and character literals: a ud-suffix notRichard Smith2012-03-081-3/+5
| | | | | | | | | | | | | | | | | | starting with an underscore is ill-formed. Since this rule rejects programs that were using <inttypes.h>'s macros, recover from this error by treating the ud-suffix as a separate preprocessing-token, with a DefaultError ExtWarn. The approach of treating such cases as two tokens is under discussion for standardization, but is in any case a conforming extension and allows existing codebases to keep building while the committee makes up its mind. Reword the warning on the definition of literal operators not starting with underscores (which are, strangely, legal) to more explicitly state that such operators can't be called by literals. Remove the special-case diagnostic for hexfloats, since it was both triggering in the wrong cases and incorrect. llvm-svn: 152287
* User-defined literals: reject string and character UDLs in all places where theRichard Smith2012-03-061-1/+1
| | | | | | | | | | grammar requires a string-literal and not a user-defined-string-literal. The two constructs are still represented by the same TokenKind, in order to prevent a combinatorial explosion of different kinds of token. A flag on Token tracks whether a ud-suffix is present, in order to prevent clients from needing to look at the token's spelling. llvm-svn: 152098
* Lexing support for user-defined literals. Currently these lex as the same tokenRichard Smith2012-03-052-2/+6
| | | | | | | kinds as the underlying string literals, and we silently drop the ud-suffix; those issues will be fixed by subsequent patches. llvm-svn: 152012
* Add tests for [over.literal]. Fix a few bugs which were exposed by the tests.Richard Smith2012-03-046-0/+130
| | | | llvm-svn: 151997
* Add test for C++ DR899.Douglas Gregor2012-02-241-0/+22
| | | | llvm-svn: 151411
OpenPOWER on IntegriCloud