Bugzilla

Thanks for the investigation and reduced example.

(In reply to Razvan Cojocaru from comment #11)
> [Here's](https://eel.is/c++draft/class.derived.general#7) the relevant part of the ISO C++ standard: *"A base class subobject can be of zero size; however, two subobjects that have the same class type and that belong to the same most derived object cannot be allocated at the same address."*

I wouldn't have thought that the two `Base` subobjects in `Derived2` "belong to the **same** most derived object" (in my mind, the "most derived object" that they belong to are, respectively, the `Derived2` object and the `member1` subobject).

However, looking at the [normative wording](https://eel.is/c++draft/intro.object#9) that this note is based on:

> [...] Two objects with overlapping lifetimes that are not bit-fields may have the same address if one is nested within the other, or if at least one is a subobject of zero size and they are of different types; otherwise, they have distinct addresses and occupy disjoint bytes of storage.

this does more clearly suggest that the two `Base` subobjects in this scenario are required to have distinct addresses.

---

So next, let's evaluate whether we need both `PointTyped` and `CoordTyped` to derive from `Units`.

The reason `PointTyped` derived from `Units` is that the unit types define some static member functions like [this one](https://searchfox.org/mozilla-central/rev/968bd894205cf4f579d94ac4e175cc3187458605/layout/base/Units.h#287), and we like to be able to call these as e.g. `CSSPoint::FromAppUnits()` rather than `CSSPixel::FromAppUnits()` (because `CSSPoint::FromAppUnits()` suggests the `CSSPoint` return type more clearly).

We do have [some methods](https://searchfox.org/mozilla-central/rev/968bd894205cf4f579d94ac4e175cc3187458605/layout/base/Units.h#279) that return `Coord` types as well, however, in this case:

 * Writing `CSSCoord::FromAppUnits()` instead of `CSSPixel::FromAppUnits()` doesn't make much of a difference for readability
 * Looking through the [call sites](https://searchfox.org/mozilla-central/search?q=symbol:_ZN7mozilla8CSSPixel12FromAppUnitsEi&redirect=false), they already use the `CSSPixel::FromAppUnits()` form, with [one exception](https://searchfox.org/mozilla-central/rev/968bd894205cf4f579d94ac4e175cc3187458605/widget/Theme.cpp#1327)

So, I think it would be reasonable to change `CoordTyped` and `IntCoordTyped` to stop inheriting from `Units` (and change that one affected call site).

Thanks for the investigation and reduced example.

(In reply to Razvan Cojocaru from comment #11)
> [Here's](https://eel.is/c++draft/class.derived.general#7) the relevant part of the ISO C++ standard: *"A base class subobject can be of zero size; however, two subobjects that have the same class type and that belong to the same most derived object cannot be allocated at the same address."*

I wouldn't have thought that the two `Base` subobjects in `Derived2` "belong to the **same** most derived object" (in my mind, the "most derived object" that they belong to are, respectively, the `Derived2` object and the `member1` subobject).

However, looking at the [normative wording](https://eel.is/c++draft/intro.object#9) that this note is based on:

> [...] Two objects with overlapping lifetimes that are not bit-fields may have the same address if one is nested within the other, or if at least one is a subobject of zero size and they are of different types; otherwise, they have distinct addresses and occupy disjoint bytes of storage.

this does more clearly suggest that the two `Base` subobjects in this scenario are required to have distinct addresses.

---

So next, let's evaluate whether we need both `PointTyped` and `CoordTyped` to derive from `Units`.

The reason `PointTyped` derives from `Units` is that the unit types define some static member functions like [this one](https://searchfox.org/mozilla-central/rev/968bd894205cf4f579d94ac4e175cc3187458605/layout/base/Units.h#287), and we like to be able to call these as e.g. `CSSPoint::FromAppUnits()` rather than `CSSPixel::FromAppUnits()` (because `CSSPoint::FromAppUnits()` suggests the `CSSPoint` return type more clearly).

We do have [some methods](https://searchfox.org/mozilla-central/rev/968bd894205cf4f579d94ac4e175cc3187458605/layout/base/Units.h#279) that return `Coord` types as well, however, in this case:

 * Writing `CSSCoord::FromAppUnits()` instead of `CSSPixel::FromAppUnits()` doesn't make much of a difference for readability
 * Looking through the [call sites](https://searchfox.org/mozilla-central/search?q=symbol:_ZN7mozilla8CSSPixel12FromAppUnitsEi&redirect=false), they already use the `CSSPixel::FromAppUnits()` form, with [one exception](https://searchfox.org/mozilla-central/rev/968bd894205cf4f579d94ac4e175cc3187458605/widget/Theme.cpp#1327)

So, I think it would be reasonable to change `CoordTyped` and `IntCoordTyped` to stop inheriting from `Units` (and change that one affected call site).