inappropriate cannot store runtime value in compile time variable in generic tuple for loop

[ExpandingMan]

Zig Version

0.8.1

Steps to Reproduce

const Builder = @import("std").build.Builder;

pub fn build(b: *Builder) void {
    const exe = b.addExecutable("tvu", "src/main.zig");

    const tests = b.addTest("src/main.zig");

    //WARN: the below is causing a compile error for some reason
    const tomlpath = "lib/zig-toml/src/toml.zig";
    inline for (.{ exe, tests }) |x| {
        x.addPackagePath("toml", tomlpath);
    }

    const test_step = b.step("test", "run tests");
    test_step.dependOn(&tests.step);

    exe.install();
}

Run with zig build. Values of string literals here should have no effect on this error.

Expected Behavior

At the very least, I'd expect the loop to lower to

exe.addPackagePath("toml", path);
tests.addPackagePath("toml", path);

I tried to create an MWE

const std = @import("std");

const A = struct {
    z: f64,

    pub fn f(self: @This()) void {
        std.log.info("what up! {any}", .{self.z});
    }
};

const B = struct {
    z: f64,

    pub fn f(self: @This()) void {
        std.log.info("what up! {any}", .{self.z});
    }
};

pub fn main() !void {
    const a = A{ .z = 0.0 };
    const b = B{ .z = 1.0 };

    inline for (.{ a, b }) |x| {
        x.f();
    }
}

but this works fine. Unfortunately it may not be a perfect comparison: a and b are fully-known at compile time, but I'm unsure if this is the case for exe and tests (perhaps they hold run-time information from the file-system).

Regardless, this is clearly equivalent to simply calling .addPackagePath twice, so it seems to me that it should work regardless of whether the variables contain run-time information.

Actual Behavior

./build.zig:11:35: error: cannot store runtime value in compile time variable
    inline for (.{ exe, tests }) |x| {
                                  ^

[SpexGuy]

Duplicate of #280. The workaround is to use inline while with a counter, or, in this case, use [_]*LibExEObjStep and a normal for instead of a tuple.