Re: C++ PATCH to refer to base members using COMPONENT_REF

[Jason Merrill <jason at redhat dot com>]

On Sun, 09 May 2004 20:25:49 -0700, Mark Mitchell <mark@codesourcery.com> wrote:

> Jason Merrill wrote:
>
>> On Mon, 03 May 2004 13:23:48 -0700, Mark Mitchell <mark@codesourcery.com> wrote:

>>>It might tell the alias analysis code that assignment to the base field
>>>might alias any of the types of the fields in the complete type when really
>>>it can only alias things in the base type.

>> I don't think so.  The base type does not alias other members of the
>> derived type.
>
> I don't understand.  The base field, after your change, will have the type
> of the derived class.

No, the base field has the type of the base class.

>> But we only use the tail padding for non-PODs, which we have to deal with
>> on a member-by-member basis anyway.
>
> That's only true until we start recognizing that some constructors are
> trivial.  Then, the front end will start treating some non-PODs as if they
> were PODs for the purpose of copying.

The front end will already need to decide in which circumstances this would
be safe; it is already unsafe for INDIRECT_REFs.  This is just another case.

>>>I think you should instead leave the base field types as they are, but use
>>>FIELD_DECLs from the base type instead of the complete type.
>> The offsets would be wrong for non-primary bases unless we did something
>> like make copies of the FIELD_DECLs for use in derived types.
>
> I'm not sure why that would be.  But, I believe you -- I'm probably just
> not thinking about it right.

If base B is at offset 4 in derived class A, all of the fields of B-in-A
are at an offset 4 different from their offset in B.

> Fundamentally, my objection to this patch is that it's causing us to lie to
> the compiler.  From the point of view of the language, these fields don't
> exist, so that's not an issue.  From the point of view of the compiler,
> however, these fields do not have the same type as the derived type, or the
> same size.  The relationship is that the base fields are an initial prefix
> of the derived class.  After your change, we've busted the type system --
> there are type-safe assignments that are not actually safe, for example.
> Historically, whenever we've lied like this, we've gotten into trouble.

I agree with the principle -- "if you lie to the compiler, it will have its
revenge."  But the object we get via "a.<B base field>" is the same as the
object we get by "*(B*)&a", and we already give the latter the base type.
I don't see any reason why the former is any less the base.

Yes, in this case we are breaking the assumption that a COMPONENT_REF
denotes a complete object, but I don't think the type system is the right
place to express that.

Jason