improved error diagnostics when unable to inline a function

[andrewrk]

Actual Behavior

test3.zig

test {
    const p = &foo;
    p();
}

inline fn foo() void {}

$ stage2/bin/zig test test3.zig
Global is external, but doesn't have external or weak linkage!
void ()* @test3.foo

Expected Behavior

Allowed, but p is comptime pointer to a comptime-known function body. If var is used instead of const then it should be "error: pointer to inline function must be comptime-known"

[andrewrk]

inline functions can call themselves with #167 and the compiler will complain if there are too many backwards branches.

However, if an inline function calls itself in the generated (post-evaluated) function, then there should be an error.

[andrewrk]

This is actually a really hard problem. We want to catch things like indirect recursion with inline functions, but sometimes indirect recursion is fine, if it terminates.

LLVM handles this by ignoring the alwaysinline attribute when it can't do the inlining.

We can duplicate LLVM's analysis and logic, or we can try to reach back into the module post-optimization and discover if inlining failed.

[andrewrk]

I added a compile error for when an inline function cannot be inlined. It looks at the post-optimization module and sees if the function got inlined. However there are these harder, unsolved problems:

• There is no note: pointing to the cause of why the function cannot be inlined.
• There are cases when debug mode and release mode are different, because LLVM optimizations can do crazy stuff like figure out that indirect recursion is tail called and change it to a loop:

export fn foo() {
    bar();
}
inline fn bar() {
    quux();
    baz();
}
inline fn baz() {
    quux();
    bar();
}
extern fn quux();

In debug mode this gives error: unable to inline function but in release mode, it ends up figuring out this:

; Function Attrs: nounwind
define void @foo() local_unnamed_addr #0 !dbg !16 {
Entry:
  br label %tailrecurse.i
tailrecurse.i:                                    ; preds = %tailrecurse.i, %Entry
  tail call void @quux() #0, !dbg !22
  tail call void @quux() #0, !dbg !27
  br label %tailrecurse.i, !dbg !31
}

• We don't have a way to figure out if callsite inlining worked.

Moving this to another milestone to deal with.

[BarabasGitHub]

zig version
0.6.0+d4d509090

fn number() !void {
    _ = try @import("std").fmt.parseFloat(f64, &[_]u8{ 1, 2, 3, 4, 5 });
}

test "parseFloat" {
    _ = number;
}

gives:

..\lib\zig\std\fmt\parse_float.zig:55:5: error: unable to inline function
    inline fn shiftLeft1(d: *Z96, s: Z96) void {
    ^
..\lib\zig\std\fmt\parse_float.zig:62:5: error: unable to inline function
    inline fn add(d: *Z96, s: Z96) void {
    ^
..\lib\zig\std\fmt\parse_float.zig:48:5: error: unable to inline function
    inline fn shiftRight1(d: *Z96, s: Z96) void {
    ^

calling number works, but in my real code I do call the function (in some other function) and still get the same error.