-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
ZON #20271
base: master
Are you sure you want to change the base?
ZON #20271
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regarding &
in ZON...
You're correct that ZON definitely shouldn't include this. Our main use of ZON today (build.zig.zon
) already creates variable-length structures without this syntax. To avoid a divergence between ZON you can @import
and build.zig.zon
, I would consider this a merge blocker, but that's Andrew's call of course.
Implementation-wise, the ZIR instruction corresponding to @import
should be modified to provide a result type if one is present (you can use .none
to represent the case where there isn't one). Then, the ZON analysis logic should traverse into this result type as needed. This has the additional advantage of providing better source locations if the structure of an imported file doesn't match what's expected, since the type error will occur whilst parsing the relevant ZON expression.
Hmm I think I agree, better to knock it out now than to release it as is then immediately change the syntax. I would've done this up front but incorrectly thought it required major changes to the compiler. I'll take a look at making this change. If no result type is specified, I'll have it default to a tuple rather than a slice unless there are any objections to that default. |
Yup. I agree that it makes sense to use a tuple when there's no result type. By the way, in case you're unfamiliar with the |
There were two primary issues at play here: 1. The hex float prefix was not handled correctly when the stream was reset for the fallback parsing path, which occured when the mantissa was longer max mantissa digits. 2. The implied exponent was not adjusted for hex-floats in this branch. Additionally, some of the float parsing routines have been condensed, making use of comptime. closes ziglang#20271
There were two primary issues at play here: 1. The hex float prefix was not handled correctly when the stream was reset for the fallback parsing path, which occured when the mantissa was longer max mantissa digits. 2. The implied exponent was not adjusted for hex-floats in this branch. Additionally, some of the float parsing routines have been condensed, making use of comptime. closes ziglang#20271
In case you haven't found why this is happening, it's here: zig/ci/x86_64-linux-release.sh Lines 60 to 66 in 17f14e1
Edit: I'll address this in a PR shortly. Sit tight for a bit. |
After #20321 you should see the same failures locally when running Edit: I think if you rebase and resolve that build.zig conflict, those CI failures will disappear. |
Nice thanks! I'll do the rebase and get started on removing & from the syntax when I'm back in town next week. |
0358ab4
to
ce32047
Compare
Thanks, I'm not familiar with this code so this is helpful! I started implementing storing the result type on imports, but got a bit stuck. AstGen used to use // AstGen.builtinCall
const operand_node = params[0];
const rhs = try expr(gz, scope, .{ .rl = .none }, operand_node);
try gz.addPlNode(.import, node, Zir.Inst.Bin{
.lhs = result_type,
.rhs = rhs,
}); Zir used to use .str_tok to get the import path, that's also been updated: // Zir.zirImport
const inst_data = sema.code.instructions.items(.data)[@intFromEnum(inst)].pl_node;
const extra = sema.code.extraData(Zir.Inst.Bin, inst_data.payload_index).data;
const src = block.nodeOffset(inst_data.src_node);
const operand = try sema.resolveConstString(
block,
src,
extra.rhs,
.{ .needed_comptime_reason = "import path must be comptime-known" },
); When this code runs,
It appears that the value I get back in Sema for Any pointers would be much appreciated--I can also push the WIP commit if that would be helpful, but I imagine that I'm probably missing something that will be obvious to people more familiar with this part of the codebase. |
You probably just need to clear your cache directory -- ZIR is cached based on However, your lowering strategy for |
Ha that was it, thanks! I made the same mistake yesterday and didn't quite understand how I fixed it--that had been bugging me glad to have it resolved.
Makes sense, will do! |
This was a bit odd, because it meant that only the coercion really needed to be checked, which isn't what I was intending to test.
Will give API more thought in followup
…s resolving types fully
ZON
This PR implements ZON, or Zig Object Notation (think JSON, but with Zig syntax instead of Javascript.)
In particular, it implements:
A lot of files are added since I added a lot of test cases, the bulk of the work is in
src/zon.zig
andlib/std/zon
. If there's anything I can do to make this easier to review, let me know.Tests cover all new features.
Runtime
The runtime code can be found at
lib/std/zon
.Parsing
lib/std/zon/parse.zig
Detailed doc comments are provided in the source. At a high level, this module provides the following functions and some configuration options:
parseFromSlice
parseFromAst
parseFromAstNode
parseFree
Most people will just want
parseFromSlice
and maybeparseFree
, but the more fine grained functions are available for those who needthem.
Stringify
lib/std/zon/stringify.zig
Detailed doc comments are provided in the source. At a high level, this module provides the following functions and some configuration options:
stringify
stringifyMaxDepth
stringifyArbitraryDepth
stringifier
Most users will just need stringify, or one of its variants.
However,
stringifier
returns a much more fine grained interface that is used in the implementation of the other functions. It may be used directly if you need to serialize something piece by piece--perhaps to apply different configuration to different parts of the value, or because the value does not actually exist laid out in memory in the same form in which you want to stringify it.Compile Time
Almost all of the logic for this is in
src/zon.zig
.This PR also implements importing ZON at compile time:
Things that may change later...
Untagged nonexhaustive enum values not yet supported
Zig does not currently have a way to represent an untagged enum value as a literal, and as such there's no way to represent one in ZON.
We could resolve this by adding a syntax for untagged enum literals to Zig, or by allowing ZON to coerce integers to untagged enum literals (provided the destination type is known.) Personally I prefer the former solution.
Allowing eliding outer braces may make sense
There's case to be made to allow eliding braces on an outer struct in ZON, like this:
Divergences from Zig
Zig has no NaN or inf literals right now. Zon does, since otherwise it would have no way to represent these values.
IMO we should add the same literals to Zig.
See Also
@import
.zon files #14531\x00
(null bytes) and empty string in@""
identifier syntax in the language specification #14534.
in tuples & anonymous struct literal syntax #5039