Compiler: allow functions prototypes to have their own scopes

[wrongnull]

Closes #15409
This patch adds scopes to functions prototypes. It may be useful for describing dependence of one parameter from another one. For instance:

const proto = fn (arg0: getType(), arg1: @TypeOf(arg0)) void;

With this capability compiler must be able to detect shadowing from current and enclosing scopes. However, when generics are involved in cases like the following:

const proto = fn(comptime T: type, arg: T)

compiler cannot infer second type and treats it as anytype. But the very same behavior appears in the latest compiler dev version with generic functions (not prototypes). I'm pretty sure that this doesn't apply to the original issue
Finally, it turned out that there was several local shadowings in the compiler_rt and std source code. I fixed it as well.

[Vexu]

Unused.

[wrongnull]

Unused.

This is true but without it the compiler crashes with 'use of null' at line 11328 in AstGen.zig in addFunc. There is following doc comment in above this fuction

/// Must be called with the following stack set up:
    ///  * gz (bottom)
    ///  * align_gz
    ///  * addrspace_gz
    ///  * section_gz
    ///  * cc_gz
    ///  * ret_gz
    ///  * body_gz (top)

[Vexu]

Huh, it's strange how it properly checks each of them individually in the else branch but only ret_gz in the then branch.

[wrongnull]

Should I rewrite this check in addFn or let it be as it is?

[Vexu]

Also unused.

[wrongnull]

Also unused.

Same here

[Vexu]

I don't think there is any benefit to separating this from @"function parameter".

[wrongnull]

I don't think there is any benefit to separating this from @"function parameter".

I think with such wording compiler diagnostics are more accurate. But I can delete it if necessary

[mlugg]

As mentioned on Discord, I do not think this is a desirable change. Allowing references to prior parameters when writing function types implies stronger guarantees on generic function types than actually exist. For instance, under this change, the following equality holds:

fn (x: anytype) @TypeOf(x) == fn (x: anytype) ?@TypeOf(x)

Zig does not have a good way to represent specific generic function types at the type level; unless this changes. allowing you to write these types and then "demoting" them to the representable generic type (in this case printed as fn (anytype) anytype, although this is currently invalid syntax to actually write) seems to me misleading at best.

[wrongnull]

As mentioned on Discord, I do not think this is a desirable change. Allowing references to prior parameters when writing function types implies stronger guarantees on generic function types than actually exist. For instance, under this change, the following equality holds:

fn (x: anytype) @TypeOf(x) == fn (x: anytype) ?@TypeOf(x)

Zig does not have a good way to represent specific generic function types at the type level; unless this changes. allowing you to write these types and then "demoting" them to the representable generic type (in this case printed as fn (anytype) anytype, although this is currently invalid syntax to actually write) seems to me misleading at best.

This behavior already in master. And users can face to the very same issue using @TypeOf . In this case this patch just preserves already existing behavior

fn foo(x: anytype) @TypeOf(x) {
    return x;
}

fn bar(x: anytype) ?@TypeOf(x) {
    return null;
}


pub fn main() void {
    @compileLog(@TypeOf(foo) == @TypeOf(bar));
}

Compile Log Output:
@as(bool, true)

[mlugg]

This behavior already in master. [...] In this case this patch just preserves already existing behavior

No, this patch takes a behavior from one part of the language, and applies it to a different part of the language. Consistency between these syntax forms is not itself a fundamental end goal here: to make this change, you must justify why allowing backreferences is useful/important despite these equivalences. Justifying this is the job of a language proposal.

In function declarations, we have to allow backreferences, because this is fundamental to Zig's system of generics. The way the type system interacts with generics there is certainly unfortunate, but it does not call for us to eliminate backreferences entirely, since the type of a generic function is only a small detail of it (it's actually fairly rare to interact much, if at all, with generic function types in Zig code). On the other hand, in function types, there is zero practical use for these backreferences in a way which is not explicitly misleading - writing generic function types, where (since the whole thing you're doing is writing a type) the syntax strongly implies that the type is encoding the constraints you are writing when, in reality, it is not.

I believe this change should be a language proposal (and it is a proposal I would personally oppose).

[andrewrk]

I've converted #15409 into a language proposal; we can continue the discussion there. This code is still available to be resurrected depending on the outcome.