Qualified friends

[Nathan Sidwell]

Martin v. Loewis wrote:
> Below is a patch. Please let me know if it works.
This patch works for that example, but not for this one, without the
-fhonor-std flag (sorry)
namespace M {
class S;
}
namespace std
{
void foo(M::S *);
}
namespace M {
class S {
  friend void std::foo(S *);
  int m;
};
}

void std::foo(M::S *ptr) {
  ptr->m = 1;
}
nathan@manao:1034>devel-g++ -c alien.ii            
alien.ii: In function `void foo(M::S *)':
alien.ii:16: member `m' is a private member of class `M::S'

I can guess why this is so, as we're smashing ::std into ::, and clearly it's
been missed somewhere.

> Indeed. This would always fail if a global function is friend of a
> namespace-scoped class. The reason is that we can't distinguish in
> DECL_CONTEXT between 'uninitialized context', and 'context is
> global_namespace'.
I'd done some poking around last night and discovered this bit of schizophenia
with a NULL DECL_CONTEXT. It seems to me that a better, more consistent
solution, would be to junk that, and have DECL_CONTEXT == NULL -->
uninitialized context, and DECL_CONTEXT == global_namespace -> in global
namespace. Some bits of the compiler need changing to stop mangling global
static names and change the detection of `main' and a few other bits and bobs.
The current situation appears that the rest of the compiler is kludging around
this with CP_DECL_CONTEXT and FROB_NAMESPACE (now there's a kludgy name if ever
there was one!). I think these are asking for trouble. I don't see why the back
end would have a problem with this -- it's not aware of names and such.

I'm working though this at the moment. Does this seem a sensible plan?

nathan
-- 
Dr Nathan Sidwell :: Computer Science Department :: Bristol University
      You can up the bandwidth, but you can't up the speed of light      
nathan@acm.org  http://www.cs.bris.ac.uk/~nathan/  nathan@cs.bris.ac.uk