Inline fn fails to inline, but only if it's not called and @typeInfo has analysed it

[cshenton]

This is a bit awkward to explain, here's the repro, it was hard to make it smaller since this bug is quite strange, on 0.5.0+62c817420:

Try the following test with zig test repro.zig

• manually expect succeeds
• automatic expectEqual fails with an unrelated inline error
• if the "failed to inline" functions are actually called the inline error goes away 🤔

This is probably related to #3893 since expectEqual calls @typeInfo under the hood.

// repro.zig
const std = @import("std");
const sqrt = std.math.sqrt;

/// Mathematical vector type
fn Vector(comptime d: usize) type {
    return struct {
        vals: [d]f32,

        const Self = @This();

        pub inline fn zeros() Self {
            var vals: [d]f32 = undefined;
            comptime var i = 0;
            inline while (i < d) : (i += 1) {
                vals[i] = 0;
            }
            return Self{ .vals = vals };
        }

        pub inline fn sum(self: Self) f32 {
            var total: f32 = 0.0;
            for (self.vals) |val| {
                total += val;
            }
            return total;
        }

        pub inline fn mul(self: Self, other: Self) Self {
            const vs: @Vector(d, f32) = self.vals;
            const vo: @Vector(d, f32) = other.vals;

            return Self{ .vals = vs * vo };
        }

        pub inline fn dot(self: Self, other: Self) f32 {
            const product = self.mul(other);
            return product.sum();
        }
    };
}

const Vec2 = Vector(2);

// Tests

const expect = std.testing.expect;
const expectEqual = std.testing.expectEqual;

test "Inline failure" {
    // This works as it should
    const v = Vec2.zeros();
    expect(v.vals[0] == 0);
    expect(v.vals[1] == 0);

    // Uncommenting this causes an inline error
    // expectEqual(v, Vec2{ .vals = [2]f32{ 0, 0 }});

    // Uncommenting this gets rid of the error!?!?
    // const result = v.dot(v);
    // expect(result == 0);
}

[cshenton]

More details:

• This seems to only affect inline functions that are called by other member functions (the calling function can be inline or not, the problem, still occurs)
• Compilation succeeds so long as the inline fn call is somewhere in the compilation unit (so a call in another test would be fine)

[Vexu]

Inlining now happens during semantic analysis.