Add support for Decl Literal in .zon

[biom4st3r]

I'm working on an mmo ran into this issue where I'd like to use decl literals in my config files. I have this struct

pub const Skill = struct {
    pub const Forestry: Skill = .{ .name = "Forestry" };
    name: []const u8,
};

I'm specifically not using an enum, because the Client executable isn't supposed to know what skills exist until they are told about them. I reference the canonical skill(.Forestry) on the server and I'd like to also use it in my configs to I don't need to reach in and canonicalize it after parsing

.{
    .Tree = .{
        .name = "Tree",
        .desc = "It looks kind of sticky.",
        .results = .{
            .{
                .action = .Chop,
                .chance = 0.2,
                .result = .{
                    .item_name = "Log",
                    .amount = 1,
                },
                .exp = .{
                    .{
                        .skill = .Forestry,
                        //.{.name = "Forestry"},
                        .amount = 20,
                     },

[alexrp]

cc @MasonRemaley @mlugg

[MasonRemaley]

If we add support for this to the std zon parser, we should make sure it works when importing zon as well

[SeanTUT]

This should probably be more in depth. Decl literals can exist on structs unions, enums, and even pointers to any of those things (or opaques). Additionally, we can probably save on eval branch quota by checking for the decl with @hasDecl instead of a for loop. (forget that last part, I forgot this check was happening at runtime!)

Anyways, we should also be validating that the decl is of the correct type before returning it, or else we will just have a compile error when parsing any type that has decls which aren't valid decl literals.

[biom4st3r]

Oh yeah I can add this for those also. Also I do check the type on line 811

[biom4st3r]

Opaques are not supported in zon files and pointers should be handled by parseExprInner. However the pointer won't be a reference to the Declaration with my current implementation and propagating that information might be tricky.