-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inferred error sets + generic interfaces = stage2 crashes #12806
Comments
This code is triggering an assertion
|
I'm getting that now too. Is that the correct behavior do you think or? |
i ran into a similar issue. not 100% sure it is the same but seems related. here is a reproduction: const std = @import("std");
fn foo(a: anytype) !void {
if (a == 0) return error.A;
return error.B;
}
const Error = error{ A, B };
test {
const info = @typeInfo(@TypeOf(foo));
const ret_type = info.Fn.return_type.?;
const error_set = @typeInfo(ret_type).ErrorUnion.error_set;
_ = Error || error_set;
} This also crashes the compiler. Althought not from this repro, a similar debug error trace was shared in discord by @nektro |
@ibokuri test.zig:28:51: error: unable to resolve inferred error set of generic function
pub usingnamespace Writer(@This(), Ok, Error, write);
^~~~~
test.zig:34:9: note: generic function declared here
pub fn write(_: @This(), value: anytype) !Ok {
~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I'm not sure if this the correct behavior. |
I'd agree it's correct personally |
Zig Version
0.10.0-dev.3978+4fd4c733d
Steps to Reproduce
Run the following program using the stage2 compiler (and a recent version of Zig).
Expected Behavior
$ zig build run true
Actual Behavior
The problem seems to only come up when the interface type (
W
) is returned within a namespace instead of as-is (e.g.,std.io.Writer
doesn't run into this issue since the interface type's returned directly). For some reason, having the interface type nested like this causes stage2 compilations to crash if a method implementation provided to the interface:anytype
parameter andThis behavior doesn't come up when building with
-fstage1
and wasn't an issue for me in stage2 until I upgraded this morning.The text was updated successfully, but these errors were encountered: