ziglang/zig

Fork 772

Code Issues 707 Pull requests 292 Activity Actions 25

Legacy issue regarding comptime `std.fmt.bufPrint` (#5401) #35435

New issue

Open

opened 2026年05月23日 22:01:15 +02:00 by ej-shafran · 3 comments

ej-shafran commented

2026年05月23日 22:01:15 +02:00

Contributor

Copy link

See #5401.

Creating this issue as a copy-on-write.

See [#5401](https://github.com/ziglang/zig/issues/5401). Creating this issue as a copy-on-write.

ej-shafran changed title from ~~(削除) Legacy issue regarding comptime std.fmt.*print functions (#5401) (削除ここまで)~~ to Legacy issue regarding comptime std.fmt.bufPrint (#5401)

2026年05月23日 22:02:44 +02:00

ej-shafran commented

2026年05月23日 22:04:53 +02:00

Author

Contributor

Copy link

Is this issue relevant anymore? It's being tracked in #31661, but I'm unsure if it should count as untested as there are tests for std.fmt.comptimePrint which does this internally, along with many many tests which use expectFmt which also does this.

Currently doing what the reproduction in the original issue does (i.e. std.fmt.comptimePrint("{}", .{"some string"}) causes a @compileError saying cannot format slice without a specifier (i.e. {s}, {x}, {b64}, or {any}), which seems like correct behavior but which I don't know how to test for...

Is this issue relevant anymore? It's being tracked in #31661, but I'm unsure if it should count as untested as there are tests for `std.fmt.comptimePrint` which does this internally, along with many many tests which use `expectFmt` which also does this. Currently doing what the reproduction in the original issue does (i.e. `std.fmt.comptimePrint("{}", .{"some string"})` causes a `@compileError` saying `cannot format slice without a specifier (i.e. {s}, {x}, {b64}, or {any})`, which seems like correct behavior but which I don't know how to test for...

ej-shafran commented

2026年05月23日 22:07:29 +02:00

Author

Contributor

Copy link

Also, apologies if opening this issue is the incorrect approach for this discussion...

pancelor commented

2026年05月24日 08:09:36 +02:00

Contributor

Copy link

I agree, "cannot format slice without a specifier" looks correct to me for that old code. Here's my modern repro (zig 0.16.0)

test{comptimevarbuf=[_]u8{0}**16;conststr=comptimetrystd.fmt.bufPrint(&buf,"{s} {s}",.{"test","123"});conststr2:[str.len]u8=str[0..].*;// avoid "error: runtime value contains reference to comptime var"trystd.testing.expectEqualStrings("test 123",&str2);}conststd=@import("std");

That "avoid error" line is pretty gnarly (maybe there's a better way?) but this should now be correctly testing the old bug, as far as I understand it.

edit: I dug around and found these tests:

lib/std/fmt.zig

Lines 648 to 666 in b868412

pubinlinefncomptimePrint(comptimefmt:[]constu8,args:anytype)*const[count(fmt,args):0]u8{

comptime{

varbuf:[count(fmt,args):0]u8=undefined;

_=bufPrint(&buf,fmt,args)catchunreachable;

buf[buf.len]=0;

constfinal=buf;

return&final;

}

testcomptimePrint{

@setEvalBranchQuota(2000);

trystd.testing.expectEqual(*const[3:0]u8,@TypeOf(comptimePrint("{}",.{100})));

trystd.testing.expectEqualSlices(u8,"100",comptimePrint("{}",.{100}));

trystd.testing.expectEqualStrings("30",comptimePrint("{d}",.{30.0}));

trystd.testing.expectEqualStrings("30.0",comptimePrint("{d:3.1}",.{30.0}));

trystd.testing.expectEqualStrings("0.05",comptimePrint("{d}",.{0.05}));

trystd.testing.expectEqualStrings("5e-2",comptimePrint("{e}",.{0.05}));

}

(aha, there is a better way!)

Given the original error from 5401 (error: else prong required when switching on type '(enum literal)'), I think this behavior is already tested (bufPrint works at comptime) and no new tests are needed.

I would say the issue should just be closed, but I didn't look at the old compiler code so I don't understand how OP's test is related to the issue title ("peer type resolution of anonymous literals at comptime") and Vexu's comment. Based on Vexu's comment that seems like a bit of a footgun, but that behavior can't be "fixed"/tested since that sort of lazy analysis is fundamental to zig and its cross-compiling strategy. IMO the programmer should:

vara:S=if(cond).{.a=1}else.{.a=2};// <- write thisvara=if(cond)S{.a=1}else.{.a=2};// <- not this

and if they write the footgun version, the error is somewhat clear: (it says struct '5401.foo__anon_42777__struct_42793' , not struct '5401.S'

error: no field named 'b' in struct '5401.foo__anon_42777__struct_42793'
 std.debug.print(".a = {}, .b = {}\n", .{ a.a, a.b });
 ^

So basically I agree with Vexu's 4th alternative, "document this limitation and add a error note about it being an anonymous literal", and I think it makes sense to just close the issue.

I agree, "cannot format slice without a specifier" looks correct to me for that old code. Here's my modern repro (zig 0.16.0) ```zig test { comptime var buf = [_]u8{0} ** 16; const str = comptime try std.fmt.bufPrint(&buf, "{s} {s}", .{ "test", "123" }); const str2: [str.len]u8 = str[0..].*; // avoid "error: runtime value contains reference to comptime var" try std.testing.expectEqualStrings("test 123", &str2); } const std = @import("std"); ``` That "avoid error" line is pretty gnarly (maybe there's a better way?) but this should now be correctly testing the old bug, as far as I understand it. --- edit: I dug around and found these tests: https://codeberg.org/ziglang/zig/src/commit/b86841244421da7001a070e9515e57223f695674/lib/std/fmt.zig#L648-L666 (aha, there is a better way!) Given the original error from 5401 (`error: else prong required when switching on type '(enum literal)'`), I think this behavior is already tested (bufPrint works at comptime) and no new tests are needed. --- I would say the issue should just be closed, but I didn't look at the old compiler code so I don't understand how OP's test is related to the issue title ("peer type resolution of anonymous literals at comptime") and Vexu's [comment](https://github.com/ziglang/zig/issues/5401#issuecomment-632812743). Based on Vexu's comment that seems like a bit of a footgun, but that behavior can't be "fixed"/tested since that sort of lazy analysis is fundamental to zig and its cross-compiling strategy. IMO the programmer should: ```zig var a: S = if (cond) .{ .a = 1 } else .{ .a = 2 }; // <- write this var a = if (cond) S{ .a = 1 } else .{ .a = 2 }; // <- not this ``` and if they write the footgun version, the error is somewhat clear: (it says `struct '5401.foo__anon_42777__struct_42793' `, not `struct '5401.S'` ``` error: no field named 'b' in struct '5401.foo__anon_42777__struct_42793' std.debug.print(".a = {}, .b = {}\n", .{ a.a, a.b }); ^ ``` So basically I agree with Vexu's 4th alternative, "document this limitation and add a error note about it being an anonymous literal", and I think it makes sense to just close the issue.

No Branch/Tag specified

Branches Tags

master

elfv2

spork8

restricted

0.16.x

panic-rewrite

parking-futex-lockfree

windows-Io-cleanup

Io-watch

ParseCommandLineOptions

windows-async-files

poll-ring

debug-file-leaks-differently

debug-file-leaks

ProcessPrng

elfv2-dyn

jobserver

threadtheft

io-threaded-no-queue

0.15.x

Io.net

comptime-allocator

restricted-function-pointers

cli

wasm-linker-writer

wrangle-writer-buffering

sha1-stream

async-await-demo

fixes

0.14.x

ast-node-methods

macos-debug-info

make-vs-configure

fuzz-macos

sans-aro

ArrayList-reserve

incr-bug

llvm-ir-nosanitize-metadata

ci-tarballs

ci-scripts

threadpool

0.12.x

new-pkg-hash

json-diagnostics

more-doctests

rework-comptime-mutation

0.11.x

ci-perf-comment

stage2-async

0.10.x

autofix

0.9.x

aro

hcs

0.8.x

0.7.x

Labels

Clear labels

This proposal is planned.

The web application for interactive documentation and generation of its assets.

backend/c

The C backend outputs C source code.

backend/llvm

The LLVM backend outputs an LLVM bitcode module.

backend/self-hosted

The self-hosted backends produce machine code directly.

binutils

Zig's included binary utilities: zig ar, zig dlltool, zig lib, zig ranlib, zig objcopy, and zig rc.

breaking

Implementing this issue could cause existing code to no longer compile or have different behavior.

build system

The Zig build system - zig build, std.Build, the build runner, and package management.

debug info

docs

An issue with documentation, e.g. the language reference or standard library doc comments.

error message

This issue points out an error message that is unhelpful and should be improved.

frontend

Tokenization, parsing, AstGen, ZonGen, Sema, Legalize, and Liveness.

fuzzing

incremental

Reuse of internal compiler state for faster compilation.

lib/c

This issue relates to Zig's libc implementation and/or vendored libcs.

lib/compiler-rt

This issue relates to Zig's compiler-rt library.

lib/cxx

This issue relates to Zig's vendored libc++ and/or libc++abi.

lib/std

This issue relates to Zig's standard library.

lib/tsan

This issue relates to Zig's vendored libtsan.

lib/ubsan-rt

This issue relates to Zig's ubsan-rt library.

lib/unwind

This issue relates to Zig's vendored libunwind.

linking

Zig's integrated object file and incremental linker.

miscompilation

The compiler reports success but produces semantically incorrect code.

This issue suggests language modifications. If it also has the "accepted" label then it is planned.

release notes

This issue or pull request should be mentioned in the release notes.

testing

This issue is related to testing the compiler, standard library, or other parts of Zig.

zig cc

Zig as a drop-in C-family compiler.

zig fmt

The Zig source code formatter.

zig reduce

The Zig source code reduction tool.

bounty

https://ziglang.org/news/announcing-donor-bounties

bug

Observed behavior contradicts documented or intended behavior.

contributor-friendly

This issue is limited in scope and/or knowledge of project internals.

downstream

An issue with a third-party project that uses this project.

enhancement

Solving this issue will likely involve adding new logic or components to the codebase.

infra

optimization

A task to improve performance and/or resource usage.

question

No questions on the issue tracker; use a community space instead.

regression

Something that used to work in a previous version stopped working

upstream

An issue with a third-party project that this project uses.

use case

Describes a real use case that is difficult or impossible, but does not propose a solution.

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

ziglang/zig#35435

No description provided.

Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?

Legacy issue regarding comptime std.fmt.bufPrint (#5401) #35435

Legacy issue regarding comptime `std.fmt.bufPrint` (#5401) #35435