sema: analyze struct field bodies in a second pass, to allow them to use the layout of the struct itself

[kcbanner]

This PR is based off of #17658.

The main goal of this PR was to resolve the circular dependency error you used to get when doing something like this:

const StructInner = extern struct {
    outer: StructOuter = std.mem.zeroes(StructOuter),
};

const StructMiddle = extern struct {
    outer: ?*StructInner,
    inner: ?*StructOuter,
};

const StructOuter = extern struct {
    middle: StructMiddle = std.mem.zeroes(StructMiddle),
};

test "circular dependency through pointer field of a struct" {
    var outer: StructOuter = .{};
    try expect(outer.middle.outer == null);
    try expect(outer.middle.inner == null);
}

test\behavior\container_circular_dependency.zig:28:29: error: struct 'container_circular_dependency.StructMiddle' depends on itself
const StructMiddle = extern struct {
                     ~~~~~~~^~~~~~
test\behavior\container_circular_dependency.zig:34:5: note: while checking this field
    middle: StructMiddle = std.mem.zeroes(StructMiddle),
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This is accomplished by breaking out the struct field init body resolution into a separate pass, so it can happen after the struct's layout has been resolved.

semaStructFields now caches the ranges of the init bodies in the StructType trailing data. The init bodies are then resolved by resolveStructFieldInits, which is called before the inits are actually required. Within the init bodies, the struct decl's instruction is repurposed to refer to the field type itself. This is to allow us to easily rebuild the inst_map mapping required for the init body instructions to refer to the field type. Thanks to @mlugg for the guidance on this one!

An additional benefit of this change is that we no longer need to make incorrect guesses about struct alignment when a field init wants to use its container's alignment. Previously, this test would fail because the struct alignment would be guessed to be pointer-aligned:

test "initializer uses own alignment" {
    const S = struct {
        x: u32 = @alignOf(@This()) + 1,
    };

    var s: S = .{};
    try expectEqual(4, @alignOf(S));
    try expectEqual(@as(usize, 5), s.x);
}

I updated the alignment guessing logic to mark if the guess was made, and it's checked in resolveStructLayout. I added a similar check for unions as well.

I checked to see if the guessing logic could be removed entirely, but there are some cases where it's still required:

test "struct field has a pointer to an aligned version of itself" {
    const E = struct {
        next: *align(1) @This(),
    };
    var e: E = undefined;
    e = .{ .next = &e };

    try expect(&e == e.next);
}

I may look into how to resolve that in a future PR.

Additional changes:

• Autodoc fixup to handle the repurposes instruction in init bodies
• CBE and wasm fixes for handling union representations that have unknown tags. Some of the new test cases exposed this problem that was introduced in sema: Support reinterpreting extern/packed unions at comptime via field access #17352.

[Vexu]

Fixes #14005

[kcbanner]

Fixes #14005

I added this as a test case and it revealed an unnecessary call I was making to resolveStructFieldInits in resolveStructFully, thanks!

[kcbanner]

I've added a fix for the CBE not handling union representations with an unknown tag - this was broken since #17352. One of the new tests cases in this PR depends on this working.

[mlugg]

As a note, you accidentally left in both Add compile error test case for... commits from the other branch, but that can be sorted during merge no problem

EDIT: ah, you removed it in a later commit - no worries, if it's okay with you @kcbanner I'm gonna force-push to your branch in a moment to reshuffle a few commits, but no material changes

[kcbanner]

As a note, you accidentally left in both Add compile error test case for... commits from the other branch, but that can be sorted during merge no problem

EDIT: ah, you removed it in a later commit - no worries, if it's okay with you @kcbanner I'm gonna force-push to your branch in a moment to reshuffle a few commits, but no material changes

I've addressed your feedback and made a couple fixes in the new test cases for big-endian arches.

Feel free to shuffle commits, thanks!

[kcbanner]

Rebased to resolve conflicts.

[kcbanner]

Fixes #17563

[mlugg]

Sorry for how long it took me to get around to this - it all looks good. I'm going to do one final rebase (and shuffle a few commits around), then I'll set this to auto-merge. Thanks!

(EDIT: "shuffle a few commits around" ended up meaning "squash basically everything", but I think everything's still there!)

[andrewrk]

This broke #17892. I haven't tracked it down yet but I have a stack trace of optimized CBE: #17892 (comment)

Also I don't like those changes to packed struct representation because I don't think a flags field needs to be added to packed struct. I avoided it so far, and now 30 bits are going to be wasted for 2, which feels bad.

I should add though, thank you, this is good work 👍

[mlugg]

Good point on the packed struct flags - I'm not sure if we can eliminate those bits entirely, but if not then I'd suggest we could perhaps repurpose a few bits of fields_len in TypeStructPacked.

[linusg]

This caused a false struct depends on itself in kiesel - unfortunately the project is too large for me to easily reduce this, but building with zig master should reproduce:

src/types/language/Object/InternalMethods.zig:1:1: error: struct 'types.language.Object.InternalMethods' depends on itself
//! 6.1.7.2 Object Internal Methods and Internal Slots
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[kcbanner]

Good point on the packed struct flags - I'm not sure if we can eliminate those bits entirely, but if not then I'd suggest we could perhaps repurpose a few bits of fields_len in TypeStructPacked.

If we can steal those two bits from fields_len, I'm happy to PR that.