summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaOverload.cpp
Commit message (Collapse)AuthorAgeFilesLines
* FixOverloadedFunctionReference needs to rebuild member accesses of John McCall2011-04-271-4/+11
| | | | | | | | instance methods to have bound-member type. Fixing that broke __unknown_anytype, which I've in turn fixed. llvm-svn: 130266
* When comparing Objective-C pointers during overload resolution toDouglas Gregor2011-04-271-12/+17
| | | | | | | | | | | determine which is a better conversion to "void*", be sure to perform the comparison using the safe-for-id ASTContext::canAssignObjCInterfaces() rather than the asserts-with-id ASTContext::canAssignObjCInterfaces(). Fixes <rdar://problem/9327203>. llvm-svn: 130259
* When computing Objective-C pointer conversions in C++, retainDouglas Gregor2011-04-261-5/+39
| | | | | | | | | | | the qualifiers (e.g., GC qualifiers) on the type we're converting from, rather than just blindly adopting the qualifiers of the type we're converting to or dropping qualifiers altogether. As an added bonus, properly diagnose GC qualifier mismatches to eliminate a crash in the overload resolution failure diagnostics. llvm-svn: 130255
* Make yet another placeholder type, this one marking that an expression is a ↵John McCall2011-04-261-52/+124
| | | | | | | | | | | bound member function, i.e. something of the form 'x.f' where 'f' is a non-static member function. Diagnose this in the general case. Some of the new diagnostics are probably worse than the old ones, but we now get this right much more universally, and there's certainly room for improvement in the diagnostics. llvm-svn: 130239
* Minor tweak to avoid having to dig through canonical types multiple times ↵Douglas Gregor2011-04-251-3/+6
| | | | | | when checking a qualification conversion llvm-svn: 130136
* In IsUserDefinedConversion try to recover from RequireCompleteType returning ↵Argyrios Kyrtzidis2011-04-221-1/+5
| | | | | | | | true. Fixes an assertion later on, rdar://9122862 & http://llvm.org/PR9460. llvm-svn: 130000
* For the purposes of overload resolution, consider a conversion from anDouglas Gregor2011-04-151-1/+1
| | | | | | | | | Objective-C pointer to void* as a "conversion to void*". This allows us to prefer an Objective-C object pointer conversion to a superclass object pointer over an Objective-C object pointer conversion to cv-void*. Fixes PR9735. llvm-svn: 129603
* Add support for C++0x's range-based for loops, as specified by the C++11 ↵Richard Smith2011-04-141-4/+9
| | | | | | draft standard (N3291). llvm-svn: 129541
* Match pointer of compatible vection types. Fariborz Jahanian2011-04-141-0/+8
| | | | | | // rdar://9208404 llvm-svn: 129536
* Clean up the bool conversion warning. Group it with other conversionChandler Carruth2011-04-091-1/+2
| | | | | | | warnings, and make its text appropriate for constant bool expressions other than 'false'. This should finish off PR9612. llvm-svn: 129205
* Add support for warning on general null pointer expressions of booleanChandler Carruth2011-04-091-5/+5
| | | | | | | type rather than just the literal 'false'. This begins fixing PR9612, but the message is now wrong. WIP, the cleanup of the messaging is next. llvm-svn: 129204
* Use ExprResult& instead of Expr *& in SemaJohn Wiegley2011-04-081-130/+208
| | | | | | | | | | | | | | | | | | | | | | | | | This patch authored by Eric Niebler. Many methods on the Sema class (e.g. ConvertPropertyForRValue) take Expr pointers as in/out parameters (Expr *&). This is especially true for the routines that apply implicit conversions to nodes in-place. This design is workable only as long as those conversions cannot fail. If they are allowed to fail, they need a way to report their failures. The typical way of doing this in clang is to use an ExprResult, which has an extra bit to signal a valid/invalid state. Returning ExprResult is de riguour elsewhere in the Sema interface. We suggest changing the Expr *& parameters in the Sema interface to ExprResult &. This increases interface consistency and maintainability. This interface change is important for work supporting MS-style C++ properties. For reasons explained here <http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-February/013180.html>, seemingly trivial operations like rvalue/lvalue conversions that formerly could not fail now can. (The reason is that given the semantics of the feature, getter/setter method lookup cannot happen until the point of use, at which point it may be found that the method does not exist, or it may have the wrong type, or overload resolution may fail, or it may be inaccessible.) llvm-svn: 129143
* PR9615: make sure we destroy any temporaries returned by operator->.Eli Friedman2011-04-041-1/+2
| | | | | | | I'm pretty sure this is the right fix, but I would appreciate it if someone else would double-check. llvm-svn: 128806
* Fix an unused variable warning in release builds and make theChandler Carruth2011-03-291-3/+3
| | | | | | assert-less codepath marginally more efficient. llvm-svn: 128472
* Fix a bug in how we were resolving the address of overloaded functionsChandler Carruth2011-03-291-17/+38
| | | | | | | | | | | | | | | | | | | | | | | | when the resolution took place due to a single template specialization being named with an explicit template argument list. In this case, the "resolution" doesn't take into account the target type at all, and therefore can take place for functions, static member functions, and *non-static* member functions. The latter weren't being properly checked and their proper form enforced in this scenario. We now do so. The result of this last form slipping through was some confusing logic in IsStandardConversion handling of these resolved address-of expressions which eventually exploded in an assert. Simplify this logic a bit and add some more aggressive asserts to catch improperly formed expressions getting into this routine. Finally add systematic testing of member functions, both static and non-static, in the various forms they can take. One of these is essentially PR9563, and this commit fixes the crash in that PR. However, the diagnostics for this are still pretty terrible. We at least are now accepting the correct constructs and rejecting the invalid ones rather than accepting invalid or crashing as before. llvm-svn: 128456
* Support for Transparent unions used as overloadableFariborz Jahanian2011-03-231-2/+41
| | | | | | | function parameter. // rdar:// 9129552 and PR9406. llvm-svn: 128159
* Implement a new 'availability' attribute, that allows one to specifyDouglas Gregor2011-03-231-17/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | which versions of an OS provide a certain facility. For example, void foo() __attribute__((availability(macosx,introduced=10.2,deprecated=10.4,obsoleted=10.6))); says that the function "foo" was introduced in 10.2, deprecated in 10.4, and completely obsoleted in 10.6. This attribute ties in with the deployment targets (e.g., -mmacosx-version-min=10.1 specifies that we want to deploy back to Mac OS X 10.1). There are several concrete behaviors that this attribute enables, as illustrated with the function foo() above: - If we choose a deployment target >= Mac OS X 10.4, uses of "foo" will result in a deprecation warning, as if we had placed attribute((deprecated)) on it (but with a better diagnostic) - If we choose a deployment target >= Mac OS X 10.6, uses of "foo" will result in an "unavailable" warning (in C)/error (in C++), as if we had placed attribute((unavailable)) on it - If we choose a deployment target prior to 10.2, foo() is weak-imported (if it is a kind of entity that can be weak imported), as if we had placed the weak_import attribute on it. Naturally, there can be multiple availability attributes on a declaration, for different platforms; only the current platform matters when checking availability attributes. The only platforms this attribute currently works for are "ios" and "macosx", since we already have -mxxxx-version-min flags for them and we have experience there with macro tricks translating down to the deprecated/unavailable/weak_import attributes. The end goal is to open this up to other platforms, and even extension to other "platforms" that are really libraries (say, through a #pragma clang define_system), but that hasn't yet been designed and we may want to shake out more issues with this narrower problem first. Addresses <rdar://problem/6690412>. As a drive-by bug-fix, if an entity is both deprecated and unavailable, we only emit the "unavailable" diagnostic. llvm-svn: 128127
* Clean up our handling of template-ids that resolve down to a singleDouglas Gregor2011-03-161-6/+10
| | | | | | | | | overload, so that we actually do the resolution for full expressions and emit more consistent, useful diagnostics. Also fixes an IRGen crasher, where Sema wouldn't diagnose a resolvable bound member function template-id used in a full-expression (<rdar://problem/9108698>). llvm-svn: 127747
* Fixes for some more expressions containing function templateids thatDouglas Gregor2011-03-121-0/+38
| | | | | | should be resolvable, from Faisal Vali! llvm-svn: 127521
* When we use the default template arguments of a template templateDouglas Gregor2011-03-031-5/+5
| | | | | | | | | | | | | parameter, save the instantiated default template arguments along with the explicitly-specified template argument list. That way, we prefer the default template template arguments corresponding to the template template parameter rather than those of its template template argument. This addresses the likely direction of C++ core issue 150, and fixes PR9353/<rdar://problem/9069136>, bringing us closer to the behavior of EDG and GCC. llvm-svn: 126920
* Move the bool-conversions behind the DiagRuntimeBehavior logic. It'sChandler Carruth2011-03-011-2/+2
| | | | | | | | | possible for these to show up due to metaprogramming both in unevaluated contexts and compile-time dead branches. Those aren't the bugs we're looking for. llvm-svn: 126739
* Push nested-name-specifier location information into DeclRefExpr andDouglas Gregor2011-02-281-9/+3
| | | | | | MemberExpr, the last of the expressions with qualifiers! llvm-svn: 126688
* Push nested-name-specifier source location information intoDouglas Gregor2011-02-281-12/+14
| | | | | | | | | | | | | UnresolvedLookupExpr and UnresolvedMemberExpr. Also, improve the computation that checks whether the base of a member expression (either unresolved or dependent-scoped) is implicit. The previous check didn't cover all of the cases we use in our representation, which threw off source-location information for these expressions (which, in turn, caused some breakage in libclang's token annotation). llvm-svn: 126681
* Sprinkle optional text of the "unavailable' attributeFariborz Jahanian2011-02-251-18/+24
| | | | | | where ever such attribute causes an error diagnostic. llvm-svn: 126509
* Remove the FIXME I introduced last night, and pull the logic forChandler Carruth2011-02-251-17/+17
| | | | | | | | | | marking selected overloads into the callers. This allows a few callers to skip it altogether (they would have anyways because they weren't interested in successful overloads) or defer until after further checks take place much like the check required for PR9323 to avoid marking unused copy constructors. llvm-svn: 126503
* Print optional message for attr(unavailable) in C++ mode.Fariborz Jahanian2011-02-251-5/+18
| | | | | | // rdar://9046492 llvm-svn: 126499
* Rough fix for PR9323 that prevents Clang from marking copy constructorChandler Carruth2011-02-251-2/+9
| | | | | | | | | | | | | | | | declarations as referenced when in fact we're not going to even form a call in the AST. This is significant because we attempt to allow as an extension classes with intentionally private and undefined copy constructors to have temporaries bound to references, and so shouldn't warn about the lack of definition for that copy constructor when the class is internal. Doug, John wasn't really satisfied with the presence of overloading at all. This is a stop-gap and there may be a better solution. If you can give me some hints for how you'd prefer to see this solved, I'll happily switch things over. llvm-svn: 126480
* Retain complete source-location information for C++Douglas Gregor2011-02-241-1/+2
| | | | | | | | | | | | nested-name-specifiers throughout the parser, and provide a new class (NestedNameSpecifierLoc) that contains a nested-name-specifier along with its type-source information. Right now, this information is completely useless, because we don't actually store the source-location information anywhere in the AST. Call this Step 1/N. llvm-svn: 126391
* Tweak the CXXScopeSpec API a bit, so that we require theDouglas Gregor2011-02-241-4/+2
| | | | | | nested-name-specifier and source range to be set at the same time. llvm-svn: 126347
* Remove unused function.Benjamin Kramer2011-02-201-10/+0
| | | | llvm-svn: 126084
* Handle the resolution of a reference to a function template (whichDouglas Gregor2011-02-191-200/+341
| | | | | | | | includes explicitly-specified template arguments) to a function template specialization in cases where no deduction is performed or deduction fails. Patch by Faisal Vali, fixes PR7505! llvm-svn: 126048
* Use hasSameType in one more, hopefully, last place.Fariborz Jahanian2011-02-131-2/+2
| | | | llvm-svn: 125468
* Some refactoring and using more modern APIs forFariborz Jahanian2011-02-131-57/+56
| | | | | | | implementation of co/contra-variance objc++ block pointers. // rdar://8979379. llvm-svn: 125467
* Implement objective-c++'s block pointer type matching involvingFariborz Jahanian2011-02-121-0/+88
| | | | | | | types which are contravariance in argument types and covariance in return types. // rdar://8979379. llvm-svn: 125445
* AST, Sema, Serialization: add CUDAKernelCallExpr and related semantic actionsPeter Collingbourne2011-02-091-3/+4
| | | | llvm-svn: 125217
* Basic implementation of inherited constructors. Only generates declarations, ↵Sebastian Redl2011-02-051-1/+32
| | | | | | and probably only works for very basic use cases. llvm-svn: 124970
* Implement reasonable conversion ranking for Objective-C pointerDouglas Gregor2011-01-311-22/+70
| | | | | | | | | | | | | | | | | | | | | | | | conversions (<rdar://problem/8592139>) for overload resolution. The conversion ranking mirrors C++'s conversion ranking fairly closely, except that we use a same pseudo-subtyping relationship employed by Objective-C pointer assignment rather than simple checking derived-to-base conversions. This change covers: - Conversions to pointers to a specific object type are better than conversions to 'id', 'Class', qualified 'id', or qualified 'Class' (note: GCC doesn't perform this ranking, but it matches C++'s rules for ranking conversions to void*). - Conversions to qualified 'id' or qualified 'Class' are better than conversions to 'id' or 'Class', respectively. - When two conversion sequences convert to the same type, rank the conversions based on the relationship between the types we're converting from. - When two conversion sequences convert from the same non-id, non-Class type, rank the conversions based on the relationship of the types we're converting to. (note: GCC allows this ranking even when converting from 'id', which is extremeley dangerous). llvm-svn: 124591
* Fix whitespace.NAKAMURA Takumi2011-01-271-321/+321
| | | | llvm-svn: 124364
* 7bit-ize.NAKAMURA Takumi2011-01-271-4/+4
| | | | llvm-svn: 124363
* Fix a horrible bug in our handling of C-style casting, where a C-styleDouglas Gregor2011-01-271-15/+26
| | | | | | | | | | | derived-to-base cast that also casts away constness (one of the cases for static_cast followed by const_cast) would be treated as a bit-cast rather than a derived-to-base class, causing miscompiles and heartburn. Fixes <rdar://problem/8913298>. llvm-svn: 124340
* Implement the restriction that a function with a ref-qualifier cannotDouglas Gregor2011-01-261-1/+17
| | | | | | | | overload a function without a ref-qualifier (C++0x [over.load]p2). This, apparently, completes the implementation of rvalue references for *this. llvm-svn: 124321
* Rvalue references for *this: explicitly keep track of whether aDouglas Gregor2011-01-261-8/+12
| | | | | | | | | reference binding is for the implicit object parameter of a member function with a ref-qualifier. My previous comment, that we didn't need to track this explicitly, was wrong: we do in fact get rvalue-references-prefer-rvalues overloading with ref-qualifiers. llvm-svn: 124313
* Rvalue references for *this: implement the implicit conversion rulesDouglas Gregor2011-01-261-43/+104
| | | | | | | for the implicit object argument to a non-static member function with a ref-qualifier (C++0x [over.match.funcs]p4). llvm-svn: 124311
* Rvalue references for *this: allow functions to be overloaded based onDouglas Gregor2011-01-261-2/+3
| | | | | | | | | the presence and form of a ref-qualifier. Note that we do *not* yet implement the restriction in C++0x [over.load]p2 that requires either all non-static functions with a given parameter-type-list to have a ref-qualifier or none of them to have a ref-qualifier. llvm-svn: 124297
* Reinstate r124236 (tweaking the rvalue-reference overload resolutionDouglas Gregor2011-01-261-18/+53
| | | | | | rules), now that we've actually have a clean build for me to sully. llvm-svn: 124290
* Speculatively revert r124236Douglas Gregor2011-01-251-53/+18
| | | | llvm-svn: 124247
* Speculatively implement a tweak to the C++0x overload resolution rulesDouglas Gregor2011-01-251-18/+53
| | | | | | | | | | | | | | for reference binding (C++ [over.rank.ics]p3b1sb4), so that we prefer the binding of an lvalue reference to a function lvalue over the binding of an rvalue reference. This change resolves the ambiguity with std::forward and lvalue references to function types in a way that seems consistent with the original rvalue references proposal. My proposed wording for this change is shown in isBetterReferenceBindingKind(); we'll try to get this change adopted in the C++0x working paper as well. llvm-svn: 124236
* Fix the ranking of reference bindings during overload resolutionDouglas Gregor2011-01-251-2/+2
| | | | | | | | | | | | | | | | | | (C++0x [over.ics.rank]p3) when one binding is an lvalue reference and the other is an rvalue reference that binds to an rvalue. In particular, we were using the predict "is an rvalue reference" rather than "is an rvalue reference that binds to an rvalue", which was incorrect in the one case where an rvalue reference can bind to an lvalue: function references. This particular issue cropped up with std::forward, where Clang was picking an std::forward overload while forwarding an (lvalue) reference to a function. However (and unfortunately!), the right answer for this code is that the call to std::forward is ambiguous. Clang now gets that right, but we need to revisit the std::forward implementation in libc++. llvm-svn: 124216
* Re-instate r123977/r123978, my updates of the reference-bindingDouglas Gregor2011-01-241-75/+57
| | | | | | | | | | | | | | | | implementation used by overload resolution to support rvalue references. The original commits caused PR9026 and some hard-to-reproduce self-host breakage. The only (crucial!) difference between this commit and the previous commits is that we now properly check the SuppressUserConversions flag before attempting to perform a second user-defined conversion in reference binding, breaking the infinite recursion chain of user-defined conversions. Rvalue references should be working a bit better now. llvm-svn: 124121
* revert r123977 and r123978 to fix PR9026.Rafael Espindola2011-01-221-58/+76
| | | | llvm-svn: 124033
OpenPOWER on IntegriCloud