[C++ Patch] DR 217 follow up (and more)

[Paolo Carlini <paolo dot carlini at oracle dot com>]

Hi,

today I noticed that when we implemented the resolution we failed to 
handle static member functions. The below tested x86_64-linux.

While working on this I noticed that we don't use the 
DECL_NONSTATIC_MEMBER_FUNCTION_P macro much, should we apply something 
like the attached?

Finally, if you are wondering instead how I noticed the former ;) I have 
been working on c++/15339, which seems relatively easy to resolve. Ie, 
rejecting in duplicate_decls

template<typename> void fun(int);
template<typename> void fun(int = 0);

however, handling correctly the member case:

class A
{
  template<typename> void fun(int);
};

template<typename> void A::fun(int = 0) { }

is more tricky because we don't want to start rejecting:

class A
{
  void fun(int);
};

void A::fun(int = 0) { }

which is well formed. The problem is that when grokfndecl calls 
duplicate_decls in such member cases it looks through TEMPLATE_DECLs, eg:

      if (TREE_CODE (old_decl) == TEMPLATE_DECL)
        /* Because grokfndecl is always supposed to return a
           FUNCTION_DECL, we pull out the DECL_TEMPLATE_RESULT
           here.  We depend on our callers to figure out that its
           really a template that's being returned.  */
        old_decl = DECL_TEMPLATE_RESULT (old_decl);

and then telling apart the two cases above is tough, both are 
FUNCTION_DECLs :(

Ideas about the best way to handle that? Anything less delicate than 
trying *not* to use DECL_TEMPLATE_RESULT that early and passing the 
TEMPLATE_DECLs as they are to duplicate_decls and then using it only 
right before returning from grokfndecl?

Thanks!
Paolo.

///////////////////////////

Attachment: CL_dr217_fu
Description: Text document

Attachment: patch_dr217_fu
Description: Text document

Attachment: patch_predicate
Description: Text document