Make the @compileError builtin variadic #32119

Background

A common use case for @compileError is to print error messages regarding incorrect types in generic code. For instance, an error message from std.Io.Writer.print might read something like this:

error: expected numeric type for 'd' format, found: main.MyStruct

Right now, the only real way to do this is with @typeName and string concatenation, for instance:

@compileError("expected numeric type for 'd' format, found: "++@typeName(T));

This works, but it isn't ideal:

• The compile error lacks the "type declared here" error note which built-in errors would usually emit
• The behavior of @typeName cannot be precisely specified in the Zig language specification, so it may be desirable to modify its behavior in the future, or even remove it entirely
• String concatenation can be a little bit visually noisy to read compared with alternatives

The first point above is the main one this proposal is trying to fix---the other issues are just nice bonuses.

Proposal

Make @compileError variadic. Arguments can either have type []const u8 (with appropriate coercions of course) or type. The error to be printed is constructed by concatenating the argument strings together, converting types to their names (as with @typeName and compiler-generated errors).

The above snippet would therefore be written as follows:

@compileError("expected numeric type for 'd' format, found: ",T);

This solves each of the issues I listed above. Most importantly, the error message will include a note mentioning where the type was declared:

error: expected numeric type for 'd' format, found: main.MyStruct
note: struct 'main.MyStruct' declared here

The status-quo solution I reach for is the following helper function:

fncompileErrorFmt(comptimefmt:[]constu8,args:anytype)noreturn{@compileError(@import("std").fmt.comptimePrint(fmt,args));}comptime{compileErrorFmt("bytes: 0x{x}, string: {s}, type: {}",.{"abc","abc",u23});}

This offers the full configurability of std.fmt / Io.Writer.print, with custom .format method via {f} etc., and also supports type arguments via {} in status-quo.
Is this planned to continue to work?
I hope support of {} formatting placeholder for type arguments isn't planned to be removed - I find it quite useful in other runtime-debugging scenarios too.

I also don't like the thought of removing @typeName entirely - however arbitrary the result may be, I know in some scenarios previously I would have bitten the bullet and written a bunch of boilerplate to re-implement it in userland by hand, just to arrive at more-or-less the same result.

Why would @typeName be removed, what are the problems it causes for specifications ?

To be clear: changes to @typeName were not a reason we accepted this proposal. The only reason I brought them up is because this proposal happens to eliminate a common use case for @typeName, which might help to inform the future of that builtin.

The issue with @typeName is simply that its behaviour (i.e. the string it returns) is necessarily implementation-defined and cannot be codified in a language specification, because we cannot reasonably standardise the compiler's approach to generating names for types which don't have an obvious user-provided name. The concern is that some codebases already use @typeName in a way which relies heavily on how our compiler generates type names, so in the future this would be likely to lead to Zig projects which do not compile on other compiler implementations, which is a bad experience for all involved.

However, this proposal is not about @typeName, and there are currently no plans to modify or remove @typeName. I apologize If I gave a different impression in the OP. If we do consider that, it will be its own proposal, and can be discussed there, but in the meantime, let's try to keep this thread focused on the proposal in the OP.

Out of interest:
What is the benefit of making it variadic vs. using the same signature that print already supports?
fn compileError(comptime fmt: []const u8, args: anytype) noreturn
or
fn compileError(comptime fmt: []const u8, args: |T|) noreturn

given #32099 is accepted.

@JanBeelte wrote in #32119 (comment):

Out of interest: What is the benefit of making it variadic vs. using the same signature that print already supports? fn compileError(comptime fmt: []const u8, args: anytype) noreturn or fn compileError(comptime fmt: []const u8, args: |T|) noreturn

given #32099 is accepted.

You do not have access to line of declaration with @typeInfo. Only the compiler knows, you can't retrieve this information. The change from anytype syntax does not impact this proposal, since it does not allows us to get the line of declarations at comptime.

"Most importantly, the error message will include a note mentioning where the type was declared"

Have you considered exposing this functionality to user space by instead modifying the @src() builtin to accept a type parameter? Perhaps this could shift the implementation of more of the compiler error notes into user space and out of compiler space.

As proposed, the modification to @compileError lacks "declare intent precisely". I provide a type but I get the string name of the type... If we are concerned with querying source locations perhaps we could enable more precise source location queries with @src.

I think we should take the inability of a user of the language to produce the compile errors they want as an opportunity to improve the error messages generated by the compiler rather than further offloading that responsibility to the user.

You do not have access to line of declaration with @typeInfo.

Maybe obvious, but we already have @src(), so I think adding a @declSrc(T: type) builtin for exactly this shouldn't be too much trouble.

I also like the implicit approach of "improve the compiler instead of offloading responsibility to users" - the question is whether the compiler can be made to do "the right thing" / be maximally helpful.

Another alternative to consider: On every compile error, attach notes about (/ include in the call stack) every comptime argument and the type of every anytype argument in the call stack (probably only the first time it appears). If they're types, provide declared/defined here notes.
This would have been pretty useful to me previously. Maybe it bloats the stack trace too much, in which case we could put it behind a cli flag similar to -freference-trace.

Of course the improved error messages is nice, but you should consider exposing the right primitives (@declSrc) to library authors, instead of holding them in the hands of the compiler team.

That's a great feature of Zig and comptime, let users do stuff that normally you would need a compiler patch to do.

What if variadic @compileError didn't work like a variadic print, but args you put after the first arg were explicitly types or source info structs that appended type trace, etc. info to the compile error?

@compileError(message:[]constu8,[trace_type:type,...])

where each trace_type arg adds "T declared here" messaging. If there are other trace types you want to add in the future, that could be based on the type passed in. E.g. a SourceLocation or w.e. Can't think of anything in particular at the moment, just trying to spell out why this wouldn't be painting the arg spec into too tight of a corner.

Consider if you have a generic type, and you know one of the type parameters because you stashed it in a decl or want to extract it from a field type (like the element type of items in an ArrayList, or of an array or slice), and you want to print the generic type name, but also show info about one of the type parameters.

@compileError("Expected sequence of container types with a 'format' function, instead got "++@typeName(T),T,std.meta.Elem(T));

which would print the name of T in the message, and also print type traces for T and its element type

You'd need to add a "T is ", GenericType.InputType param pair in order to get it to print the trace info separately for that relevant type decl, but then you're kinda just bloating the error message.

That more directly solves the problem, but does also imply that you'd keep some form of @typeName so that we could format the message arg well.

I'd be able to produce better generic errors with that kind of setup. But even variadic @compileError as proposed would be a big W.

the proposal is not proposing printf-style and the prime example is one just like yours but it goes beyond that.
you could also do something like this @compileError("expected type ", T, " got ", Q); for example

Yeah I understand the proposal, I think I didn't convey what I'm describing well

I'm saying: don't make the variadic args things with their string repr concatenated to the message. Rely on the existing string concatenation mechanism (++ or std.fmt.comptimePrint) and have the extra args just append compiler-generated notes.

In the example I wrote:

@compileError("Expected sequence of container types with a 'format' function, instead got "++@typeName(T),T,std.meta.Elem(T));

Assume T is []i32 This would print:

Expected sequence of container types with a 'format' function, instead got []i32
note: i32 is a primitive type
note: [...whatever else for a type trace...]
note: []i32 declared here: wherever/in/your/project/you/have/that/slice.zig
note: [...whatever else for a type trace...]

With the proposal as-is, I think you'd achieve something similar with this:

@compileError("Expected sequence of container types with a 'format' function, instead got " , T, ", elem type: ", std.meta.Elem(T));

which I think would print something like:

Expected sequence of container types with a 'format' function, instead got []i32, elem type: i32
note: i32 is a primitive type
note: [...whatever else for a type trace...]
note: []i32 declared here: wherever/in/your/project/you/have/that/slice.zig
note: [...whatever else for a type trace...]

To get it to print the type trace for i32 it needs to be included in the concatenated args, versus explicitly separating the message from things that append trace info in the argument list.

[EDIT] Just thought of another good use case, if you pass function body arguments, that might be a weird thing to format (you'd wanna format the type of the function), but you might ostenibly want to get a "function declared here" compiler note.