summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaOverload.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* DR674, PR38883, PR40238: Qualified friend lookup should look for aRichard Smith2019-01-071-0/+29
| | | | | | | | | | | | | | | | | | template specialization if there is no matching non-template function. This exposed a couple of related bugs: - we would sometimes substitute into a friend template instead of a suitable non-friend declaration; this would now crash because we'd decide the specialization of the friend is a redeclaration of itself - ADL failed to properly handle the case where an invisible local extern declaration redeclares an invisible friend Both are fixed herein: in particular, we now never make invisible friends or local extern declarations visible to name lookup unless they are the only declaration of the entity. (We already mostly did this for local extern declarations.) llvm-svn: 350505
* Prevent unreachable when checking invalid multiversion decls.Erich Keane2019-01-041-0/+5
| | | | | | | | | | | CPUSpecifc/CPUDispatch call resolution assumed that all declarations that would be passed are valid, however this was an invalid assumption. This patch deals with those situations by making the valid version take priority. Note that the checked ordering is arbitrary, since both are replaced by calls to the resolver later. Change-Id: I7ff2ec88c55a721d51bc1f39ea1a1fe242b4e45f llvm-svn: 350398
* [Basic] Extend DiagnosticEngine to store and format Qualifiers.Anastasia Stulova2019-01-041-5/+3
| | | | | | | | | | | Qualifiers can now be streamed into the DiagnosticEngine using regular << operator. If Qualifiers are empty 'unqualified' will be printed in the diagnostic otherwise regular qual syntax is used. Differential Revision: https://reviews.llvm.org/D56198 llvm-svn: 350386
* [AST] Store the callee and argument expressions of CallExpr in a trailing array.Bruno Ricci2018-12-211-60/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since CallExpr::setNumArgs has been removed, it is now possible to store the callee expression and the argument expressions of CallExpr in a trailing array. This saves one pointer per CallExpr, CXXOperatorCallExpr, CXXMemberCallExpr, CUDAKernelCallExpr and UserDefinedLiteral. Given that CallExpr is used as a base of the above classes we cannot use llvm::TrailingObjects. Instead we store the offset in bytes from the this pointer to the start of the trailing objects and manually do the casts + arithmetic. Some notes: 1.) I did not try to fit the number of arguments in the bit-fields of Stmt. This leaves some space for future additions and avoid the discussion about whether x bits are sufficient to hold the number of arguments. 2.) It would be perfectly possible to recompute the offset to the trailing objects before accessing the trailing objects. However the trailing objects are frequently accessed and benchmarks show that it is slightly faster to just load the offset from the bit-fields. Additionally, because of 1), we have plenty of space in the bit-fields of Stmt. Differential Revision: https://reviews.llvm.org/D55771 Reviewed By: rjmccall llvm-svn: 349910
* [AST][NFC] Pass the AST context to one of the ctor of DeclRefExpr.Bruno Ricci2018-12-211-4/+4
| | | | | | | | | All of the other constructors already take a reference to the AST context. This avoids calling Decl::getASTContext in most cases. Additionally move the definition of the constructor from Expr.h to Expr.cpp since it is calling DeclRefExpr::computeDependence. NFC. llvm-svn: 349901
* [OpenCL] Add generic AS to 'this' pointerMikael Nilsson2018-12-131-11/+24
| | | | | | | | | | | | | Address spaces are cast into generic before invoking the constructor. Added support for a trailing Qualifiers object in FunctionProtoType. Note: This recommits the previously reverted patch, but now it is commited together with a fix for lldb. Differential Revision: https://reviews.llvm.org/D54862 llvm-svn: 349019
* [AST] Store "UsesADL" information in CallExpr.Eric Fiselier2018-12-121-32/+32
| | | | | | | | | | | | | | | | | | | | | Summary: Currently the Clang AST doesn't store information about how the callee of a CallExpr was found. Specifically if it was found using ADL. However, this information is invaluable to tooling. Consider a tool which renames usages of a function. If the originally CallExpr was formed using ADL, then the tooling may need to additionally qualify the replacement. Without information about how the callee was found, the tooling is left scratching it's head. Additionally, we want to be able to match ADL calls as quickly as possible, which means avoiding computing the answer on the fly. This patch changes `CallExpr` to store whether it's callee was found using ADL. It does not change the size of any AST nodes. Reviewers: fowles, rsmith, klimek, shafik Reviewed By: rsmith Subscribers: aaron.ballman, riccibruno, calabrese, titus, cfe-commits Differential Revision: https://reviews.llvm.org/D55534 llvm-svn: 348977
* Revert "[OpenCL] Add generic AS to 'this' pointer"Mikael Nilsson2018-12-121-24/+11
| | | | | | Reverting because the patch broke lldb. llvm-svn: 348931
* [OpenCL] Add generic AS to 'this' pointerMikael Nilsson2018-12-121-11/+24
| | | | | | | | | | Address spaces are cast into generic before invoking the constructor. Added support for a trailing Qualifiers object in FunctionProtoType. Differential Revision: https://reviews.llvm.org/D54862 llvm-svn: 348927
* Pass PartialOverloading argument to the correct corresponding parameterEric Fiselier2018-12-111-5/+7
| | | | llvm-svn: 348864
* Use zip_longest for iterator range comparisons. NFC.Michael Kruse2018-12-101-10/+13
| | | | | | | | | | | | | | | | | | | Use zip_longest in two locations that compare iterator ranges. zip_longest allows the iteration using a range-based for-loop and to be symmetric over both ranges instead of prioritizing one over the other. In that latter case code have to handle the case that the first is longer than the second, the second is longer than the first, and both are of the same length, which must partially be checked after the loop. With zip_longest, this becomes an element comparison within the loop like the comparison of the elements themselves. The symmetry makes it clearer that neither the first and second iterators are handled differently. The iterators are not event used directly anymore, just the ranges. Differential Revision: https://reviews.llvm.org/D55468 llvm-svn: 348762
* [CodeComplete] Fix assertion failureIlya Biryukov2018-12-071-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: ...that fires when running completion inside an argument of UnresolvedMemberExpr (see the added test). The assertion that fires is from Sema::TryObjectArgumentInitialization: assert(FromClassification.isLValue()); This happens because Sema::AddFunctionCandidates does not account for object types which are pointers. It ends up classifying them incorrectly. All usages of the function outside code completion are used to run overload resolution for operators. In those cases the object type being passed is always a non-pointer type, so it's not surprising the function did not expect a pointer in the object argument. However, code completion reuses the same function and calls it with the object argument coming from UnresolvedMemberExpr, which can be a pointer if the member expr is an arrow ('->') access. Extending AddFunctionCandidates to allow pointer object types does not seem too crazy since all the functions down the call chain can properly handle pointer object types if we properly classify the object argument as an l-value, i.e. the classification of the implicitly dereferenced pointer. Reviewers: kadircet Reviewed By: kadircet Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D55331 llvm-svn: 348590
* [AST][Sema] Remove CallExpr::setNumArgsBruno Ricci2018-12-031-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CallExpr::setNumArgs is the only thing that prevents storing the arguments in a trailing array. There is only 3 places in Sema where setNumArgs is called. D54900 dealt with one of them. This patch remove the other two calls to setNumArgs in ConvertArgumentsForCall. To do this we do the following changes: 1.) Replace the first call to setNumArgs by an assertion since we are moving the responsability to allocate enough space for the arguments from Sema::ConvertArgumentsForCall to its callers (which are Sema::BuildCallToMemberFunction, and Sema::BuildResolvedCallExpr). 2.) Add a new member function CallExpr::shrinkNumArgs, which can only be used to drop arguments and then replace the second call to setNumArgs by shrinkNumArgs. 3.) Add a new defaulted parameter MinNumArgs to CallExpr and its derived classes which specifies a minimum number of argument slots to allocate. The actual number of arguments slots allocated will be max(number of args, MinNumArgs) with the extra args nulled. Note that after the creation of the call expression all of the arguments will be non-null. It is just during the creation of the call expression that some of the last arguments can be temporarily null, until filled by default arguments. 4.) Update Sema::BuildCallToMemberFunction by passing the number of parameters in the function prototype to the constructor of CXXMemberCallExpr. Here the change is pretty straightforward. 5.) Update Sema::BuildResolvedCallExpr. Here the change is more complicated since the type-checking for the function type was done after the creation of the call expression. We need to move this before the creation of the call expression, and then pass the number of parameters in the function prototype (if any) to the constructor of the call expression. 6.) Update the deserialization of CallExpr and its derived classes. Differential Revision: https://reviews.llvm.org/D54902 Reviewed By: aaron.ballman llvm-svn: 348145
* [Sema] Avoid CallExpr::setNumArgs in Sema::BuildCallToObjectOfClassTypeBruno Ricci2018-12-031-25/+23
| | | | | | | | | | | | | | | | | | | | | | CallExpr::setNumArgs is the only thing that prevents storing the arguments of a call expression in a trailing array since it might resize the argument array. setNumArgs is only called in 3 places in Sema, and for all of them it is possible to avoid it. This deals with the call to setNumArgs in BuildCallToObjectOfClassType. Instead of constructing the CXXOperatorCallExpr first and later calling setNumArgs if we have default arguments, we first construct a large enough SmallVector, do the promotion/check of the arguments, and then construct the CXXOperatorCallExpr. Incidentally this also avoid reallocating the arguments when the call operator has default arguments but this is not the primary goal. Differential Revision: https://reviews.llvm.org/D54900 Reviewed By: aaron.ballman llvm-svn: 348134
* Revert "Revert r347417 "Re-Reinstate 347294 with a fix for the failures.""Fangrui Song2018-11-301-1/+1
| | | | | | | | | It seems the two failing tests can be simply fixed after r348037 Fix 3 cases in Analysis/builtin-functions.cpp Delete the bad CodeGen/builtin-constant-p.c for now llvm-svn: 348053
* Revert r347417 "Re-Reinstate 347294 with a fix for the failures."Fangrui Song2018-11-301-1/+1
| | | | | | | | | | Kept the "indirect_builtin_constant_p" test case in test/SemaCXX/constant-expression-cxx1y.cpp while we are investigating why the following snippet fails: extern char extern_var; struct { int a; } a = {__builtin_constant_p(extern_var)}; llvm-svn: 348039
* Re-commit r347417 "Re-Reinstate 347294 with a fix for the failures."Hans Wennborg2018-11-281-1/+1
| | | | | | | This was reverted in r347656 due to me thinking it caused a miscompile of Chromium. Turns out it was the Chromium code that was broken. llvm-svn: 347756
* Revert r347417 "Re-Reinstate 347294 with a fix for the failures."Hans Wennborg2018-11-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This caused a miscompile in Chrome (see crbug.com/908372) that's illustrated by this small reduction: static bool f(int *a, int *b) { return !__builtin_constant_p(b - a) || (!(b - a)); } int arr[] = {1,2,3}; bool g() { return f(arr, arr + 3); } $ clang -O2 -S -emit-llvm a.cc -o - g() should return true, but after r347417 it became false for some reason. This also reverts the follow-up commits. r347417: > Re-Reinstate 347294 with a fix for the failures. > > Don't try to emit a scalar expression for a non-scalar argument to > __builtin_constant_p(). > > Third time's a charm! r347446: > The result of is.constant() is unsigned. r347480: > A __builtin_constant_p() returns 0 with a function type. r347512: > isEvaluatable() implies a constant context. > > Assume that we're in a constant context if we're asking if the expression can > be compiled into a constant initializer. This fixes the issue where a > __builtin_constant_p() in a compound literal was diagnosed as not being > constant, even though it's always possible to convert the builtin into a > constant. r347531: > A "constexpr" is evaluated in a constant context. Make sure this is reflected > if a __builtin_constant_p() is a part of a constexpr. llvm-svn: 347656
* Re-Reinstate 347294 with a fix for the failures.Bill Wendling2018-11-211-1/+1
| | | | | | | | | Don't try to emit a scalar expression for a non-scalar argument to __builtin_constant_p(). Third time's a charm! llvm-svn: 347417
* Revert r347364 again, the fix was incomplete.Nico Weber2018-11-211-1/+1
| | | | llvm-svn: 347389
* Reinstate 347294 with a fix for the failures.Bill Wendling2018-11-201-1/+1
| | | | | | | EvaluateAsInt() is sometimes called in a constant context. When that's the case, we need to specify it as so. llvm-svn: 347364
* Revert 347294, it turned many bots on lab.llvm.org:8011/console red.Nico Weber2018-11-201-1/+1
| | | | llvm-svn: 347314
* Use is.constant intrinsic for __builtin_constant_pBill Wendling2018-11-201-1/+1
| | | | | | | | | | | | | | | | Summary: A __builtin_constant_p may end up with a constant after inlining. Use the is.constant intrinsic if it's a variable that's in a context where it may resolve to a constant, e.g., an argument to a function after inlining. Reviewers: rsmith, shafik Subscribers: jfb, kristina, cfe-commits, nickdesaulniers, jyknight Differential Revision: https://reviews.llvm.org/D54355 llvm-svn: 347294
* [Clang][Sema]Choose a better candidate in overload function call if there is ↵Zi Xuan Wu2018-11-161-0/+25
| | | | | | | | | | | | | | | | | | | | | | a compatible vector conversion instead of ambiguous call error There are 2 function variations with vector type parameter. When we call them with argument of different vector type we would prefer to choose the variation with implicit argument conversion of compatible vector type instead of incompatible vector type. For example, typedef float __v4sf __attribute__((__vector_size__(16))); void f(vector float); void f(vector signed int); int main { __v4sf a; f(a); } Here, we'd like to choose f(vector float) but not report an ambiguous call error. Differential revision: https://reviews.llvm.org/D53417 llvm-svn: 347019
* Compound literals, enums, et al require const exprBill Wendling2018-11-091-1/+1
| | | | | | | | | | | | | | | | | | Summary: Compound literals, enums, file-scoped arrays, etc. require their initializers and size specifiers to be constant. Wrap the initializer expressions in a ConstantExpr so that we can easily check for this later on. Reviewers: rsmith, shafik Reviewed By: rsmith Subscribers: cfe-commits, jyknight, nickdesaulniers Differential Revision: https://reviews.llvm.org/D53921 llvm-svn: 346455
* NFC: Remove the ObjC1/ObjC2 distinction from clang (and related projects)Erik Pilkington2018-10-301-3/+3
| | | | | | | | | | We haven't supported compiling ObjC1 for a long time (and never will again), so there isn't any reason to keep these separate. This patch replaces LangOpts::ObjC1 and LangOpts::ObjC2 with LangOpts::ObjC. Differential revision: https://reviews.llvm.org/D53547 llvm-svn: 345637
* 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
OpenPOWER on IntegriCloud