Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Arguments are evaluated multiple times when a generic return type turns out to be comptime-only #22262

Closed
mlugg opened this issue Dec 17, 2024 · 0 comments · Fixed by #22414
Closed
Labels
bug Observed behavior contradicts documented or intended behavior frontend Tokenization, parsing, AstGen, Sema, and Liveness.
Milestone

Comments

@mlugg
Copy link
Member

mlugg commented Dec 17, 2024

Zig Version

0.14.0-dev.2443+3f7b3daaa

Steps to Reproduce and Observed Behavior

test {
    comptime var foo: u32 = 0;
    _ = bar({
        foo += 1;
    });
    @compileLog(foo);
}

fn bar(val: anytype) if (@TypeOf(val) == void) comptime_int else u32 {
    return 123;
}
$ zig test foo.zig
foo.zig:6:5: error: found compile log statement
    @compileLog(foo);
    ^~~~~~~~~~~~~~~~

Compile Log Output:
@as(u32, 2)

Expected Behavior

The logged value should be 1, because the argument expression should only be evaluated once.

This happens because:

  • Sema.analyzeCall notices that we are calling a generic function, so calls Sema.instantiateGenericCall
  • After evaluating the arguments, instantiateGenericCall notices that the resolved return type is comptime-only, so returns error.ComptimeReturn
  • Sema.analyzeCall catches this and performs a comptime call instead
  • This code path re-evaluates the arguments

To fix this, the resolved argument values must be cached after they are first analyzed; perhaps by CallArgsInfo itself, or perhaps through some specialized mechanism between analyzeCall and instantiateGenericCall.

@mlugg mlugg added the bug Observed behavior contradicts documented or intended behavior label Dec 17, 2024
@mlugg mlugg added this to the 0.14.0 milestone Dec 17, 2024
@mlugg mlugg changed the title Parameters are evaluated multiple times when a function return type turns out to be comptime-only Parameters are evaluated multiple times when a generic return type turns out to be comptime-only Dec 17, 2024
@andrewrk andrewrk added the frontend Tokenization, parsing, AstGen, Sema, and Liveness. label Dec 17, 2024
@mlugg mlugg changed the title Parameters are evaluated multiple times when a generic return type turns out to be comptime-only Arguments are evaluated multiple times when a generic return type turns out to be comptime-only Jan 2, 2025
mlugg added a commit to mlugg/zig that referenced this issue Jan 5, 2025
This rewrite improves some error messages, hugely simplifies the logic,
and fixes several bugs. One of these bugs is technically a new rule
which Andrew and I agreed on: if a parameter has a comptime-only type
but is not declared `comptime`, then the corresponding call argument
should not be *evaluated* at comptime; only resolved. Implementing this
required changing how function types work a little, which in turn
required allowing a new kind of function coercion for some generic use
cases: function coercions are now allowed to implicitly *remove*
`comptime` annotations from functions with comptime-only types. This is
okay because removing the annotation affects only the call site.

Resolves: ziglang#22262
mlugg added a commit to mlugg/zig that referenced this issue Jan 5, 2025
This rewrite improves some error messages, hugely simplifies the logic,
and fixes several bugs. One of these bugs is technically a new rule
which Andrew and I agreed on: if a parameter has a comptime-only type
but is not declared `comptime`, then the corresponding call argument
should not be *evaluated* at comptime; only resolved. Implementing this
required changing how function types work a little, which in turn
required allowing a new kind of function coercion for some generic use
cases: function coercions are now allowed to implicitly *remove*
`comptime` annotations from parameters with comptime-only types. This is
okay because removing the annotation affects only the call site.

Resolves: ziglang#22262
mlugg added a commit to mlugg/zig that referenced this issue Jan 5, 2025
This rewrite improves some error messages, hugely simplifies the logic,
and fixes several bugs. One of these bugs is technically a new rule
which Andrew and I agreed on: if a parameter has a comptime-only type
but is not declared `comptime`, then the corresponding call argument
should not be *evaluated* at comptime; only resolved. Implementing this
required changing how function types work a little, which in turn
required allowing a new kind of function coercion for some generic use
cases: function coercions are now allowed to implicitly *remove*
`comptime` annotations from parameters with comptime-only types. This is
okay because removing the annotation affects only the call site.

Resolves: ziglang#22262
mlugg added a commit to mlugg/zig that referenced this issue Jan 5, 2025
This rewrite improves some error messages, hugely simplifies the logic,
and fixes several bugs. One of these bugs is technically a new rule
which Andrew and I agreed on: if a parameter has a comptime-only type
but is not declared `comptime`, then the corresponding call argument
should not be *evaluated* at comptime; only resolved. Implementing this
required changing how function types work a little, which in turn
required allowing a new kind of function coercion for some generic use
cases: function coercions are now allowed to implicitly *remove*
`comptime` annotations from parameters with comptime-only types. This is
okay because removing the annotation affects only the call site.

Resolves: ziglang#22262
mlugg added a commit to mlugg/zig that referenced this issue Jan 5, 2025
This rewrite improves some error messages, hugely simplifies the logic,
and fixes several bugs. One of these bugs is technically a new rule
which Andrew and I agreed on: if a parameter has a comptime-only type
but is not declared `comptime`, then the corresponding call argument
should not be *evaluated* at comptime; only resolved. Implementing this
required changing how function types work a little, which in turn
required allowing a new kind of function coercion for some generic use
cases: function coercions are now allowed to implicitly *remove*
`comptime` annotations from parameters with comptime-only types. This is
okay because removing the annotation affects only the call site.

Resolves: ziglang#22262
mlugg added a commit to mlugg/zig that referenced this issue Jan 6, 2025
This rewrite improves some error messages, hugely simplifies the logic,
and fixes several bugs. One of these bugs is technically a new rule
which Andrew and I agreed on: if a parameter has a comptime-only type
but is not declared `comptime`, then the corresponding call argument
should not be *evaluated* at comptime; only resolved. Implementing this
required changing how function types work a little, which in turn
required allowing a new kind of function coercion for some generic use
cases: function coercions are now allowed to implicitly *remove*
`comptime` annotations from parameters with comptime-only types. This is
okay because removing the annotation affects only the call site.

Resolves: ziglang#22262
@mlugg mlugg closed this as completed in e9bd2d4 Jan 10, 2025
Fri3dNstuff pushed a commit to Fri3dNstuff/zig that referenced this issue Jan 27, 2025
This rewrite improves some error messages, hugely simplifies the logic,
and fixes several bugs. One of these bugs is technically a new rule
which Andrew and I agreed on: if a parameter has a comptime-only type
but is not declared `comptime`, then the corresponding call argument
should not be *evaluated* at comptime; only resolved. Implementing this
required changing how function types work a little, which in turn
required allowing a new kind of function coercion for some generic use
cases: function coercions are now allowed to implicitly *remove*
`comptime` annotations from parameters with comptime-only types. This is
okay because removing the annotation affects only the call site.

Resolves: ziglang#22262
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Observed behavior contradicts documented or intended behavior frontend Tokenization, parsing, AstGen, Sema, and Liveness.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants