fix(ast_tools): fix miscalculation of enum layouts.

[rzvxa]

Fixes a bug with how we were calculating the size of enums when there are different padding on variants and there aren't enough niches. Now it aligns the largest variant size to the largest alignment before consuming niches.

[graphite-app]

Your org has enabled the Graphite merge queue for merging into main

Add the label “0-merge” to the PR and Graphite will automatically add it to the merge queue when it’s ready to merge. Or use the label “hotfix” to add to the merge queue as a hot fix.

You must have a Graphite account and log in to Graphite in order to use the merge queue. Sign up using this link.

[rzvxa]

• feat(ast, syntax, ast_tools): Introduce GetNodeId trait. #5776
• feat(ast): add a dummy node_id field to all visitable AST types. #5775
• fix(ast_tools): fix miscalculation of enum layouts. #5774 👈
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @rzvxa and the rest of your teammates on Graphite

[codspeed-hq]

CodSpeed Performance Report

Merging #5774 will not alter performance

_{Comparing 09-15-fix_ast_tools_fix_miscalculation_of_enum_layouts (ea1c733) with main (3230ae5)}

Summary

✅ 29 untouched benchmarks

[overlookmotel]

I am not familiar with the layout calculation logic in ast_tools, so I could be reading it wrong, but it looks like this is taking the niches of the variants' fields into account for niche calculation of the enum.

I don't think this is correct. e.g.: Rust playground:

• StartNiche has an unused discriminant at start of the u8 range (0).

• EndNiche has an unused discriminant at end of the u8 range (255).

• NoNiche has no unused discriminants at either start or end of u8 range.

• Option<StartNiche> and Option<EndNiche> are 2 bytes (discriminant's niche used as None).

• Option<NoNiche> is 3 bytes (indicating NoNiche has no niche).

A couple of conclusions we can draw from this:

1. The number of variants is not relevant, only whether there are spare discriminant values at start or end of range (not in the middle).
2. Whether the fields have niches or not is also irrelevant. Compiler could have noticed that every variant in NoNiche has a field with 254 illegal values, and those illegal values overlap for all fields. It could have used one of those illegal values as a niche (Option<NoNiche>::None could be stored as 2 bytes [0, 2]). But it doesn't! An enum only has niches if there are available discriminant values.

You have other PRs stacked on top of this, so feel free to merge this, and then change the niche logic in a follow-up if you like.

[overlookmotel]

Am going to merge this, and then address the issues raised in my comment above in a follow-on.

[overlookmotel]

Merge activity

• Oct 21, 8:18 AM EDT: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
• Oct 21, 8:18 AM EDT: A user added this pull request to the Graphite merge queue.
• Oct 21, 8:25 AM EDT: A user merged this pull request with the Graphite merge queue.

[overlookmotel]

Am going to merge this, and then address the issues raised in my comment above in a follow-on.

Actually, I can't understand the code at all. To calculate niches correctly, need to know the value of the variant discriminants, which isn't easily available at this stage. I think to make it exactly correct, will need quite a large refactoring. In any case, for AST transfer, we need to know not just how many niches, but their positions and values. So will need a rework for that anyway. I'll return to this later on.

Note: The usual niche optimization for Option-like enums does not apply when the enum is #[repr(C)], which all our enums are. Rust playground