Zig stage2 erroneous backwards branch evaluation/segfault with recursive function

[jwhear]

Zig Version

0.10.0-dev.4198+5e0d8a435

Steps to Reproduce

Run zig test on the following code (heavily reduced to minimize surface area):

const std = @import("std");
const swap = std.mem.swap;

pub fn stablePartition(comptime T: type, slice: []T, predicate: fn(T) bool) i8 {
 if (slice.len == 0)
 return 0;
 _ = stablePartition(T, slice[1..], predicate);
 return 1;
}
test "stablePartition" {
 var items = [_]i8{0,1,2,3,4,5,6};
 _=stablePartition(i8, &items, isOdd);
}

fn isOdd(val: i8) bool {
 return val & 1 == 1;
}

By default this produces the following error:

min.zig:7:24: error: evaluation exceeded 1000 backwards branches
 _ = stablePartition(T, slice[1..], predicate);
 ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
min.zig:7:24: note: use @setEvalBranchQuota() to raise the branch limit from 1000
min.zig:7:24: note: called from here (999 times)
min.zig:14:22: note: called from here
 _=stablePartition(i8, &items, isOdd);
 ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~

Using @setEvalBranchQuota(5000) as suggested causes the compiler to crash on my machine. Note that this is during compilation, not runtime.

Expected Behavior

Running zig test -fstage1 min.zig compiles and runs successfully with all tests passing.

Actual Behavior

Backwards branches error or segfault if the branch quota is increased. There appears to be some kind of infinite recursion, perhaps in type inference/resolution.

[Vexu]

Duplicate of #12973

[topolarity]

I'm not sure this is a duplicate of #12973, since stablePartition should only be instantiated once.

I think we're missing "error: parameter of type 'fn (i8) bool' must be declared comptime"

@jwhear The example works if you update the function pointer for stage2:

pub fn stablePartition(comptime T: type, slice: []T, predicate: std.meta.FnPtr(fn(T) bool)) i8

std.meta.FnPtr returns fn(...) for stage1, and *const fn(...) for stage2

[jwhear]

Ah, good catch. I distantly remember reading this in the transition guide a while ago, but had forgotten all about it. Using FnPtr should unblock my code, though the compiler bug remains.

[Vexu]

This is then related to #13022 and probably caused by 8e4d0ae