summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaOverload.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Use llvm::{all,any,none}_of instead std::{all,any,none}_of. NFCFangrui Song2018-10-201-1/+1
| | | | llvm-svn: 344859
* [Sema][OpenCL] Improve diagnostics for not viable overloadable function ↵Andrew Savonichev2018-10-111-1/+2
| | | | | | | | | | | | | | | | | | | candidates Summary: Allowed extension name (that ought to be disabled) printing in the note message. This diagnostic was proposed here: https://reviews.llvm.org/D51341 Reviewers: Anastasia, yaxunl Reviewed By: Anastasia Subscribers: cfe-commits, asavonic, bader Differential Revision: https://reviews.llvm.org/D52292 llvm-svn: 344246
* PR39231: fix null dereference when diagnosing deduction failure due toRichard Smith2018-10-091-1/+1
| | | | | | conflicting values for a non-type pack. llvm-svn: 344070
* llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)Fangrui Song2018-09-261-2/+1
| | | | | | | | | | | | | | Summary: The convenience wrapper in STLExtras is available since rL342102. Reviewers: rsmith, #clang, dblaikie Reviewed By: rsmith, #clang Subscribers: mgrang, arphaman, kadircet, cfe-commits Differential Revision: https://reviews.llvm.org/D52576 llvm-svn: 343147
* PR33222: Require the declared return type not the actual return type toRichard Smith2018-09-101-1/+2
| | | | | | | | | match when checking for redeclaration of a function template. This properly handles differences in deduced return types, particularly when performing redeclaration checks for a friend function template. llvm-svn: 341778
* Port getLocEnd -> getEndLocStephen Kelly2018-08-091-1/+1
| | | | | | | | | | Reviewers: teemperor! Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D50351 llvm-svn: 339386
* Port getLocStart -> getBeginLocStephen Kelly2018-08-091-117/+104
| | | | | | | | | | Reviewers: teemperor! Subscribers: jholewinski, whisperity, jfb, cfe-commits Differential Revision: https://reviews.llvm.org/D50350 llvm-svn: 339385
* Append new attributes to the end of an AttributeList.Michael Kruse2018-08-031-34/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recommit of r335084 after revert in r335516. ... instead of prepending it at the beginning (the original behavior since implemented in r122535 2010-12-23). This builds up an AttributeList in the the order in which the attributes appear in the source. The reverse order caused nodes for attributes in the AST (e.g. LoopHint) to be in the reverse order, and therefore printed in the wrong order in -ast-dump. Some TODO comments mention this. The order was explicitly reversed for enable_if attribute overload resolution and name mangling, which is not necessary anymore with this patch. The change unfortunately has some secondary effect, especially on diagnostic output. In the simplest cases, the CHECK lines or expected diagnostic were changed to the the new output. If the kind of error/warning changed, the attributes' order was changed instead. This unfortunately causes some 'previous occurrence here' hints to be textually after the main marker. This typically happens when attributes are merged, but are incompatible to each other. Interchanging the role of the the main and note SourceLocation will also cause the case where two different declaration's attributes (in contrast to multiple attributes of the same declaration) are merged to be reverse. There is no easy fix because sometimes previous attributes are merged into a new declaration's attribute list, sometimes new attributes are added to a previous declaration's attribute list. Since 'previous occurrence here' pointing to locations after the main marker is not rare, I left the markers as-is; it is only relevant when the attributes are declared in the same declaration anyway. Differential Revision: https://reviews.llvm.org/D48100 llvm-svn: 338800
* Add missing temporary materialization conversion on left-hand side of .Richard Smith2018-07-271-0/+7
| | | | | | | | | in some member function calls. Specifically, when calling a conversion function, we would fail to create the AST node representing materialization of the class object. llvm-svn: 338135
* Implement cpu_dispatch/cpu_specific MultiversioningErich Keane2018-07-201-8/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As documented here: https://software.intel.com/en-us/node/682969 and https://software.intel.com/en-us/node/523346. cpu_dispatch multiversioning is an ICC feature that provides for function multiversioning. This feature is implemented with two attributes: First, cpu_specific, which specifies the individual function versions. Second, cpu_dispatch, which specifies the location of the resolver function and the list of resolvable functions. This is valuable since it provides a mechanism where the resolver's TU can be specified in one location, and the individual implementions each in their own translation units. The goal of this patch is to be source-compatible with ICC, so this implementation diverges from the ICC implementation in a few ways: 1- Linux x86/64 only: This implementation uses ifuncs in order to properly dispatch functions. This is is a valuable performance benefit over the ICC implementation. A future patch will be provided to enable this feature on Windows, but it will obviously more closely fit ICC's implementation. 2- CPU Identification functions: ICC uses a set of custom functions to identify the feature list of the host processor. This patch uses the cpu_supports functionality in order to better align with 'target' multiversioning. 1- cpu_dispatch function def/decl: ICC's cpu_dispatch requires that the function marked cpu_dispatch be an empty definition. This patch supports that as well, however declarations are also permitted, since the linker will solve the issue of multiple emissions. Differential Revision: https://reviews.llvm.org/D47474 llvm-svn: 337552
* Sema: Fix explicit address space cast in C++Yaxun Liu2018-07-201-0/+9
| | | | | | | | | | | | | | | | | | | | | Currently clang does not allow implicit cast of a pointer to a pointer type in different address space but allows C-style cast of a pointer to a pointer type in different address space. However, there is a bug in Sema causing incorrect Cast Expr in AST for the latter case, which in turn results in invalid LLVM IR in codegen. This is because Sema::IsQualificationConversion returns true for a cast of pointer to a pointer type in different address space, which in turn allows a standard conversion and results in a cast expression with no op in AST. This patch fixes that by let Sema::IsQualificationConversion returns false for a cast of pointer to a pointer type in different address space, which in turn disallows standard conversion, implicit cast, and static cast. Finally it results in an reinterpret cast and correct conversion kind is set. Differential Revision: https://reviews.llvm.org/D49294 llvm-svn: 337540
* Fix template argument deduction when a parameter pack has a valueRichard Smith2018-07-191-0/+19
| | | | | | | | | | | | | | provided by an outer template. We made the incorrect assumption in various places that the only way we can have any arguments already provided for a pack during template argument deduction was from a partially-specified pack. That's not true; we can also have arguments from an enclosing already-instantiated template, and that can even result in the function template's own pack parameters having a fixed length and not being packs for the purposes of template argument deduction. llvm-svn: 337481
* DR330: look through array types when forming the cv-decomposition of a type.Richard Smith2018-07-111-13/+3
| | | | | | | | | | This allows more qualification conversions, eg. conversion from 'int *(*)[]' -> 'const int *const (*)[]' is now permitted, along with all the consequences of that: more types are similar, more cases are permitted by const_cast, and conversely, fewer "casting away constness" cases are permitted by reinterpret_cast. llvm-svn: 336745
* PR37979: integral promotions in C++ treat enum bit-fields like enums,Richard Smith2018-06-281-0/+13
| | | | | | | | | | | | | | | | | not like bit-fields. We used to get this right "by accident", because conversions for the selected built-in overloaded operator would convert the enum bit-field to its corresponding underlying type early. But after DR1687 that no longer happens. Technically this change should also apply to C, where bit-fields only have special promotion rules if the bit-field's declared type is _Bool, int, signed int, or unsigned int, but for GCC compatibility we only look at the bit-width and not the underlying type when performing bit-field integral promotions in C. llvm-svn: 335925
* DR1687: When overload resolution selects a built-in operator, implicitRichard Smith2018-06-271-13/+14
| | | | | | | | | | | 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
* Revert "Append new attributes to the end of an AttributeList."Michael Kruse2018-06-251-13/+34
| | | | | | | This reverts commit r335084 as requested by David Jones and Eric Christopher because of differences of emitted warnings. llvm-svn: 335516
* [Sema] Updated note for address spaces to print the type.Anastasia Stulova2018-06-221-3/+1
| | | | | | This allows to reuse the same diagnostic for OpenCL or CUDA. llvm-svn: 335358
* [Sema] Fix overloaded static functions for templatesIvan Donchevskii2018-06-211-41/+39
| | | | | | | | Apply almost the same fix as https://reviews.llvm.org/D36390 but for templates. Differential Revision: https://reviews.llvm.org/D43453 llvm-svn: 335211
* Append new attributes to the end of an AttributeList.Michael Kruse2018-06-191-34/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ... instead of prepending it at the beginning (the original behavior since implemented in r122535 2010-12-23). This builds up an AttributeList in the the order in which the attributes appear in the source. The reverse order caused nodes for attributes in the AST (e.g. LoopHint) to be in the reverse, and therefore printed in the wrong order by -ast-dump. Some TODO comments mention this. The order was explicitly reversed for enable_if attribute overload resolution and name mangling, which is not necessary anymore with this patch. The change unfortunately has some secondary effects, especially for diagnostic output. In the simplest cases, the CHECK lines or expected diagnostic were changed to the the new output. If the kind of error/warning changed, the attribute's order was changed instead. It also causes some 'previous occurrence here' hints to be textually after the main marker. This typically happens when attributes are merged, but are incompatible. Interchanging the role of the the main and note SourceLocation will also cause the case where two different declaration's attributes (in contrast to multiple attributes of the same declaration) are merged to be reversed. There is no easy fix because sometimes previous attributes are merged into a new declaration's attribute list, sometimes new attributes are added to a previous declaration's attribute list. Since 'previous occurrence here' pointing to locations after the main marker is not rare, I left the markers as-is; it is only relevant when the attributes are declared in the same declaration anyway, which often is on the same line. Differential Revision: https://reviews.llvm.org/D48100 llvm-svn: 335084
* Fix overload resolution between Ptr-To-Member and BoolErich Keane2018-06-121-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | As reported here (https://bugs.llvm.org/show_bug.cgi?id=19808) and discovered independently when looking at plum-hall tests, we incorrectly implemented over.ics.rank, which says "A conversion that is not a conversion of a pointer, or pointer to member, to bool is better than another conversion that is such a conversion.". In the current Draft (N4750), this is phrased slightly differently in paragraph 4.1: A conversion that does not convert a pointer, a pointer to member, or std::nullptr_t to bool is better than one that does. The comment on isPointerConversionToBool (the changed function) also confirms that this is the case (note outdated reference): isPointerConversionToBool - Determines whether this conversion is a conversion of a pointer or pointer-to-member to bool. This is used as part of the ranking of standard conversion sequences (C++ 13.3.3.2p4). However, despite this comment, it didn't check isMemberPointerType on the 'FromType', presumably incorrectly assuming that 'isPointerType' matched it. This patch fixes this by adding isMemberPointerType to this function. Additionally, member function pointers are just MemberPointerTypes that point to functions insted of data, so that is fixed in this patch as well. llvm-svn: 334503
* [Sema] Use %sub to cleanup overload diagnosticsEric Fiselier2018-05-301-105/+116
| | | | | | | | | | | | | | | | | | | | Summary: This patch adds the newly added `%sub` diagnostic modifier to cleanup repetition in the overload candidate diagnostics. I think this should be good to go. @rsmith: Some of the notes now emit `function template` where they only said `function` previously. It seems OK to me, but I would like your sign off on it. Reviewers: rsmith, EricWF Reviewed By: EricWF Subscribers: cfe-commits, rsmith Differential Revision: https://reviews.llvm.org/D47101 llvm-svn: 333485
* Allow dllimport non-type template arguments in C++17Reid Kleckner2018-05-101-3/+4
| | | | | | | | | | | Summary: Fixes PR35772. Reviewers: rsmith Differential Revision: https://reviews.llvm.org/D43320 llvm-svn: 332018
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-091-39/+39
| | | | | | | | | | | | | | | | | | | This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
* [C++2a] Implement operator<=> CodeGen and ExprConstantEric Fiselier2018-05-071-9/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch tackles long hanging fruit for the builtin operator<=> expressions. It is currently needs some cleanup before landing, but I want to get some initial feedback. The main changes are: * Lookup, build, and store the required standard library types and expressions in `ASTContext`. By storing them in ASTContext we don't need to store (and duplicate) the required expressions in the BinaryOperator AST nodes. * Implement [expr.spaceship] checking, including diagnosing narrowing conversions. * Implement `ExprConstant` for builtin spaceship operators. * Implement builitin operator<=> support in `CodeGenAgg`. Initially I emitted the required comparisons using `ScalarExprEmitter::VisitBinaryOperator`, but this caused the operand expressions to be emitted once for every required cmp. * Implement [builtin.over] with modifications to support the intent of P0946R0. See the note on `BuiltinOperatorOverloadBuilder::addThreeWayArithmeticOverloads` for more information about the workaround. Reviewers: rsmith, aaron.ballman, majnemer, rnk, compnerd, rjmccall Reviewed By: rjmccall Subscribers: rjmccall, rsmith, aaron.ballman, junbuml, mgorny, cfe-commits Differential Revision: https://reviews.llvm.org/D45476 llvm-svn: 331677
* Track the result of evaluating a computed noexcept specification on theRichard Smith2018-05-031-3/+3
| | | | | | | | | | | | | | FunctionProtoType. We previously re-evaluated the expression each time we wanted to know whether the type is noexcept or not. We now evaluate the expression exactly once. This is not quite "no functional change": it fixes a crasher bug during AST deserialization where we would try to evaluate the noexcept specification in a situation where we have not deserialized sufficient portions of the AST to permit such evaluation. llvm-svn: 331428
* Implement P0482R2, support for char8_t type.Richard Smith2018-05-011-0/+2
| | | | | | | | | | | | This is not yet part of any C++ working draft, and so is controlled by the flag -fchar8_t rather than a -std= flag. (The GCC implementation is controlled by a flag with the same name.) This implementation is experimental, and will be removed or revised substantially to match the proposal as it makes its way through the C++ committee. llvm-svn: 331244
* [Sema] Disable built-in increment operator for bool in overload resolution ↵Jan Korous2018-04-181-5/+11
| | | | | | | | | | | | | | | | | in C++17 Following: https://llvm.org/svn/llvm-project/cfe/trunk@329804 For C++17 the wording of [over.built] p4 excluded bool: For every pair (T , vq), where T is an arithmetic type other than bool, there exist candidate operator functions of the form vq T & operator++(vq T &); T operator++(vq T &, int); Differential Revision: https://reviews.llvm.org/D45569 llvm-svn: 330254
* Limit types of builtins that can be redeclared.Erich Keane2018-04-161-0/+7
| | | | | | | | | | | | | | | | | | As reported here: https://bugs.llvm.org/show_bug.cgi?id=37033 Any usage of a builtin function that uses a va_list by reference will cause an assertion when redeclaring it. After discussion in the review, it was concluded that the correct way of accomplishing this fix is to make attempts to redeclare certain builtins an error. Unfortunately, doing this limitation for all builtins is likely a breaking change, so this commit simply limits it to types with custom type checking and those that take a reference. Two tests needed to be updated to make this work. Differential Revision: https://reviews.llvm.org/D45383 llvm-svn: 330160
* [Sema] Fix built-in decrement operator overload resolutionJan Korous2018-04-111-3/+5
| | | | | | | | | | | | | | | | | C++ [over.built] p4: "For every pair (T, VQ), where T is an arithmetic type other than bool, and VQ is either volatile or empty, there exist candidate operator functions of the form VQ T& operator--(VQ T&); T operator--(VQ T&, int); " The bool type is in position LastPromotedIntegralType in BuiltinOperatorOverloadBuilder::getArithmeticType::ArithmeticTypes, but addPlusPlusMinusMinusArithmeticOverloads() was expecting it at position 0. Differential Revision: https://reviews.llvm.org/D44988 rdar://problem/34255516 llvm-svn: 329804
* Fix typos in clangAlexander Kornienko2018-04-061-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Found via codespell -q 3 -I ../clang-whitelist.txt Where whitelist consists of: archtype cas classs checkk compres definit frome iff inteval ith lod methode nd optin ot pres statics te thru Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few files that have dubious fixes reverted.) Differential revision: https://reviews.llvm.org/D44188 llvm-svn: 329399
* Revert "Set calling convention for CUDA kernel"Artem Belevich2018-04-031-0/+1
| | | | | | | This reverts r328795 which introduced an issue with referencing __global__ function templates. More details in the original review D44747. llvm-svn: 329099
* Set calling convention for CUDA kernelYaxun Liu2018-03-291-1/+0
| | | | | | | | | | | This patch sets target specific calling convention for CUDA kernels in IR. Patch by Greg Rodgers. Revised and lit test added by Yaxun Liu. Differential Revision: https://reviews.llvm.org/D44747 llvm-svn: 328795
* [clang] Change std::sort to llvm::sort in response to r327219Mandeep Singh Grang2018-03-271-2/+2
| | | | | | | | | | | r327219 added wrappers to std::sort which randomly shuffle the container before sorting. This will help in uncovering non-determinism caused due to undefined sorting order of objects having the same key. To make use of that infrastructure we need to invoke llvm::sort instead of std::sort. llvm-svn: 328636
* [SemaOverload] Fixed crash on code completionIlya Biryukov2018-03-091-6/+11
| | | | | | | | | | | | | | | | | | Summary: The relevant failing assertion message is: ../tools/clang/lib/Sema/SemaInit.cpp:8411: PerformCopyInitialization(): Assertion `InitE && "No initialization expression?"' failed. See the added test case for a repro. Reviewers: bkramer, sammccall, ioeric, hokein Reviewed By: sammccall Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D44300 llvm-svn: 327134
* [Sema] Classify conversions from enum to float as narrowingMikhail Maltsev2018-02-211-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: According to [dcl.init.list]p7: A narrowing conversion is an implicit conversion - ... - from an integer type or unscoped enumeration type to a floating-point type, except where the source is a constant expression and the actual value after conversion will fit into the target type and will produce the original value when converted back to the original type, or - ... Currently clang does not handle the 'unscoped enumeration' case. This patch fixes the corresponding check. Reviewers: faisalv, rsmith, rogfer01 Reviewed By: rogfer01 Subscribers: rogfer01, cfe-commits Differential Revision: https://reviews.llvm.org/D42545 llvm-svn: 325668
* [NFC] Fixup comment with function name, actually incorrect name!Erich Keane2018-01-291-3/+2
| | | | llvm-svn: 323679
* [Sema] Allow conversion between long double and __float128.Benjamin Kramer2018-01-171-2/+2
| | | | | | | We should only ban this if long double is a double double. x86's 80 bit long double is fine and supported by the backend. llvm-svn: 322779
* Track in the AST whether the operand to a UnaryOperator can overflow and ↵Aaron Ballman2018-01-091-3/+3
| | | | | | then use that logic when evaluating constant expressions and emitting codegen. llvm-svn: 322074
* Implement Attribute Target MultiVersioningErich Keane2018-01-081-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | GCC's attribute 'target', in addition to being an optimization hint, also allows function multiversioning. We currently have the former implemented, this is the latter's implementation. This works by enabling functions with the same name/signature to coexist, so that they can all be emitted. Multiversion state is stored in the FunctionDecl itself, and SemaDecl manages the definitions. Note that it ends up having to permit redefinition of functions so that they can all be emitted. Additionally, all versions of the function must be emitted, so this also manages that. Note that this includes some additional rules that GCC does not, since defining something as a MultiVersion function after a usage has been made illegal. The only 'history rewriting' that happens is if a function is emitted before it has been converted to a multiversion'ed function, at which point its name needs to be changed. Function templates and virtual functions are NOT yet supported (not supported in GCC either). Additionally, constructors/destructors are disallowed, but the former is planned. llvm-svn: 322028
* No -fsanitize=function warning when calling noexcept function through ↵Stephan Bergmann2018-01-051-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | non-noexcept pointer in C++17 As discussed in the mail thread <https://groups.google.com/a/isocpp.org/forum/ #!topic/std-discussion/T64_dW3WKUk> "Calling noexcept function throug non- noexcept pointer is undefined behavior?", such a call should not be UB. However, Clang currently warns about it. This change removes exception specifications from the function types recorded for -fsanitize=function, both in the functions themselves and at the call sites. That means that calling a non-noexcept function through a noexcept pointer will also not be flagged as UB. In the review of this change, that was deemed acceptable, at least for now. (See the "TODO" in compiler-rt test/ubsan/TestCases/TypeCheck/Function/function.cpp.) To remove exception specifications from types, the existing internal ASTContext::getFunctionTypeWithExceptionSpec was made public, and some places otherwise unrelated to this change have been adapted to call it, too. This is the cfe part of a patch covering both cfe and compiler-rt. Differential Revision: https://reviews.llvm.org/D40720 llvm-svn: 321859
* Fix and simplify handling of return type for (generic) lambda conversion ↵Richard Smith2018-01-021-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | function to function pointer. Previously, we would: * compute the type of the conversion function and static invoker as a side-effect of template argument deduction for a conversion * re-compute the type as part of deduced return type deduction when building the conversion function itself Neither of these turns out to be quite correct. There are other ways to reach a declaration of the conversion function than in a conversion (such as an explicit call or friend declaration), and performing auto deduction causes the function type to be rebuilt in the context of the lambda closure type (which is different from the context in which it originally appeared, resulting in spurious substitution failures for constructs that are valid in one context but not the other, such as the use of an enclosing class's "this" pointer). This patch switches us to use a different strategy: as before, we use the declared type of the operator() to form the type of the conversion function and invoker, but we now populate that type as part of return type deduction for the conversion function. And the invoker is now treated as simply being an implementation detail of building the conversion function, and isn't given special treatment by template argument deduction for the conversion function any more. llvm-svn: 321683
* [Sema] Improve diagnostics for const- and ref-qualified member functionsJacob Bandes-Storch2017-12-311-2/+21
| | | | | | | | | | | | | | | | | | | | | | | | (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-21/+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/+21
| | | | | | | | | | | | | | | | | | | | | | | 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
* Silence a bunch of implicit fallthrough warningsAdrian Prantl2017-12-191-5/+5
| | | | llvm-svn: 321115
* Now that C++17 is official (https://www.iso.org/standard/68564.html), start ↵Aaron Ballman2017-12-041-1/+1
| | | | | | changing the C++1z terminology over to C++17. NFC intended, these are all mechanical changes. llvm-svn: 319688
* [c++2a] P0515R3: Support for overloaded operator<=>.Richard Smith2017-12-011-0/+3
| | | | | | No CodeGen support for MSABI yet, we don't know how to mangle this there. llvm-svn: 319513
* BuiltinOperatorOverloadBuilder: Don't consider types that are unavailable on ↵Hans Wennborg2017-11-151-71/+70
| | | | | | | | | | | | | the target (PR35174) In the PR, Clang ended up in a situation where it tried to mangle the __float128 type, which isn't supported when targetingt MSVC, because Clang instantiated a variable template with that type when searching for a conversion to use in an arithmetic expression. Differential revision: https://reviews.llvm.org/D39579 llvm-svn: 318309
* [Sema] Stable sort OverloadCandidates to remove non-deterministic orderingMandeep Singh Grang2017-11-141-1/+1
| | | | | | | | | | | | | | | | Summary: This fixes failure in Misc/diag-template-diffing.cpp uncovered by D39245. Reviewers: rjmccall, rsmith Reviewed By: rjmccall Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D39944 llvm-svn: 318121
* [c++17] Refine resolution of constructor / conversion function disambiguation.Richard Smith2017-11-011-14/+12
| | | | | | | | | | | | Given a choice between a constructor call and a conversion function in C++17, we prefer the constructor for direct-initialization and the conversion function for copy-initialization, matching the behavior in C++14 and before. The guaranteed copy elision rules were not intended to change the meaning of such code (other than by removing unnecessary copy constructor calls). This tweak will be raised with CWG. llvm-svn: 317066
OpenPOWER on IntegriCloud