🚀 go-pugleaf

I think I've found what the problem is, though it's not really one that can
be fixed by someone who knows the inner workings of g++ as little as I do.

The problem is conceptual:  the default X(X&) and X::operator=(X&)
functionality is handled in several different places in the code, rather
than being treated as an actual function.

My illustration code, with more precise comments:

-----
class Bunk {
    int d;
  public:
    Bunk(int i) { d = i; }
};

main() {
    Bunk b(1);			// Calls Bunk(int);
    Bunk a(b);			// Simulates Bunk(Bunk&) in expand_aggr_init();
    Bunk* ap = new Bunk(b);	
	// Calls build_method_call to get Bunk(Bunk&) and fails, since it's
	// not defined. (build_new could simulate Bunk(Bunk&), but it doesn't.
    a = b;			
	// Simulates Bunk::operator=(Bunk&) in convert_for_assignment
    a.operator=(b);
	// Calls build_method_call to get Bunk::operator=(Bunk&), and fails.
    return 0;
}
-----

The first failure could be solved by making build_new deal with default
constructors properly.  However, the second failure can only be solved by
either hacking build_method_call to simulate operator= if it's not defined
or by defining it when it is needed; this involves a significant conceptual
shift from "simulate it where it might occur" to "create it if it's not
there".

Actually creating the functions and generating function calls would be
considerably less efficient than the current method, but I think that
putting the simulation code in build_method_call only would do the trick
well.  That way, you also don't have to worry about having the same code in
several different functions.

--
Jason Merrill
jason@jarthur.claremont.edu