argument of inline fn no longer propagates comptime-ness to result type expression

[rohlem]

EDIT: #22537 might fix this.

Until I've verified that it actually doesn't, this might not really be worth reading tbh.

Zig Version

0.14.0-dev.2837+f38d7a92c

Steps to Reproduce and Observed Behavior

So to keep it short, there exists a hack mechanism to inspect comptime-ness of arguments of inline fn by constructing a .{v} tuple (and inspecting the comptime-ness of its field via @typeInfo).
I'm not quite confident whether this is a supported use case, but the behavior here changed since 0.14.0-dev.2628+5b5c60f43,
and the new behavior is inconsistent, so I thought I'd report it and let maintainers decide what should happen.
Reproduction for zig test .zig:

fn E(comptime flag: bool) type {
    if (flag) return enum { @"comptime" };
    return enum { runtime };
}

inline fn isComptimeKnown(comptime ValueTuple: type) bool {
    return @typeInfo(ValueTuple).@"struct".fields[0].is_comptime;
}
inline fn f(value: u1) E(isComptimeKnown(@TypeOf(.{value}))) {
    if (isComptimeKnown(@TypeOf(.{value}))) {
        return .@"comptime"; //compile error: type mismatch (=> @TypeOf(.{value}) in function body != @TypeOf(.{value}) in result type expression)
    }
    return .runtime;
}

test "inline fn" {
    const x1: u1 = 0;
    var y1: u1 = 0;
    _ = &y1;
    if (f(comptime x1) != .@"comptime") unreachable; //causes compile error in 0.14.0-dev.2837+f38d7a92c, not in 0.14.0-dev.2628+5b5c60f43
    if (f(y1) != .runtime) unreachable;
}

test "inlined by hand" { // allowed by both 0.14.0-dev.2837+f38d7a92c and 0.14.0-dev.2628+5b5c60f43
    const x1: u1 = 0;
    const comptime_x1 = comptime x1;
    const f_result = @as(E(isComptimeKnown(@TypeOf(.{comptime_x1}))), f_result: {
        if (isComptimeKnown(@TypeOf(.{comptime_x1}))) {
            break :f_result .@"comptime"; //compile error: type mismatch (=> @TypeOf(.{value}) in function body != @TypeOf(.{value}) in result type expression)
        }
        break :f_result .runtime;
    });
    if (f_result != .@"comptime") unreachable;
}

Zig version 0.14.0-dev.2628+5b5c60f43 passes both tests.
Zig version 0.14.0-dev.2837+f38d7a92c succeeds test "inlined by hand" on its own, but fails compiling test "inline fn" as outlined in the comments. Compile error output:

.zig:11:17: error: enum '.zig.E(false)' has no member named 'comptime'
        return .@"comptime"; //compile error: type mismatch (=> @TypeOf(.{value}) in function body != @TypeOf(.{value}) in result type expression)
               ~^~~~~~~~~~~
.zig:3:12: note: enum declared here
    return enum { runtime };
           ^~~~~~~~~~~~~~~~
.zig:20:10: note: called from here
    if (f(comptime x1) != .@"comptime") unreachable; //causes compile error in 0.14.0-dev.2837+f38d7a92c, not in 0.14.0-dev.2628+5b5c60f43
        ~^~~~~~~~~~~~~

Expected Behavior

The primary inconsistency here is that the type constructed by .{value} always treats value as runtime-known in the return type expression, while it doesn't in the function body.
Not propagating comptime-ness means that the inline fn behaves semantically different from manually inlining its code.
(I thought I remembered a comment somewhere, I think from mlugg, basically saying that if I find such behavior I should report it as a bug - couldn't find it anymore so maybe I'm misremembering the details.)

If those are indeed the intended semantics, I'd have to instead use inline parameters once/if they're added (#7772).
Either way I believe code in the return type expression should not construct tuples differently than in the function body.

I assume this may be related in some way to #22494, which posits that the change was introduced in #22414. While a comment there mentions a change in behavior, that seems only related to comptime-only types, not inline fn arguments of all types.

[rohlem]

Looks like #22537 was opened while I was filing this issue - judging from the title that might be an exact fix for this as well!

[castholm]

@rohlem I tried running your repro using a compiler built from #22537 and it still failed. #22537 fixes it so that comptime-known arguments are allowed to be evaluated at comptime, but it does not appear to propagate the comptime-knownness of the arguments when evaluating the generic expressions. Here's a different repro that more directly demonstrates what is happening:

const std = @import("std");

pub fn main() void {
    const a: u1 = 0;
    std.debug.print("expect comptime:\n", .{});
    const result1 = foo(a, @enumFromInt(0));
    std.debug.print(" result:    {}\n", .{result1});

    var b: u1 = 0;
    _ = &b;
    std.debug.print("expect runtime:\n", .{});
    const result2 = foo(b, @enumFromInt(0));
    std.debug.print(" result:    {}\n", .{result2});
}

inline fn foo(
    x: u1,
    y: E(@typeInfo(@TypeOf(.{x})).@"struct".fields[0].is_comptime),
) E(@typeInfo(@TypeOf(.{x})).@"struct".fields[0].is_comptime) {
    const x_in_body: E(@typeInfo(@TypeOf(.{x})).@"struct".fields[0].is_comptime) = @enumFromInt(x);
    std.debug.print(" x_in_body: {}\n", .{x_in_body});
    std.debug.print(" y:         {}\n", .{y});
    return @enumFromInt(x);
}

fn E(comptime flag: bool) type {
    return if (flag) EC else ER;
}

const EC = enum { @"comptime" };
const ER = enum { runtime };

On 0.14.0-dev.2837+f38d7a92c this prints:

expect comptime:
 x_in_body: repro.EC.comptime
 y:         repro.ER.runtime 
 result:    repro.ER.runtime 
expect runtime:
 x_in_body: repro.ER.runtime 
 y:         repro.ER.runtime 
 result:    repro.ER.runtime 

On 0.13.0 it prints:

expect comptime:
 x_in_body: repro.EC.comptime
 y:         repro.ER.runtime
 result:    repro.EC.comptime
expect runtime:
 x_in_body: repro.ER.runtime
 y:         repro.ER.runtime
 result:    repro.ER.runtime

[mlugg]

#22537 definitely should be fixing this. I'll take a look in a moment.

[mlugg]

Agh, this is stupid shit related to how the param instruction works. This might take me a couple of days to figure out.

[mlugg]

okay i got the green light from Andrew to make an internally-significant-but-only-mildly-breaking language change which will restore this functionality without making the compiler code stupid. will hopefully sort it tomorrow

[rohlem]

Awesome, thanks so much to both of you! ❤

[castholm]

For posterity: The problem appears to be that the function is not considered generic under the current language rules. If we make it generic, we get the expected results with a compiler built from #22537:

diff --git a/repro_old.zig b/repro.zig
index 06fda7ab4a..ada4182ada 100644
--- a/repro_old.zig
+++ b/repro.zig
@@ -3,18 +3,19 @@ const std = @import("std");
 pub fn main() void {
     const a: u1 = 0;
     std.debug.print("expect comptime:\n", .{});
-    const result1 = foo(a, @enumFromInt(0));
+    const result1 = foo(u1, a, @enumFromInt(0));
     std.debug.print(" result:    {}\n", .{result1});
 
     var b: u1 = 0;
     _ = &b;
     std.debug.print("expect runtime:\n", .{});
-    const result2 = foo(b, @enumFromInt(0));
+    const result2 = foo(u1, b, @enumFromInt(0));
     std.debug.print(" result:    {}\n", .{result2});
 }
 
 inline fn foo(
-    x: u1,
+    comptime T: type,
+    x: T,
     y: E(@typeInfo(@TypeOf(.{x})).@"struct".fields[0].is_comptime),
 ) E(@typeInfo(@TypeOf(.{x})).@"struct".fields[0].is_comptime) {
     const x_in_body: E(@typeInfo(@TypeOf(.{x})).@"struct".fields[0].is_comptime) = @enumFromInt(x);

expect comptime:
 x_in_body: repro.EC.comptime
 y:         repro.EC.comptime
 result:    repro.EC.comptime
expect runtime:
 x_in_body: repro.ER.runtime 
 y:         repro.ER.runtime 
 result:    repro.ER.runtime