`zig ast-check` produces an error on well-formed `build.zig.zon` files

[torque]

Zig Version

0.14.0-dev.2293+6d781e095

Steps to Reproduce and Observed Behavior

zig ast-check build.zig.zon

on a well-formed build.zig.zon (such as the one in this repository), instead of succeeding, produces the following error message

build.zig.zon:1:1: error: file cannot be a tuple
.{
^

This also happens with zig fmt --ast-check and is likely to be hit if you try to run that on all files in a project with e.g. zig fmt --ast-check --check .

Expected Behavior

zig should not disagree with itself about whether the structure of build.zig.zon is correct.

[der-teufel-programming]

build.zig.zon file isn't a well formed Zig file, but a ZON file. ast-check correctly checks that this is not a correct Zig file

[torque]

While I agree that zon files are indeed not strictly zig files, I think it's pretty reasonable to expect zig's tooling to work with the family of zig file formats. Please see the note about zig fmt automatically operating on .zon files when provided a directory.

This is a "regression" of the previous behavior (i.e. this error is not produced by zig 0.13 or some earlier versions of 0.14-dev). It seems very likely this was a side effect of #21817, but I haven't attempted to bisect it to prove that.

[andrewrk]

@mlugg would you mind taking a look at this? It's causing damage in the ecosystem which you can see above with the referenced commit "remove --ast-check from zig format". We don't want people to do that.

It's definitely a regression from previous behavior:

[mlugg]

@andrewrk Sure thing, I'll take a look tomorrow (just heading to bed). The reason this is happening is because ast-check runs AstGen over the file, but ZON files have expressions at the top-level, whereas Zig source files have container declarations at the top level. This worked by accident before, because a Zig source file containing only an expression was parsed as a single-element tuple type; i.e. if the file contained expr, the file evaluated to struct { expr }. Since files are now banned from being tuples, this isn't the case anymore.

The obvious thing is that ZON files shouldn't go through AstGen -- it's just not appropriate, because ZON is not the same thing as Zig. I could just make ast-check on ZON files only validate parsing, but I could also potentially write a ZON validation pass which checks the ZON is well-formed (top-level is a valid expression, and it doesn't use any illegal constructs like struct { ... } or T{ ... }). I'll take a look at Mason's ZON work, since this will tie in to that.