Hmm, on the other hand, it may be possible to prove that the error message could never be displayed in the case that it is an error set. For instance if it is the return type of a function it will force the function to be compile-time.

Yes, my assumption was comes from the fact that there isn't a way to create a non-comptime error set (but I might be wrong on this). That means a value being non-comptime implies it isn't an error set.

A more conservative approach could be changing the note to what @silversquirl suggested.

I think there could still be a problem if the comptime reason ends up being something else inside a function that returns an error set. Then the comptime reason trace would include the line "operand to error set merge (||) must be an error set" while pointing to an operand that is, indeed, an error set.

Example:

test "example" {
    const A = error{A};
    const B = A || foo();
    _ = B;
}
fn foo() type {
    bar();
    return error{B};
}
extern fn bar() void;

test.zig:7:8: error: comptime call of extern function
    bar();
    ~~~^~
test.zig:3:23: note: called at comptime from here
    const B = A || foo();
                   ~~~^~
test.zig:3:23: note: types must be comptime-known

the main reason i suggested changing "an error set" to "a type" is because "error set" is confusing - it somewhat implies a value of type error { ... }, not an error set type itself (which is of type type).

@andrewrk i think this confusion is demonstrated quite well by the fact that your example actually makes exactly this mistake! foo() should return type, not error{B} :)

Oops! Good catch. I think both of our points stand.