summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaOverload.cpp
Commit message (Collapse)AuthorAgeFilesLines
* p0012: Teach resolving address of overloaded function with dependent exceptionRichard Smith2016-11-011-6/+23
| | | | | | | | specification to resolve the exception specification as part of the type check, in C++1z onwards. This is not actually part of P0012 / CWG1330 rules for when an exception specification is "needed", but is necessary for sanity. llvm-svn: 285663
* Make a function static. NFC.George Burgess IV2016-10-281-4/+3
| | | | llvm-svn: 285458
* [c++1z] P0012R1: Implement a few remaining pieces: downgrade diagnostic forRichard Smith2016-10-221-0/+10
| | | | | | | | | | | | | | mismatched dynamic exception specifications in expressions from an error to a warning, since this is no longer ill-formed in C++1z. Allow reference binding of a reference-to-non-noexcept function to a noexcept function lvalue. As defect resolutions, also allow a conditional between noexcept and non-noexcept function lvalues to produce a non-noexcept function lvalue (rather than decaying to a function pointer), and allow function template argument deduction to deduce a reference to non-noexcept function when binding to a noexcept function type. llvm-svn: 284905
* Remove unnecessary distinction between Ref_Compatible andRichard Smith2016-10-211-8/+5
| | | | | | | Ref_Compatible_With_Added_Qualification. We always treated these two values the same way. llvm-svn: 284895
* DR583, DR1512: Implement a rewrite to C++'s 'composite pointer type' rules.Richard Smith2016-10-211-17/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | This has two significant effects: 1) Direct relational comparisons between null pointer constants (0 and nullopt) and pointers are now ill-formed. This was always the case for C, and it appears that C++ only ever permitted by accident. For instance, cases like nullptr < &a are now rejected. 2) Comparisons and conditional operators between differently-cv-qualified pointer types now work, and produce a composite type that both source pointer types can convert to (when possible). For instance, comparison between 'int **' and 'const int **' is now valid, and uses an intermediate type of 'const int *const *'. Clang previously supported #2 as an extension. We do not accept the cases in #1 as an extension. I've tested a fair amount of code to check that this doesn't break it, but if it turns out that someone is relying on this, we can easily add it back as an extension. This is a re-commit of r284800. llvm-svn: 284890
* Revert "DR583, DR1512: Implement a rewrite to C++'s 'composite pointer type' ↵Renato Golin2016-10-211-15/+17
| | | | | | | | rules." This reverts commit r284800, as it failed all ARM/AArch64 bots. llvm-svn: 284811
* DR583, DR1512: Implement a rewrite to C++'s 'composite pointer type' rules.Richard Smith2016-10-211-17/+15
| | | | | | | | | | | | | | | | | | | | | | | | This has two significant effects: 1) Direct relational comparisons between null pointer constants (0 and nullopt) and pointers are now ill-formed. This was always the case for C, and it appears that C++ only ever permitted by accident. For instance, cases like nullptr < &a are now rejected. 2) Comparisons and conditional operators between differently-cv-qualified pointer types now work, and produce a composite type that both source pointer types can convert to (when possible). For instance, comparison between 'int **' and 'const int **' is now valid, and uses an intermediate type of 'const int *const *'. Clang previously supported #2 as an extension. We do not accept the cases in #1 as an extension. I've tested a fair amount of code to check that this doesn't break it, but if it turns out that someone is relying on this, we can easily add it back as an extension. llvm-svn: 284800
* Re-commit r284753, reverted in r284778, with a fix for PR30749.Richard Smith2016-10-201-25/+29
| | | | | | | | | | Original commit message: [c++1z] Teach composite pointer type computation how to compute the composite pointer type of two function pointers with different noexcept specifications. While I'm here, also teach it how to merge dynamic exception specifications. llvm-svn: 284785
* Revert r284753 "[c++1z] Teach composite pointer type computation how to ↵Hans Wennborg2016-10-201-29/+25
| | | | | | | | compute the composite" It caused PR30749. llvm-svn: 284778
* [c++1z] Teach composite pointer type computation how to compute the compositeRichard Smith2016-10-201-25/+29
| | | | | | | pointer type of two function pointers with different noexcept specifications. While I'm here, also teach it how to merge dynamic exception specifications. llvm-svn: 284753
* Fix crash on noreturn conversion in unprototyped function type. Thanks to KeithRichard Smith2016-10-201-2/+2
| | | | | | Walker for spotting the bug. llvm-svn: 284673
* Resolve exception specifications when selecting an overloaded operator.Richard Smith2016-10-191-0/+2
| | | | llvm-svn: 284556
* DR1330: instantiate exception-specifications when "needed". We previously didRichard Smith2016-10-181-0/+7
| | | | | | | | | | | | | | | | | | | | not instantiate exception specifications of functions if they were only used in unevaluated contexts (other than 'noexcept' expressions). In C++17 onwards, this becomes essential since the exception specification is now part of the function's type. Note that this means that constructs like the following no longer work: struct A { static T f() noexcept(...); decltype(f()) *p; }; ... because the decltype expression now needs the exception specification of 'f', which has not yet been parsed. llvm-svn: 284549
* P0012R1: Make exception specifications be part of the type system. ThisRichard Smith2016-10-161-14/+54
| | | | | | | implements the bulk of the change (modifying the type system to include exception specifications), but not all the details just yet. llvm-svn: 284337
* Re-commit r283722, reverted in r283750, with a fix for a CUDA-specific use ofRichard Smith2016-10-101-5/+6
| | | | | | | | | | | past-the-end iterator. Original commit message: P0035R4: Semantic analysis and code generation for C++17 overaligned allocation. llvm-svn: 283789
* Revert "P0035R4: Semantic analysis and code generation for C++17 overaligned ↵Daniel Jasper2016-10-101-6/+5
| | | | | | | | | | | | allocation." This reverts commit r283722. Breaks: Clang.SemaCUDA.device-var-init.cu Clang.CodeGenCUDA.device-var-init.cu http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-expensive/884/ llvm-svn: 283750
* P0035R4: Semantic analysis and code generation for C++17 overalignedRichard Smith2016-10-101-5/+6
| | | | | | allocation. llvm-svn: 283722
* PR25890: Fix incoherent error handling in PerformImplicitConversion andRichard Smith2016-10-061-1/+2
| | | | | | | | | | | | CheckSingleAssignmentConstraints. These no longer produce ExprError() when they have not emitted an error, and reliably inform the caller when they *have* emitted an error. This fixes some serious issues where we would fail to emit any diagnostic for invalid code and then attempt to emit code for an invalid AST, and conversely some issues where we would emit two diagnostics for the same problem. llvm-svn: 283508
* [CUDA] Clean up some comments in Sema::IsOverload. NFCJustin Lebar2016-10-031-7/+7
| | | | llvm-svn: 283121
* [CUDA] Disallow overloading destructors.Justin Lebar2016-10-031-0/+5
| | | | | | | | | | | | | | | | | | | | | | Summary: We'd attempted to allow this, but turns out we were doing a very bad job. :) Making this work properly would be a giant change in clang. For example, we'd need to make CXXRecordDecl::getDestructor() context-sensitive, because the destructor you end up with depends on where you're calling it from. For now (and hopefully for ever), just disallow overloading of destructors in CUDA. Reviewers: rsmith Subscribers: cfe-commits, tra Differential Revision: https://reviews.llvm.org/D24571 llvm-svn: 283120
* [Sema] Compare bad conversions in overload resolution.George Burgess IV2016-09-071-3/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | r280553 introduced an issue where we'd emit ambiguity errors for code like: ``` void foo(int *, int); void foo(unsigned int *, unsigned int); void callFoo() { unsigned int i; foo(&i, 0); // ambiguous: int->unsigned int is worse than int->int, // but unsigned int*->unsigned int* is better than // int*->int*. } ``` This patch fixes this issue by changing how we handle ill-formed (but valid) implicit conversions. Candidates with said conversions now always rank worse than candidates without them, and two candidates are considered to be equally bad if they both have these conversions for the same argument. Additionally, this fixes a case in C++11 where we'd complain about an ambiguity in a case like: ``` void f(char *, int); void f(const char *, unsigned); void g() { f("abc", 0); } ``` ...Since conversion to char* from a string literal is considered ill-formed in C++11 (and deprecated in C++03), but we accept it as an extension. llvm-svn: 280847
* Try contextually converting condition of constexpr if to Boolean valueIsmail Pazarbasi2016-09-071-5/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: C++1z 6.4.1/p2: If the if statement is of the form if constexpr, the value of the condition shall be a contextually converted constant expression of type bool [...] C++1z 5.20/p4: [...] A contextually converted constant expression of type bool is an expression, contextually converted to bool (Clause4), where the converted expression is a constant expression and the conversion sequence contains only the conversions above. [...] Contextually converting result of an expression `e` to a Boolean value requires `bool t(e)` to be well-formed. An explicit conversion function is only considered as a user-defined conversion for direct-initialization, which is essentially what //contextually converted to bool// requires. Also, fixes PR28470. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D24158 llvm-svn: 280838
* [Sema] Fix how we set implicit conversion kinds.George Burgess IV2016-09-031-9/+15
| | | | | | | | | | | | We have invariants we like to guarantee for the `ImplicitConversionKind`s in a `StandardConversionSequence`. These weren't being upheld in code that r280553 touched, so Richard suggested that we should fix that. See D24113. I'm not entirely sure how to go about testing this, so no test case is included. Suggestions welcome. llvm-svn: 280562
* [Sema] Relax overloading restrictions in C.George Burgess IV2016-09-021-15/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch allows us to perform incompatible pointer conversions when resolving overloads in C. So, the following code will no longer fail to compile (though it will still emit warnings, assuming the user hasn't opted out of them): ``` void foo(char *) __attribute__((overloadable)); void foo(int) __attribute__((overloadable)); void callFoo() { unsigned char bar[128]; foo(bar); // selects the char* overload. } ``` These conversions are ranked below all others, so: A. Any other viable conversion will win out B. If we had another incompatible pointer conversion in the example above (e.g. `void foo(int *)`), we would complain about an ambiguity. Differential Revision: https://reviews.llvm.org/D24113 llvm-svn: 280553
* Based on post-commit feedback over IRC with dblaikie, ideally, we should ↵Aaron Ballman2016-09-021-2/+2
| | | | | | | | have a SmallVector constructor that accepts anything which can supply a range via ADL begin()/end() calls so that we can construct the SmallVector directly from anything range-like. Since that doesn't exist right now, use a local variable instead of calling getAssocExprs() twice; NFC. llvm-svn: 280520
* Allow a C11 generic selection expression to select a function with the ↵Aaron Ballman2016-09-021-0/+25
| | | | | | overloadable attribute as the result expression without crashing. This fixes PR30201. llvm-svn: 280483
* [CUDA] Raise an error if a wrong-side call is codegen'ed.Justin Lebar2016-08-151-13/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Some function calls in CUDA are allowed to appear in semantically-correct programs but are an error if they're ever codegen'ed. Specifically, a host+device function may call a host function, but it's an error if such a function is ever codegen'ed in device mode (and vice versa). Previously, clang made no attempt to catch these errors. For the most part, they would be caught by ptxas, and reported as "call to unknown function 'foo'". Now we catch these errors and report them the same as we report other illegal calls (e.g. a call from a host function to a device function). This has a small change in error-message behavior for calls that were previously disallowed (e.g. calls from a host to a device function). Previously, we'd catch disallowed calls fairly early, before doing additional semantic checking e.g. of the call's arguments. Now we catch these illegal calls at the very end of our semantic checks, so we'll only emit a "illegal CUDA call" error if the call is otherwise well-formed. Reviewers: tra, rnk Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D23242 llvm-svn: 278759
* [Sema] Fix the wording of a comment. NFC.George Burgess IV2016-08-121-1/+1
| | | | llvm-svn: 278472
* [Sema] Fix a crash on variadic enable_if functions.George Burgess IV2016-08-121-1/+5
| | | | | | | | | | | | | Currently, when trying to evaluate an enable_if condition, we try to evaluate all arguments a user passes to a function. Given that we can't use variadic arguments from said condition anyway, not converting them is a reasonable thing to do. So, this patch makes us ignore any varargs when attempting to check an enable_if condition. We'd crash because, in order to convert an argument, we need its ParmVarDecl. Variadic arguments don't have ParmVarDecls. llvm-svn: 278471
* [CUDA] Print a "previous-decl" note when calling an illegal member fn.Justin Lebar2016-08-101-0/+1
| | | | | | | | | | | | | | | Summary: When we emit err_ref_bad_target, we should emit a "'method' declared here" note. We already do so in most places, just not in BuildCallToMemberFunction. Reviewers: tra Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D23240 llvm-svn: 278195
* [CUDA] Rename CheckCUDATarget to IsAllowedCUDACall. NFCJustin Lebar2016-08-101-4/+4
| | | | | | | | | | | | | | Summary: I want to reuse "CheckCUDAFoo" in a later patch. Also, I think IsAllowedCUDACall gets the point across more clearly. Reviewers: tra Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D23238 llvm-svn: 278193
* [CUDA] Minor comment nits.Justin Lebar2016-08-101-2/+2
| | | | llvm-svn: 278183
* [Sema] Replace mem_fn with lambdas. NFC.George Burgess IV2016-07-241-4/+6
| | | | | | | | | I'm told that some optimizers like lambdas a lot more than mem_fn. Given that the readability difference is basically nil, and we seem to use lambdas basically everywhere else, it seems sensible to just use lambdas. llvm-svn: 276577
* Deprecated (legacy) string literal conversion to 'char *' causes strange ↵Dmitry Polukhin2016-07-191-2/+0
| | | | | | | | | | | | | | overloading resolution It's a patch for PR28050. Seems like overloading resolution wipes out the first standard conversion sequence (before user-defined conversion) in case of deprecated string literal conversion. Differential revision: https://reviews.llvm.org/D21228 Patch by Alexander Makarov llvm-svn: 275970
* [CUDA] Don't assume that destructors can't be overloaded.Justin Lebar2016-07-121-2/+1
| | | | | | | | | | | | | | | Summary: You can overload a destructor in CUDA, and SemaOverload needs to be tweaked not to crash when it sees an explicit call to an overloaded destructor. Reviewers: rsmith Subscribers: cfe-commits, tra Differential Revision: http://reviews.llvm.org/D21912 llvm-svn: 275231
* [MS ABI] Pick an inheritance model if we resolve an overload setDavid Majnemer2016-06-301-0/+3
| | | | | | | | | | | | | We didn't assign an inheritance model for 'Foo' if the event an exrepssion like '&Foo::Bar' occured if 'Bar' could resolve to multiple functions. Once the overload set is resolved to a particular member, we enforce a specific inheritance model. This fixes PR28360. llvm-svn: 274202
* P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991:Richard Smith2016-06-281-43/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Replace inheriting constructors implementation with new approach, voted into C++ last year as a DR against C++11. Instead of synthesizing a set of derived class constructors for each inherited base class constructor, we make the constructors of the base class visible to constructor lookup in the derived class, using the normal rules for using-declarations. For constructors, UsingShadowDecl now has a ConstructorUsingShadowDecl derived class that tracks the requisite additional information. We create shadow constructors (not found by name lookup) in the derived class to model the actual initialization, and have a new expression node, CXXInheritedCtorInitExpr, to model the initialization of a base class from such a constructor. (This initialization is special because it performs real perfect forwarding of arguments.) In cases where argument forwarding is not possible (for inalloca calls, variadic calls, and calls with callee parameter cleanup), the shadow inheriting constructor is not emitted and instead we directly emit the initialization code into the caller of the inherited constructor. Note that this new model is not perfectly compatible with the old model in some corner cases. In particular: * if B inherits a private constructor from A, and C uses that constructor to construct a B, then we previously required that A befriends B and B befriends C, but the new rules require A to befriend C directly, and * if a derived class has its own constructors (and so its implicit default constructor is suppressed), it may still inherit a default constructor from a base class llvm-svn: 274049
* Use even more ArrayRefsDavid Majnemer2016-06-241-4/+4
| | | | | | No functional change is intended, just a small refactoring. llvm-svn: 273650
* [Sema] Teach CheckPlaceholderExpr about unaddressable functions.George Burgess IV2016-06-081-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Given the following C++: ``` void foo(); void foo() __attribute__((enable_if(false, ""))); bool bar() { auto P = foo; return P == foo; } ``` We'll currently happily (and correctly) resolve `foo` to the `foo` overload without `enable_if` when assigning to `P`. However, we'll complain about an ambiguous overload on the `P == foo` line, because `Sema::CheckPlaceholderExpr` doesn't recognize that there's only one `foo` that could possibly work here. This patch teaches `Sema::CheckPlaceholderExpr` how to properly deal with such cases. Grepping for other callers of things like `Sema::ResolveAndFixSingleFunctionTemplateSpecialization`, it *looks* like this is the last place that needed to be fixed up. If I'm wrong, I'll see if there's something we can do that beats what amounts to whack-a-mole with bugs. llvm-svn: 272080
* Preserve the FoundDecl when performing overload resolution for constructors.Richard Smith2016-05-111-80/+66
| | | | | | | | | This is in preparation for C++ P0136R1, which switches the model for inheriting constructors over from synthesizing a constructor to finding base class constructors (via using shadow decls) when looking for derived class constructors. llvm-svn: 269231
* [MSVC] Implementation of __unaligned as a proper type qualifierAndrey Bokhanko2016-05-111-1/+21
| | | | | | | | | | | This patch implements __unaligned (MS extension) as a proper type qualifier (before that, it was implemented as an ignored attribute). It also fixes PR27367 and PR27666. Differential Revision: http://reviews.llvm.org/D20103 llvm-svn: 269220
* [Sema] Fix value-dependent enable_if bug.George Burgess IV2016-05-111-13/+6
| | | | | | | | | | | | | | | This patch fixes a bug where we would assume all value-dependent enable_if conditions give successful results. Instead, we consider value-dependent enable_if conditions to always fail. While this isn't ideal, this is the best we can realistically do without changing both enable_if's semantics and large parts of Sema (specifically, all of the parts that don't expect type dependence to come out of nowhere, and that may interact with overload resolution). Differential Revision: http://reviews.llvm.org/D20130 llvm-svn: 269154
* [Sema] Fix an overload resolution bug with enable_if.George Burgess IV2016-05-101-21/+37
| | | | | | | | | | | | | | | | | | | | | | Currently, if clang::isBetterOverloadCandidate encounters an enable_if attribute on either candidate that it's inspecting, it will ignore all lower priority attributes (e.g. pass_object_size). This is problematic in cases like: ``` void foo(char *c) __attribute__((enable_if(1, ""))); void foo(char *c __attribute__((pass_object_size(0)))) __attribute__((enable_if(1, ""))); ``` ...Because we would ignore the pass_object_size attribute in the second `foo`, and consider any call to `foo` to be ambiguous. This patch makes overload resolution consult further tiebreakers (e.g. pass_object_size) if two candidates have equally good enable_if attributes. llvm-svn: 269005
* Enable support for __float128 in Clang and enable it on pertinent platformsNemanja Ivanovic2016-05-091-7/+23
| | | | | | | | | | | | | | | | | | This patch corresponds to reviews: http://reviews.llvm.org/D15120 http://reviews.llvm.org/D19125 It adds support for the __float128 keyword, literals and target feature to enable it. Based on the latter of the two aforementioned reviews, this feature is enabled on Linux on i386/X86 as well as SystemZ. This is also the second attempt in commiting this feature. The first attempt did not enable it on required platforms which caused failures when compiling type_traits with -std=gnu++11. If you see failures with compiling this header on your platform after this commit, it is likely that your platform needs to have this feature enabled. llvm-svn: 268898
* Revert r268727, it caused PR27666.Nico Weber2016-05-061-4/+0
| | | | llvm-svn: 268736
* [MSVC] Implementation of __unaligned as a proper type qualifierAndrey Bokhanko2016-05-061-0/+4
| | | | | | | | | | | This patch implements __unaligned (MS extension) as a proper type qualifier (before that, it was implemented as an ignored attribute). It also fixes PR27367. Differential Revision: http://reviews.llvm.org/D19654 llvm-svn: 268727
* [Sema] Specify the underlying type for an enum. NFC.George Burgess IV2016-04-291-1/+1
| | | | llvm-svn: 268113
* Warn if function or variable cannot be implicitly instantiatedSerge Pavlov2016-04-191-5/+2
| | | | | | | | | | | | With this patch compiler emits warning if it tries to make implicit instantiation of a template but cannot find the template definition. The warning can be suppressed by explicit instantiation declaration or by command line options -Wundefined-var-template and -Wundefined-func-template. The implementation follows the discussion of http://reviews.llvm.org/D12326. Differential Revision: http://reviews.llvm.org/D16396 llvm-svn: 266719
* Revert 266186 as it breaks anything that includes type_traits on some platformsNemanja Ivanovic2016-04-151-23/+7
| | | | | | | | | | Since this patch provided support for the __float128 type but disabled it on all platforms by default, some platforms can't compile type_traits with -std=gnu++11 since there is a specialization with __float128. This reverts the patch until D19125 is approved (i.e. we know which platforms need this support enabled). llvm-svn: 266460
* Enable support for __float128 in ClangNemanja Ivanovic2016-04-131-7/+23
| | | | | | | | | | | | | | | | This patch corresponds to review: http://reviews.llvm.org/D15120 It adds support for the __float128 keyword, literals and a target feature to enable it. This support is disabled by default on all targets and any target that has support for this type is free to add it. Based on feedback that I've received from target maintainers, this appears to be the right thing for most targets. I have not heard from the maintainers of X86 which I believe supports this type. I will subsequently investigate the impact of enabling this on X86. llvm-svn: 266186
OpenPOWER on IntegriCloud