Rohlem
Rohlem
EDIT2: Looks like I commented without doing proper research/testing _again_. Sorry for the noise. (After further testing, it appears that comptime-caching with `@fieldParentPtr` already does what I proposed before this...
(Drive-by speculation from an LLVM noob.) The test (if I found the right one) [calls](https://github.com/ziglang/zig/blob/fb81522e0ba97294a475df040ccfea493342498d/test/standalone/stack_iterator/shared_lib_unwind.zig#L45) `extern fn frame0`, provided [here](https://github.com/ziglang/zig/blob/fb81522e0ba97294a475df040ccfea493342498d/test/standalone/stack_iterator/shared_lib.c), which writes `expected[4] = __builtin_extract_return_addr(__builtin_return_address(0));`, yet when we unwind [here](https://github.com/ziglang/zig/blob/fb81522e0ba97294a475df040ccfea493342498d/test/standalone/stack_iterator/shared_lib_unwind.zig#L45)...
looks similar to #18900 to me
@RossComputerGuy Right, and as far as I can see both cases trigger the `@compileError` at `std/fmt.zig:470`, `"invalid format string 's' for type ''"`. I wanted to link the issues together...
@raddari Thanks for this - I based https://github.com/david-vanderson/dvui/pull/173 on it, which has now been merged, so I think this PR can be closed too. I just realized my rebase accidentally...
@BratishkaErik with the risk of restating something obvious, I believe the code structure of the `usingnamespace` example in your comment can be completely preserved by simply explicitly listing all the...
For reference/discussion I'll repeat my point from https://github.com/ziglang/zig/pull/21501#issuecomment-2387999763 here, i.e. I think we can provide stricter parsing that errors in situations that might be unintentional. (If we value compatibility by...
In status-quo, `comptime_float` is "guaranteed to have the same precision and operations of \[`f128`\]." I think with this proposal, a `comptime_real` type would make sense: Afaik status-quo float literals are...
> it is important that expressions that involve `comptime_float`/floating-point literals have very strict, predictable and well-defined semantics. Just wanted to clarify that my suggestion above was to make float literals...
I'm surprised to see this relabeled from documentation issue to implementation bug, so I'll write down my perspective/interpretation to maybe start the discussion of what the desired resolution should be....