Skip to content
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.

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

always use a vptr (possibly with an empty type) in object representations #4517

Closed
wants to merge 2 commits into from

Conversation

dwblaikie
Copy link
Contributor

@dwblaikie dwblaikie commented Nov 12, 2024

This breaks a lot of tests and lowering (with a pre-existing crash, probably just due to the lack of lowering of the initializer (or lowering it in check into an Error builtin, specifically), that only happens currently in dynamic classes, but by putting a vptr (even a zero-length one) in every class means they all hit that crash) so the presubmit checks aren't clear, but that's not really the fault of this patch.

MODULE.bazel.lock Outdated Show resolved Hide resolved
MODULE.bazel.lock Outdated Show resolved Hide resolved
@dwblaikie dwblaikie mentioned this pull request Nov 12, 2024
@dwblaikie dwblaikie closed this Nov 19, 2024
@dwblaikie dwblaikie deleted the vptr_always branch November 19, 2024 22:52
github-merge-queue bot pushed a commit that referenced this pull request Nov 26, 2024
We considered a couple of other options for this:
* #4515 Keep the
`ElementIndex` numbering vptr-ignorant, and do +1 offsets as needed -
seems subtle/easy to miss
* #4517 Always have a
zeroth element in the object representation, make it zero-size in the
case of no-vptr - @zygoloid was concerned this would add overhead
especially to stateless objects used in type-trait-like things.

But currently moving forward with this direction - of initializing field
indexes with an invalid value until the end of the class definition,
then assigning field indexes during construction of the class's object
representation struct type. This direction might reinforce/help avoid
premature access to the object representation before the class is
complete, and give a single place where class layout is done (at class
completion) if we want to add more options there, such as class layout
optimizations, etc.

This patch still has problems with object initialization (that #4515
does not have/does address) but does address normal `obj.member` access
correctly.

---------

Co-authored-by: Richard Smith <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants