Allow importing ZON without a result type (you can import build.zig.zon now)

[MasonRemaley]

Adds support for using import ZON without a result type.

@mlugg you should probably check over the logic for structs, as I imagine you were planning to anyway. In particular a few points I'm unsure about:

• Is addTypeReferenceEntry necessary? (Maybe this is what you meant by I may need to register an incremental dependency.)
• Imported types get a type name based on the first import location, this seems wrong they should probably be based on the ZON file (I think I can just write my own logic for this instead of using Sema.createTypeName but let me know your thoughts)
• Side note: Zoir and LowerZon/std.zon are inconsistent in how they refer to tuples/arrays. Zoir calls them arrays, LowerZon/std.zon calls them tuples. Not a huge deal but I can resolve this one way or the other, let me know if you have an opinion either way.

---

For those who want to import build.zig.zon, remember to add it as a module. You can't access it via ../build.zig.zon since this is outside the module path. This is not necessary for ZON files in the module path.

build.zig

const build_zig_zon = b.createModule(.{
    .root_source_file = b.path("build.zig.zon"),
    .target = target,
    .optimize = optimize,
});
exe.root_module.addImport("build.zig.zon", build_zig_zon);

main.zig

const std = @import("std");
const build = @import("build.zig.zon");

pub fn main() !void {
    std.debug.print("Version: \"{s}\"\n", .{build.version});
}

[cryptocode]

In #22775 it was suggested that the build.zig.zon format should maybe be changed to be representable directly in the Zig type system.

With this PR, iterating through dependencies does work, though only through meta programming since the field is not of an indexable type:

    const deps = std.meta.fields(@TypeOf(zon.dependencies));
    inline for (deps) |d| {
        const dep = @field(zon.dependencies, d.name);
        ... etc
    }

Then again, accessing dependencies might have such rare usecases that maybe it's fine.

[MasonRemaley]

This currently crashes on the output of #22939, looking into it.

[MasonRemaley]

Fixed. Struct field values are now allocated from the sema arena, similar to how it's done in sema for anonymous types. I didn't realize this was necessary, I thought the values from the struct init would still be around. Still not fully sure I understand the situation here and would be happy to have it explained to me!

[mlugg]

Nearly there! There were one or two things here I said I'd do. I'll also write you up an incremental test case to throw in to test/incremental/.

[mlugg]

I'm not entirely sure if this is safe; might need some changes in places where we use this zir_index just to make sure that it's handling the ZON case. (I'll handle that.)

[mlugg]

Just to explain this:

Fixed. Struct field values are now allocated from the sema arena, similar to how it's done in sema for anonymous types. I didn't realize this was necessary, I thought the values from the struct init would still be around. Still not fully sure I understand the situation here and would be happy to have it explained to me!

The slice you get from field_inits.get(ip) (and similar calls) is ephemeral; it's invalidated when the InternPool resizes. That can potentially happen whenever something is interned (InternPool.get / Zcu.PerThread.intern / Zcu.PerThread.xyzValue / etc). As such, what was probably happening before was that your recursive lowerExprAnonResTy was (since it itself interned some stuff) triggering an InternPool resize, meaning the rest of the values you wrote were in old memory (that old memory actually would still have been mapped/alloced, weird quirk of the thread-safe InternPool), so the rest of the code wouldn't see them (and would instead see the undefined/.none values which were originally there).

[MasonRemaley]

Ah that makes a lot of sense, thank you for walking me through it! That explains why I was only triggering it on a very large import (it was presumably putting enough stuff in intern pool to cause it to realloc.)

[MasonRemaley]

I just noticed that I'm getting this log message while running the tests:

error: warning(zcu): unexpected EOF reading cached ZIR for zon/large_number.zon

I'm guessing this is related to the changes you already mentioned need to be made WRT the ZIR index?

I'll also write you up an incremental test case to throw in to test/incremental/.

Good idea, thanks!

[mlugg]

I just noticed that I'm getting this log message while running the tests:

error: warning(zcu): unexpected EOF reading cached ZIR for zon/large_number.zon

Hm, that's concerning. I'll take a look at this locally when I can -- mind writing out the exact repro?

[MasonRemaley]

I can reliably repro it like this:

1. Build the compiler

build/stage3/bin/zig build -p build/stage4 -Denable-llvm -Dno-lib -Ddebug-extensions --prominent-compile-errors

2. Run the ZON behvaior tests:

build/stage4/bin/zig test test/behavior/zon.zig

3. Run the ZON behavior tests a second time emits the warning:

build/stage4/bin/zig test test/behavior/zon.zig

Running the tests a third time does not emit the warning.

[MasonRemaley]

Alright, mlugg helped me fix the above warning. The math on the code writing the big int limbs for zoir was slightly off, and the file wasn't properly cleared on error--both issues are fixed now.

[mlugg]

Sorry for the delay in getting to this! I've fixed a minor bug related to the zir_index on generated structs, added an incremental case, and squashed most of the commits together. I'll set this to auto-merge now; thanks!

@alexrp, since you've been doing a bunch of 0.14.1 cherry-picking and I'll probably forget... 8720995 and d8ac37f should be cherry-picked into 0.14.1, since they fix a kinda-significant bug. The other commits here shouldn't; they introduce a new feature.