[cfe-commits] r63692 - in /cfe/trunk: lib/Sema/Sema.h lib/Sema/SemaExpr.cpp lib/Sema/SemaLookup.cpp lib/Sema/SemaOverload.cpp test/SemaCXX/basic_lookup_argdep.cpp test/SemaCXX/convert-to-bool.cpp test/SemaCXX/converting-constructor.cpp test/SemaCXX/decl-expr-ambiguity.cpp test/SemaCXX/overloaded-operator.cpp test/SemaCXX/qualification-conversion.cpp test/SemaCXX/type-dependent-exprs.cpp test/SemaObjCXX/blocks.mm

[Douglas Gregor]

On Feb 4, 2009, at 8:34 AM, Sebastian Redl wrote:

> Douglas Gregor wrote:
>> Author: dgregor
>> Date: Tue Feb  3 18:32:51 2009
>> New Revision: 63692
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=63692&view=rev
>> Log:
>> Initial implementation of argument dependent lookup (a.k.a. ADL,
>> a.k.a. Koenig lookup) in C++.
>>
> Woohoo!

:)

>> +  bool ADL = true;
>> +  while (true) {
>> +    if (ImplicitCastExpr *IcExpr = dyn_cast<ImplicitCastExpr> 
>> (FnExpr))
>> +      FnExpr = IcExpr->getSubExpr();
>> +    else if (ParenExpr *PExpr = dyn_cast<ParenExpr>(FnExpr)) {
>> +      // FIXME: Where does the C++ standard say this?
>> +      ADL = false;
>>
>
> 3.4.2/p1: "When an *unqualified name* is used as the postfix- 
> expression
> in a function call"
> That this reading is intentional was reinforced at the September 2008
> meeting when discussing DR 705. The wording will probably be changed
> before the final C++0x standard is published.

Yep, found it :)

> By my reading, this means that ADL should be disabled if the address  
> is
> taken, too.

I'm being sneaky. You can't have an address-of operator for the  
function without there being parentheses around the expression, so ADL  
will be disabled by the parentheses.

> (Why unwrap the address-of operator at all? Where does the
> standard say that?)

Two reasons:
   1) (&f)(blah) needs to be treated the same way as f(blah) when f  
refers to a set of overloaded functions (C++ [over.match.call]p3)
   2) We want to call CheckFunctionCall in cases like (&f)(blah)

>> +  // FIXME: What about block pointers?
>>
> I assume that we'll have to define the semantics of that. It seems  
> to me
> that block pointers should be treated like normal function pointers,
> i.e. recurse into arguments and return type.

Probably; I want to double-check with our blocks guys here (and then  
*write it down* somewhere).

>> +  // FIXME: What about Objective-C message sends?
>>
> Same, I think. But in this case, we should see what GCC's Objective-C 
> ++
> implementation does, if anything.

Probably; I want to double-check with our Objective-C guys here (and  
then *write it down* somewhere).

:)

	- Doug the Pedant