[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

[Sebastian Redl]

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.
By my reading, this means that ADL should be disabled if the address is
taken, too. (Why unwrap the address-of operator at all? Where does the
standard say that?)
> +  if (getLangOptions().CPlusPlus && DRExpr &&
> +      (FDecl || isa<OverloadedFunctionDecl>(DRExpr->getDecl()))) {
> +    // C++ [basic.lookup.argdep]p1:
> +    //   When an unqualified name is used as the postfix-expression in
> +    //   a function call (5.2.2), other namespaces not considered
> +    //   during the usual unqualified lookup (3.4.1) may be searched,
> +    //   and namespace-scope friend func- tion declarations (11.4) not
> +    //   otherwise visible may be found.
>   
func- tion should be unbroken.
> +  // 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.
> +  // 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.


Great work, as usual.
Sebastian