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

concat (++) of anytype function parameter for runtime call #14817

Closed
trgwii opened this issue Mar 6, 2023 · 5 comments
Closed

concat (++) of anytype function parameter for runtime call #14817

trgwii opened this issue Mar 6, 2023 · 5 comments
Labels
question No questions on the issue tracker, please.
Milestone

Comments

@trgwii
Copy link

trgwii commented Mar 6, 2023

Zig Version

0.11.0-dev.1863+a63134a4a

Steps to Reproduce and Observed Behavior

Given the following code:

const std = @import("std");

fn concat(x: anytype) []const u8 {
    return x ++ " world";
}

pub fn main() !void {
    std.debug.print("comptime: {s}\n", .{comptime concat("hello")});
    std.debug.print("runtime : {s}\n", .{concat("hello")});
    std.debug.print("inline  : {s}\n", .{@call(.always_inline, concat, .{"hello"})});
}

zig run concat.zig produces:

comptime: hello world
runtime : hellrld
inline  : hello world

zig run -O ReleaseFast concat.zig produces:

comptime: hello world
runtime : 
inline  : hello world

Expected Behavior

I would either expect a compile error complaining about ++ being used at runtime, or I would expect ++ to force comptime evaluation, and give the following output:

comptime: hello world
runtime : hello world
inline  : hello world

EDIT: I think the best option is ++ forcing comptime evaluation, so it'll compile error with "can't resolve comptime value" or whatever for actual runtime values, and just work if the value is comptime-known.

@trgwii trgwii added the bug Observed behavior contradicts documented or intended behavior label Mar 6, 2023
@ifreund ifreund added the miscompilation The compiler reports success but produces semantically incorrect code. label Mar 6, 2023
@ifreund ifreund added this to the 0.11.0 milestone Mar 6, 2023
@jacobly0
Copy link
Member

jacobly0 commented Mar 7, 2023

Runtime ++ creates a value on the stack which cannot be returned as a pointer. This is invalid for the same reason that dereferencing the result of the following function is:

fn f() *u32 {
    var x: u32 = 42;
    return &x;
}

@andrewrk andrewrk added question No questions on the issue tracker, please. and removed bug Observed behavior contradicts documented or intended behavior miscompilation The compiler reports success but produces semantically incorrect code. labels Mar 7, 2023
@andrewrk
Copy link
Member

andrewrk commented Mar 7, 2023

related: #3180

@andrewrk andrewrk closed this as not planned Won't fix, can't repro, duplicate, stale Mar 7, 2023
@trgwii
Copy link
Author

trgwii commented Mar 7, 2023

Runtime ++ creates a value on the stack which cannot be returned as a pointer. This is invalid for the same reason that dereferencing the result of the following function is:

fn f() *u32 {
    var x: u32 = 42;
    return &x;
}

But why is it a runtime ++ when both parameters are comptime-known?

@jacobly0
Copy link
Member

jacobly0 commented Mar 7, 2023

Parameters are never comptime-known unless they are marked comptime, the function is called at comptime, or a value with a comptime-only type is passed to an anytype parameter. The type of a string literal is a const pointer to a zero terminated array which is not a comptime-only type (as in, you are allowed to have runtime values with that type).

@mlugg
Copy link
Member

mlugg commented Mar 7, 2023

(they're also comptime-known if the function is marked inline and the parameter was comptime-known at the call site)

Note that the reason the operands don't have to be comptime-known here is that their lengths are known by their types, since the type passed in is e.g. *const [5:0]u8. That means the compiler can emit code to concatenate these into a local buffer at runtime, since the buffer length is known at compile time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question No questions on the issue tracker, please.
Projects
None yet
Development

No branches or pull requests

5 participants