`std.meta.stringToEnum` is hitting a `@setEvalBranchQuota` error even for small enums

[lapis pelican]

I have some code where I'm doing:

                const source: VertexAttributeSource = if (is_builtin)
                    std.meta.stringToEnum(VertexAttributeSource, attr_name) orelse .custom
                else
                    .custom;

Where the enum is:

pub const VertexAttributeSource = enum {
    /// Unused
    unused,

    /// Game code will write this attribute data
    custom,

    /// Position (vec3)
    position,

    /// Normal (vec3)
    normal,

    /// Texture coordinates (vec2)
    texcoords,

    /// `transform` from RenderMesh (mat4)
    transform,

    /// Entity id
    entity_id,
};

I'm hitting the 1500 limit in @setEvalBranchQuota(1500) (ComptimeStringMapWithEql), but my input strings are short and the enum is small.

It seems like all calls to ComptimeStringMapWithEql affect the branch quota, vs it being reset after leaving the function.

I'm iterating my list of shaders and calling this code on each one, and I started getting the error after adding a new shader, but it uses existing enum values, which is what makes me think the evaluation count is not reseting.

ie. I increased the number of times I call into stringToEnum, but not the size of the inputs to stringToEnum

I can easily work around it by using the inline for path in stringToEnum directly in my code instead, but interestingly the doc comments in there hint that the ComptimeStringMap is more performant, yet I don't hit the eval quota issue with inline for

[radiant lintel]

branch quota resetting when returning from a function has never been a thing

A comptime/inline call counts against the quota and the same quota continues applying after that function returns. A runtime call doesn't affect the current quota at all, and the callee gets the default quota when analyzed separately as an independent decl.

[lapis pelican]

Aah ok. This is consistent with what I'm seeing, thanks for the clarification