Skip to content

Clarify that the "type conflict" rule ignores cv-qualifiers #167

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Clarify that the "type conflict" rule ignores cv-qualifiers #167

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
1d08f82
Clarify that the "type conflict" rule ignores cv-qualifiers
zygoloid Sep 5, 2023
73b8981
Say "similar type" rather than explicitly talking about cv-qualifiers
zygoloid Sep 6, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions abi.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1045,8 +1045,8 @@ <h3><a href="#class-types"> 2.4 Non-POD Class Types </a></h3>
to nvalign(D) for base classes or
to align(D) for data members.
Place D at this offset unless doing so would result in two
components (direct or indirect) of the same type having the
same offset.
components (direct or indirect) of the same type (ignoring
cv-qualifiers) having the same offset.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be top-level cv-qualifiers.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, are you thinking of cv-qualifiers in template arguments? Empty types can't have non-top-level cv-qualifiers in the usual sense (and if they could, they should be ignored here too, because we don't want objects with similar types to have the same address).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Being clear about the qualifiers being ignored only being the top-level qualifiers seems like the right thing to do. If for some strange reason we ever add a new fundamental type that can be empty, the right default rule to apply here would be to ignore only the top-level qualifiers. A type similarity rule would necessarily be specific to the new fundamental type.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can avoid the question entirely and specify the rule in terms of whether the types are similar. Done.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, that works.

If such a component type conflict occurs,
increment the candidate offset by nvalign(D)
for base classes or by align(D) for data members
Expand Down