-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Labels
Milestone
Comments
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
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
Zig Version
0.14.0-dev.2443+3f7b3daaa
Steps to Reproduce and Observed Behavior
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 callsSema.instantiateGenericCall
instantiateGenericCall
notices that the resolved return type is comptime-only, so returnserror.ComptimeReturn
Sema.analyzeCall
catches this and performs a comptime call insteadTo fix this, the resolved argument values must be cached after they are first analyzed; perhaps by
CallArgsInfo
itself, or perhaps through some specialized mechanism betweenanalyzeCall
andinstantiateGenericCall
.The text was updated successfully, but these errors were encountered: