Change builtins to return a string literal

[jmc-88]

Fixes issue #3779 (I think?).

[Vexu]

@tagName and @errorName should both return a null terminated slice instead since they can be used with runtime known arguments and returning different types based on whether they are being executed at comptime or not is bad for generic code.

[marler8997]

Looks like @andrewrk was the one to suggest that we use pointers to arrays when the length is comptime known (see #3779 (comment)). I can see how this could cause some issues with generic code, but I think sometimes this information is necessary, so I don't see much choice other than to expose it.

[Vexu]

I assumed he was referring to @embedFile and @typeName since they are always comptime but I could be wrong.

[jmc-88]

Looks like @andrewrk was the one to suggest that we use pointers to arrays when the length is comptime known (see #3779 (comment)).

Yes, I took that comment as reference, and probably misunderstood it, and here we are. 😄

@tagName and @errorName should both return a null terminated slice instead since they can be used with runtime known arguments and returning different types based on whether they are being executed at comptime or not is bad for generic code.

Just for extra n00b-friendly clarity, the desire is to ensure these builtins all return [:0]const u8?

[Vexu]

This change should also apply to all the strings in std.builtin.TypeInfo, and yes [:0]const u8 is the correct type.

[Vexu]

Are you still interested in finishing this pr? I'd be happy to do it for you if not.

[jmc-88]

Sorry, yeah, I'd like to work on this. I got busy with real life and now I have a scary rebase in front of me 😄

I'll update this PR as soon as possible and ping the thread.

[jmc-88]

I have updated the PR and it seems to pass test-behavior locally, PTAL.

[Vexu]

Looks good so far, do you also want to make the change to @typeInfo and @src?

[jmc-88]

Looks good so far, do you also want to make the change to @typeInfo and @src?

I have local changes ready to update string fields contained in structures returned by these two builtins to [:0]const u8.

But while applying changes to @typeInfo() I realized its std.builtin.TypeInfo output is also an input to @Type() and that could break existing code. For instance, this assignment fails since it uses a []const u8 as returned by std.mem.tokenize() and that can't implicitly cast to [:0]const u8:

zig/test/behavior/bugs/6456.zig

Line 20 in e006281

.name = name,

Would you say this is WAI?

EDIT: to clarify, this seems to make it impossible to use a similar pattern where std.mem.tokenize() is used at comptime, unless there's a way to do comptime memory allocations for ensuring the slice is null-terminated.

[Vexu]

Hmm, I didn't think of that. I see three ways to solve this:

1. Have separate types for @typeInfo and @Type, which would break even more code.
2. Leave things as they are, which kind of defeats the purpose of this change.
3. Add casts from []T -> [:t]T and *[N]T -> *[N:t]T when the value is comptime known, which would make this change purely cosmetic.

I'll make an issue for this since this pr is already useful as is.