Change how u8 slices/array are formatted with {} #6870

LemonBoy · 2020-10-29T21:26:39Z

This PR spiraled out of control and became a monster that removes the special-casing of []u8/[N]u8/*[N]u8 as strings.

Now {} defaults to printing the array or slice elements as numbers, If you want a string you need {s}.

lib/std/fmt.zig

LemonBoy · 2020-10-30T17:24:08Z

lib/std/fmt.zig

-                if (fmt.len > 0 and ((fmt[0] == 'x') or (fmt[0] == 'X'))) {
-                    return formatText(value, fmt, options, writer);
+                if (max_depth == 0) {
+                    return writer.writeAll("[ ... ]");
                }
                if (ptr_info.child == u8) {


Makes sense as a default, I'll apply it locally to check for regressions

Wait, then formatText cannot handle x nor e...

if (ptr_info.child == u8 and fmt.len == 0 or (fmt.len > 0 and (fmt[0] == 'x' or fmt[0] == 'X')))
?

data-man · 2020-10-30T17:32:28Z

Pretty formatting for arrays:

        },
        .Array => |info| {
            if (max_depth == 0) {
                return writer.writeAll("{ ... }");
            }
            if (info.child == u8) {
                return formatText(value[0..], fmt, options, writer);
            }
            try writer.writeAll("{ ");
            for (value) |elem, i| {
                try formatType(elem, fmt, options, writer, max_depth - 1);
                if (i < value.len - 1) {
                    try writer.writeAll(", ");
                }
            }
            try writer.writeAll(" }");
        },

LemonBoy · 2020-10-30T17:34:09Z

Pretty formatting for arrays:

Open a PR against this branch on my repo, it should appear here.

LemonBoy · 2020-10-31T14:19:05Z

We should really sort this mess with all the formatting specifiers & their defaults :(

data-man · 2020-11-01T11:24:54Z

Why so few thumbs up? 😄

data-man · 2020-11-06T13:56:39Z

Dear maintainers, is there a chance this PR will be included in the upcoming release?

jedisct1 · 2020-11-06T16:09:15Z

+1. That would be very useful.

LemonBoy · 2020-11-06T17:07:49Z

The FreeBSD CI is acting up again, cool.

Dear maintainers, is there a chance this PR will be included in the upcoming release?

The different handling of u8 arrays/slices is still up for discussion, let's take our time to discuss about every detail before slamming the merge button.

Vexu · 2020-11-19T13:35:32Z

lib/std/fmt.zig

            },
            .Many, .C => {
                if (ptr_info.sentinel) |sentinel| {
                    return formatType(mem.span(value), fmt, options, writer, max_depth);
                }
                if (ptr_info.child == u8) {
-                    if (fmt.len > 0 and fmt[0] == 's') {
+                    if (fmt.len > 0 and comptime mem.indexOfScalar(u8, "sxXzZ", fmt[0]) != null) {


formatText also takes eE, though that should probably be merged with Z which does the same but using Zig escape sequences.

Vexu · 2020-11-19T13:38:41Z

lib/std/fmt.zig

+    {
+        var int_slice = [_]u32{ 1, 4096, 391891, 1111111111 };
+        var runtime_zero: usize = 0;
+        try testFmt("int: [1, 4096, 391891, 1111111111]", "int: {}", .{int_slice[runtime_zero..]});


Is there a reason why slices don't use curly braces like arrays?

Yeah, style-wise there are a few questions. Do we want a space after the opening/closing brace? Do we want curly or square brackets? Same symbol for both arrays and slices?

If we want to make generating Zig with the formatting system easier we should definitely use curly braces for both. For the spaces I'd either follow zig fmt or just leave it as is to keep things simple.

LemonBoy · 2020-11-24T11:22:50Z

If we're in for a bold breaking (and perhaps controversial) change we could:

Make the default ({}) specifier for arrays print the content as if their elements were numbers
Strings require an explicit {s} (or {z/Z}) as there's no separate string type

This way we can get rid of the special-case handling of []u8/[N]u8 as strings and streamline a bit the formatting rules.

MasterQ32 · 2020-11-24T13:20:03Z

Yes, please. We need at least three options then:

{} print as array
{s} print as raw string
{q} print as quoted string ("\xF3" will yield "\xF3" instead of the raw byte output)

andrewrk · 2020-11-25T23:42:04Z

If we're in for a bold breaking (and perhaps controversial) change we could:

I support this. I think {} in format strings is already a footgun because it can be a runtime bug if you expected that your parameter was a string-like object but instead it is a struct or something and ends up printing a struct representation of it.

LemonBoy · 2020-11-26T09:10:35Z

Yes, please. We need at least three options then:

Right now the supported specifiers are:

{} to print the value as an array,
{s} to print the value as a string
{z}/{Z} to print the value as a valid Zig identifier
{x}/{X} to print the content in hexadecimal form (eg. [0x12, 0x34] -> "1234")
- This conflicts with xX for the array values, should find a new name for this.
- Do we need it? Does it deserve its own specifier? Can we spin it into its own hexdump-like function if it's really needed?
{e}/{E} to print the content as an ASCII string, the non-printable characters are escaped (\xXX)
- Limited to ASCII strings :(
- People never find it! Maybe because it uses the same specifier used for printing floating point numbers...
- Is this what people want from a {q} (for quote) specifier?

The last two specifiers should be rehomed/renamed to complete the plan.

MasterQ32 · 2020-11-26T09:18:47Z

Do we need it? Does it deserve its own specifier? Can we spin it into its own hexdump-like function if it's really needed?

Yes, very. I use it often to verify that binary data actually looks like it should and i also use it for several hexdump style outputs

Is this what people want from a {q} (for quote) specifier?

We could introduce {q} for general string quoting (everything non-valid utf-8 is quoted) and use {a} for ASCII quoted strings

LemonBoy · 2020-11-26T09:40:55Z

Yes, very. I use it often to verify that binary data actually looks like it should and i also use it for several hexdump style outputs

Fair enough, where do we put it? {sx} maybe?

We could introduce {q} for general string quoting (everything non-valid utf-8 is quoted) and use {a} for ASCII quoted strings

Invalid UTF-8 should be replaced with U+FFFD according to the sacred texts, what I had in mind was to traverse the string in terms of utf8 runes and apply the usual ascii.isprint predicate on them. It won't escape unprintable non-ASCII codepoints but that's IMO better than splitting the specifier in two.
I do agree that {q} is a better name than {e}.

Vexu · 2020-11-26T17:21:52Z

src/Compilation.zig

+        \\pub const output_mode = OutputMode.{s};
+        \\pub const link_mode = LinkMode.{s};


All the {s} in generateBuiltinZigSource should be {z}.

LemonBoy · 2020-12-08T17:00:08Z

This is probably caused by the Windows CI going OOM. It basically happends when the the compiler is compiling all the tests for test-std. Everything ends up in a single compile unit and the CI does not have enough memory to compile all this. We have had this problem before and I think it happend at the exact same place.

The question is, does this PR increase the RAM consumption? If so, how?

FireFox317 · 2020-12-09T08:54:11Z

The question is, does this PR increase the RAM consumption? If so, how?

Good question, I have no idea, but apparently it does.

andrewrk · 2021-01-01T21:58:28Z

I love this and want it, let's coordinate on how to land this since it is destined to conflict with everything

the amount of RAM we get on Windows CI runs is not consistent. so it doesn't necessarily mean this PR causes more ram consumption.

This code is adapted from pixelherodev paste from IRC I have added a new fmt option to handle printing slice values ``{v}`` or ``{V}`` While i think it can be made the default, i want your opinion about it ```zig var slicea = [0]u32{}; var sliceb = [3]u32{ 1, 2, 3 }; std.log.info("Content: {v}", .{slicea}); std.log.info("Content: {v}", .{sliceb}); ``` will print: ``` info: Content: [] info: Content: [1, 2, 3] ``` Question: Should we drop ``{v}`` and make it the default behavior?

Also fix the `*` specifier for more types, print an error message if we can't show the value address.

Unless {s} is specified the contents won't be treated as a string.

LemonBoy · 2021-01-02T11:44:00Z

I love this and want it, let's coordinate on how to land this since it is destined to conflict with everything

I've rebased the whole patch series, I don't expect many conflicts with other PRs as the changes are pretty much self-contained.

the amount of RAM we get on Windows CI runs is not consistent. so it doesn't necessarily mean this PR causes more ram consumption.

shrug, then I wonder why we always hit the OOM condition with this PR...
We have the same problem in masterand #7331.

Leftovers after a long rebase.

commit 3e8aaee Author: Andrew Kelley <andrew@ziglang.org> Date: Mon Jan 4 22:25:04 2021 -0700 std: skip more tests on Windows to save CI memory I've enabled only the tests that check things specific to Windows that are not tested by other systems. commit 16896a9 Author: Andrew Kelley <andrew@ziglang.org> Date: Mon Jan 4 15:57:54 2021 -0700 ci: skip crypto tests on windows Trying to buy us more time on the Windows CI. commit 66e5e92 Merge: d957244 2561168 Author: Andrew Kelley <andrew@ziglang.org> Date: Mon Jan 4 14:23:01 2021 -0800 Merge pull request ziglang#7592 from LemonBoy/fix-7188 Allow variable captures on multi-prong switch arms commit d957244 Author: Evan Haas <evan@lagerdata.com> Date: Fri Jan 1 23:13:15 2021 -0800 Allow dollar sign $ in identifiers in translate-c In strictly conforming C, identifiers cannot container dollar signs. However GCC and Clang allow them by default, so translate-c should handle them. See http://gcc.gnu.org/onlinedocs/cpp/Tokenization.html I encountered this in the wild in windows.h Fixes ziglang#7585 commit 819f2a0 Author: Felix (xq) Queißner <git@mq32.de> Date: Mon Jan 4 12:20:43 2021 +0100 Fixes missing error prong in std.os.send. commit fc3508b Author: J.C. Moyer <jcmoyer32@gmail.com> Date: Mon Jan 4 09:15:39 2021 -0500 Fix off-by-one error in SinglyLinkedList.len() and add associated tests commit a93c123 Author: xackus <14938807+xackus@users.noreply.github.com> Date: Mon Jan 4 17:41:24 2021 +0100 std.c: add some noalias commit 2fe8a48 Author: Andrew Kelley <andrew@ziglang.org> Date: Mon Jan 4 14:59:18 2021 -0700 ci: omit stage2 backend from stage1 on Windows to avoid out-of-memory on the CI runs. commit 462c1d8 Author: Andrew Kelley <andrew@ziglang.org> Date: Mon Jan 4 14:33:32 2021 -0700 stage2: add more perf tracing points commit fc38b42 Author: Andrew Kelley <andrew@ziglang.org> Date: Mon Jan 4 13:49:17 2021 -0700 Revert "Fix ziglang#7296:" This broke build scripts that wanted to refer to `exe_dir` or `install_path`. There has also been some pushback and discussion on this breaking change. I think it should be re-evaluated. This reverts commit a1a1929. commit ef2fa67 Merge: aa0906e 7e64dc4 Author: Andrew Kelley <andrew@ziglang.org> Date: Mon Jan 4 13:40:51 2021 -0700 Merge branch 'g-w1-stage2-evalbranch' closes ziglang#7682 commit 7e64dc4 Author: Andrew Kelley <andrew@ziglang.org> Date: Mon Jan 4 13:40:01 2021 -0700 stage2: improvements to `@setEvalBranchQuota` * extract magic number into a constant * properly use result location casting for the operand * naming convention for ZIR instructions commit 638f93e Author: g-w1 <jacoblevgw@gmail.com> Date: Sun Jan 3 15:45:22 2021 -0500 stage2: implementation of `@setEvalBranchQuota`: `@setEvalBranchQuota` can be called before the comptime/inline call stack is created. For example: ```zig @setEvalBranchQuota(100); comptime { while (true) {} } ``` Here we need to set the branch_quota before the comptime block creates a scope for the branch_count. commit aa0906e Author: joachimschmidt557 <joachim.schmidt557@outlook.com> Date: Sat Jan 2 18:53:11 2021 +0100 stage2 x86_64: fix bug in Function.gen Previously, the x86_64 backend would remove code for exitlude relocs if the jump amount were 0. This causes issues as earlier jumps rely on the jump being present at the same address. commit 4400d2d Author: Frank Denis <github@pureftpd.org> Date: Sun Jan 3 09:10:59 2021 +0100 std/crypto: add BLAKE2-160 types and tests commit e4c4a0a Author: daurnimator <quae@daurnimator.com> Date: Mon Jan 4 01:27:35 2021 +1100 Improve uring definitions commit 53a0b79 Merge: c8e44d8 807dc56 Author: Andrew Kelley <andrew@ziglang.org> Date: Sun Jan 3 19:51:38 2021 -0800 Merge pull request ziglang#7681 from kubkon/stage2-aarch64-fn-args stage2: basic fn args for aarch64 commit c8e44d8 Author: Andrew Kelley <andrew@ziglang.org> Date: Sun Jan 3 20:34:17 2021 -0700 stage2: remove the Cache deadlock detection code It's more trouble than it's worth; it didn't even catch the most recent incident because it was across process boundaries anyway. commit 404dc96 Author: Andrew Kelley <andrew@ziglang.org> Date: Sun Jan 3 20:25:04 2021 -0700 stage2: fix Cache debug deadlock code memory leak commit 5c92e24 Author: Andrew Kelley <andrew@ziglang.org> Date: Sun Jan 3 20:10:07 2021 -0700 drone ci: skip compile error tests to save time These are covered by other CI scripts and we're up against Drone CI time limits. commit f664425 Merge: 5cc1310 0151f3b Author: Andrew Kelley <andrew@ziglang.org> Date: Sun Jan 3 16:09:14 2021 -0800 Merge pull request ziglang#7598 from FireFox317/more-llvm-stage2 stage2: More improvements to self-hosted LLVM backend commit 5cc1310 Author: Evan Haas <evan@lagerdata.com> Date: Tue Dec 29 11:07:04 2020 -0800 Static function declarations with no prototype should not be variadic If a static function is defined with no argument list and no prototype is given, it should be treated as a function that takes no arguments rather than as a variadic function. Fixes ziglang#7594 commit 807dc56 Author: Jakub Konka <kubkon@jakubkonka.com> Date: Sun Jan 3 23:20:09 2021 +0100 stage2: add aarch64 stage2 tests Fix missing string format specifier in Mach-O used to generate path to debug symbols bundle. commit 2a410ba Author: Jakub Konka <kubkon@jakubkonka.com> Date: Sun Jan 3 23:01:22 2021 +0100 stage2: implement basic function params aarch64 Implement missing `.register` prong for `aarch64` `genSetReg`. commit 0151f3b Author: Timon Kruiper <timonkruiper@gmail.com> Date: Sun Jan 3 17:10:28 2021 +0100 stage2: Add support for testing LLVM enabled builds in test-stage2 To make sure that we don't have to rebuild libc for every case, we now have a seperate cache directory for the global cache, which remains the same between test runs. Also make sure to destory the Compilation before executing a child process, otherwise the compiler deadlocks. (ziglang#7596) commit a926c91 Author: Timon Kruiper <timonkruiper@gmail.com> Date: Sun Jan 3 16:48:52 2021 +0100 stage2: enable building test-stage2 with LLVM backend enabled We can now run `zig build test-stage2 -Denable-llvm`. commit 7e5aaca Author: Timon Kruiper <timonkruiper@gmail.com> Date: Sun Jan 3 16:44:53 2021 +0100 stage2: add some missing deallocations in Compilation.zig commit 3c05c60 Author: Timon Kruiper <timonkruiper@gmail.com> Date: Sun Jan 3 16:09:32 2021 +0100 stage2: Output the LLVM object files in the cache directory Also make sure to properly free everything. commit 0008bef Author: Timon Kruiper <timonkruiper@gmail.com> Date: Sun Jan 3 16:00:12 2021 +0100 stage2: add support for integers in LLVM backend Also adds support for simple operators, like add and subtract. The intcast and bitcast instruction also have been implemented. Linking with libc also works, so we can now generate working executables! `zig build-exe example.zig -fLLVM -lc`: ``` fn add(a: i32, b: i32) i32 { return a + b; } export fn main() c_int { var a: i32 = -5; const x = add(a, 7); var y = add(2, 0); y -= x; return y; } ``` commit e095ebf Author: Timon Kruiper <timonkruiper@gmail.com> Date: Tue Dec 29 22:47:52 2020 +0100 stage2: make use of proper LLVM intrinsic APIs in LLVM backend commit da545d6 Author: Timon Kruiper <timonkruiper@gmail.com> Date: Tue Dec 29 20:39:58 2020 +0100 stage2: implement argument passing and returning in LLVM backend Furthermore add the Not instruction. The following now works: ``` export fn _start() noreturn { var x: bool = true; var other: bool = foo(x); exit(); } fn foo(cond: bool) bool { return !cond; } fn exit() noreturn { unreachable; } ``` commit 47a4d43 Author: Timon Kruiper <timonkruiper@gmail.com> Date: Tue Dec 29 20:18:17 2020 +0100 stage2: Add code generation for Load instruction in LLVM backend The following now works: ``` export fn _start() noreturn { var x: bool = true; var y: bool = x; exit(); } fn exit() noreturn { unreachable; } ``` commit 19cfd31 Author: Timon Kruiper <timonkruiper@gmail.com> Date: Tue Dec 29 20:09:08 2020 +0100 stage2: implement register allocation in LLVM self-hosted backend A HashMap has been added which store the LLVM values used in a function. Together with the alloc and store instructions the following now works: ``` export fn _start() noreturn { var x: bool = true; exit(); } fn exit() noreturn { unreachable; } ``` commit a5dab15 Author: Timon Kruiper <timonkruiper@gmail.com> Date: Tue Dec 29 19:03:04 2020 +0100 stage2: clear `err_msg` after it has been added to `module.failed_decls` commit 0ed04aa Author: Timon Kruiper <timonkruiper@gmail.com> Date: Tue Dec 29 18:52:53 2020 +0100 stage2: fix building self-hosted compiler with -Dstatic-llvm This supersedes c81ae52 commit 5aac2fc Author: Frank Denis <github@pureftpd.org> Date: Sat Jan 2 20:08:27 2021 +0100 std/crypto: properly support arbitrary output sizes Fixes ziglang#7657 commit 6838141 Merge: d8f3f14 33e53d7 Author: Andrew Kelley <andrew@ziglang.org> Date: Sat Jan 2 22:05:31 2021 -0800 Merge pull request ziglang#7612 from g-w1/do-7296 Implement ziglang#7296 commit d8f3f14 Merge: 3d151fb 6548322 Author: Andrew Kelley <andrew@ziglang.org> Date: Sat Jan 2 22:01:51 2021 -0800 Merge pull request ziglang#7647 from ziglang/stage2-comptime-fn-call stage2: comptime function calls and inline function calls commit 6548322 Author: Andrew Kelley <andrew@ziglang.org> Date: Sat Jan 2 22:42:07 2021 -0700 stage2: support recursive inline/comptime functions zir.Inst no longer has an `analyzed_inst` field. This is previously how we mapped ZIR to their TZIR counterparts, however with the way inline and comptime function calls work, we can potentially have the same ZIR structure being analyzed by multiple different analyses, such as during a recursive inline function call. This would cause the `analyzed_inst` field to become clobbered. So instead, we use a table to map the instructions to their semantically analyzed counterparts. This will help with multi-threaded compilation as well. Scope.Block.Inlining is split into 2 different layers of "sharedness". The first layer is shared by the whole inline/comptime function call stack. It contains the callsite where something is being inlined and the branch count/quota. The second layer is different per function call but shared by all the blocks within the function being inlined. Add support for debug dumping br and brvoid TZIR instructions. Remove the "unreachable code" error. It was happening even for this case: ```zig if (comptime_condition) return; bar(); // error: unreachable code ``` We will need smarter logic for when it is legal to emit this compile error. Remove the ZIR test cases. These are redundant with other higher level Zig source tests we have, and maintaining support for ZIRModule as a first-class top level abstraction is getting in the way of clean compiler design for the main use case. We will have ZIR/TZIR based test cases someday to help with testing optimization passes and ZIR to TZIR analysis, but as is, these test cases are not accomplishing that, and they are getting in the way. commit 3d151fb Author: g-w1 <jacoblevgw@gmail.com> Date: Sat Jan 2 23:11:34 2021 -0500 fix 7665: only add self exe path when testing commit 50a5301 Author: Andrew Kelley <andrew@ziglang.org> Date: Sat Jan 2 14:28:03 2021 -0700 stage2: fix handling compile error in inline fn call * scopes properly inherit inlining information * compile errors of inline function calls are properly attached to the caller rather than the callee. - added a test case for this * --watch still opens a repl if compile errors happen. commit 006e7f6 Author: Andrew Kelley <andrew@ziglang.org> Date: Sat Jan 2 13:40:23 2021 -0700 stage2: re-use ZIR for comptime and inline calls Instead of freeing ZIR after semantic analysis, we keep it around so that it can be used for comptime calls, inline calls, and generic function calls. ZIR memory is now managed by the Decl arena. Debug dump() functions are conditionally compiled; only available in Debug builds of the compiler. Add a test for an inline function call. commit 9362f38 Author: Andrew Kelley <andrew@ziglang.org> Date: Sat Jan 2 12:32:30 2021 -0700 stage2: implement function call inlining in the frontend * remove the -Ddump-zir thing. that's handled through --verbose-ir * rework Fn to have an is_inline flag without requiring any more memory on the heap per function. * implement a rough first version of dumping typed zir (tzir) which is a lot more helpful for debugging than what we had before. We don't have a way to parse it though. * keep track of whether the inline-ness of a function changes because if it does we have to go update callsites. * add compile error for inline and export used together. inline function calls and comptime function calls are implemented the same way. A block instruction is set up to capture the result, and then a scope is set up that has a flag for is_comptime and some state if the scope is being inlined. when analyzing `ret` instructions, zig looks for inlining state in the scope, and if found, treats `ret` as a `break` instruction instead, with the target block being the one set up at the inline callsite. Follow-up items: * Complete out the debug TZIR dumping code. * Don't redundantly generate ZIR for each inline/comptime function call. Instead we should add a new state enum tag to Fn. * comptime and inlining branch quotas. * Add more test cases. commit fea8659 Author: Andrew Kelley <andrew@ziglang.org> Date: Fri Jan 1 19:24:02 2021 -0700 stage2: comptime function calls * Function calls that happen in a comptime scope get called at compile-time. We do this by putting the parameters in place as constant values and then running regular function analysis on the body. * Added `Scope.Block.dump()` for debugging purposes. * Fixed some code to call `identifierTokenString` rather than `tokenSlice`, making it work for `@""` syntax. * Implemented `Value.copy` for big integers. Follow-up issues to tackle: * Adding compile errors to the callsite instead of the callee Decl. * Proper error notes for "called from here". - Related: ziglang#7555 * Branch quotas. * ZIR support? commit fb37c1b Merge: db1e97d 974c008 Author: Andrew Kelley <andrew@ziglang.org> Date: Sat Jan 2 19:03:37 2021 -0700 Merge branch 'LemonBoy-revive-6680' closes ziglang#6870 commit 974c008 Author: Andrew Kelley <andrew@ziglang.org> Date: Sat Jan 2 19:03:14 2021 -0700 convert more {} to {d} and {s} commit 5b981b1 Author: LemonBoy <thatlemon@gmail.com> Date: Sat Jan 2 12:29:37 2021 +0100 Remove some unwanted changes Leftovers after a long rebase. commit 608a73e Author: LemonBoy <thatlemon@gmail.com> Date: Wed Dec 2 20:02:51 2020 +0100 Decrement max_depth when printing slice elements commit 04f37dc Author: LemonBoy <thatlemon@gmail.com> Date: Thu Nov 26 22:20:44 2020 +0100 stage2: Use {z} instead of {s} in generated Zig code commit 1fbe89d Author: LemonBoy <thatlemon@gmail.com> Date: Thu Nov 26 19:14:22 2020 +0100 langref: Update langref to use {s} commit d2f6fa1 Author: LemonBoy <thatlemon@gmail.com> Date: Thu Nov 26 17:06:52 2020 +0100 Fix more stray uses of {} for formatting strings commit 1ca2dec Author: LemonBoy <thatlemon@gmail.com> Date: Thu Nov 26 15:43:28 2020 +0100 std: Disable the special casing of {} for u8 slices/arrays Unless {s} is specified the contents won't be treated as a string. commit 4420afe Author: LemonBoy <thatlemon@gmail.com> Date: Thu Nov 26 13:28:38 2020 +0100 tests: Use {s} instead of {} when formatting strings commit 1c13ca5 Author: LemonBoy <thatlemon@gmail.com> Date: Thu Nov 26 13:19:30 2020 +0100 stage2: Use {s} instead of {} when formatting strings commit dd973fb Author: LemonBoy <thatlemon@gmail.com> Date: Thu Nov 26 09:48:12 2020 +0100 std: Use {s} instead of {} when printing strings commit 5a06fdf Author: LemonBoy <thatlemon@gmail.com> Date: Thu Nov 19 19:02:30 2020 +0100 Use same brace pairs for arrays/slices/vectors commit d4a8fc8 Author: LemonBoy <thatlemon@gmail.com> Date: Sat Oct 31 15:16:59 2020 +0100 Small cleanup commit 2b5e93f Author: data-man <datamanrb@gmail.com> Date: Sat Oct 31 15:12:05 2020 +0100 Add formatting for arrays commit 6f53653 Author: LemonBoy <thatlemon@gmail.com> Date: Thu Oct 29 22:22:25 2020 +0100 std: Refactor the slice formatting code Also fix the `*` specifier for more types, print an error message if we can't show the value address. commit 5275280 Author: ryuukk <44361234+ryuukk@users.noreply.github.com> Date: Wed Oct 14 18:45:46 2020 +0200 Formatting fix commit 1d97747 Author: ryuukk <44361234+ryuukk@users.noreply.github.com> Date: Wed Oct 14 18:38:59 2020 +0200 Pretty print Slices This code is adapted from pixelherodev paste from IRC I have added a new fmt option to handle printing slice values ``{v}`` or ``{V}`` While i think it can be made the default, i want your opinion about it ```zig var slicea = [0]u32{}; var sliceb = [3]u32{ 1, 2, 3 }; std.log.info("Content: {v}", .{slicea}); std.log.info("Content: {v}", .{sliceb}); ``` will print: ``` info: Content: [] info: Content: [1, 2, 3] ``` Question: Should we drop ``{v}`` and make it the default behavior? commit db1e97d Author: Cameron Conn <camconn@users.noreply.github.com> Date: Sat Jan 2 18:06:51 2021 -0600 Improve documentation for ArrayList, ArrayListUnmanaged, etc. (ziglang#7624) * Improve ArrayList & co documentation - Added doc comments about the validity of references to elements in an ArrayList and how they may become invalid after resizing operations. - This should help users avoid footguns in future. * Improve ArrayListUnmanaged & co's documentation - Port improved documentation from ArrayList and ArrayList aligned to their unmanaged counterparts. - Made documentation for ArrayListUnmanaged & co more inclusive and up-to-date. - Made documentation more consistent with `ArrayList`. * Corrections on ArrayList documentation. - Remove incorrect/unpreferred wording on ArrayList vs ArrayListUnmanaged. - Fix notes about the alignment of ArrayListAligned - Be more verbose with warnings on when pointers are invalidated. - Copy+paste a few warnings * add warning to replaceRange * revert changes to append documentation commit 1856dfe Author: LemonBoy <LemonBoy@users.noreply.github.com> Date: Fri Jan 1 19:33:53 2021 +0100 stage1: Use correct format specifier for size_t parameters Use `Iu` on Windows, the integer width depends on the target being a 32bit or a 64bit one. commit af8eab5 Author: Sizhe Zhao <prc.zhao@outlook.com> Date: Sat Jan 2 22:50:49 2021 +0800 Fix usage message commit 44c9bf5 Author: Andrew Kelley <andrew@ziglang.org> Date: Sat Jan 2 12:21:19 2021 -0700 std: disable a couple tests on windows They are passing but we're hitting OOM on the Windows CI server. This is to buy us more time until stage2 rescues us from the CI memory crisis. commit 5a65796 Merge: a9c75a2 763d807 Author: Jakub Konka <kubkon@jakubkonka.com> Date: Sat Jan 2 20:08:37 2021 +0100 Merge pull request ziglang#7506 from kubkon/fix-6923 zig cc: detect framework include paths when native commit 763d807 Author: Jakub Konka <kubkon@jakubkonka.com> Date: Sun Dec 20 11:52:25 2020 +0100 Duplicate OSAtomic.h between aarch64 and x86_64 The reason this is required is for two reasons: 1) the libc targeting `aarch64` macOS is slightly newer than that targeting `x86_64`, and 2) `OSAtomic.h` uses relative imports rather than system-wide imports for accompanying headers which clearly is an oversight on Apple's part. Until such time when `libkern` headers between `x86_64` and `aarch64` are identical, this will require a manual intervention to duplicate the relevant headers between the respective architectures. commit 91a35e1 Author: Jakub Konka <kubkon@jakubkonka.com> Date: Sun Dec 20 11:45:48 2020 +0100 Detect native iframework dirs on macOS This commit adds default search paths for system frameworks on macOS while also adding `-isysroot` for OS versions at least BigSur. Since BigSur (11.0.1), neither headers nor libs exist in standard root locations (`/usr/include`, `/System/Library/Frameworks`). Instead, they are now exclusively part of the installed developer toolchain (either via XCode.app or CLT), and specifying `-isysroot` allows us to keep using universal search paths such as `/System/Library/Frameworks` while only changing the include flag from `-iframework` to `-iframeworkwithsysroot`. commit 33e53d7 Author: g-w1 <jacoblevgw@gmail.com> Date: Thu Dec 31 10:21:58 2020 -0500 update .gitignore to include /release/ and /debug/ commit a1a1929 Author: g-w1 <jacoblevgw@gmail.com> Date: Wed Dec 30 21:04:27 2020 -0500 Fix ziglang#7296: * makes '$build_root/{install,debug}/' the default prefix. This makes it not '$pwd/zig-cache/'. commit 2561168 Author: LemonBoy <thatlemon@gmail.com> Date: Tue Dec 29 13:00:01 2020 +0100 std: Clean up some tests No functional changes, remove some dead code. commit 88634f0 Author: LemonBoy <thatlemon@gmail.com> Date: Tue Dec 29 12:58:47 2020 +0100 stage1: Allow variable capture for multi-prong switch arms Handle the multi-prong case as we do with range cases. Closes ziglang#7188

data-man reviewed Oct 30, 2020

View reviewed changes

lib/std/fmt.zig Outdated Show resolved Hide resolved

data-man reviewed Oct 30, 2020

View reviewed changes

lib/std/fmt.zig Show resolved Hide resolved

data-man reviewed Oct 30, 2020

View reviewed changes

LemonBoy force-pushed the revive-6680 branch from bc605c0 to bd4dbab Compare October 31, 2020 14:17

LemonBoy force-pushed the revive-6680 branch from bd4dbab to 9d16c85 Compare October 31, 2020 15:19

alexnask closed this Nov 6, 2020

alexnask reopened this Nov 6, 2020

Vexu reviewed Nov 19, 2020

View reviewed changes

LemonBoy force-pushed the revive-6680 branch from 5a89e8d to bae332b Compare November 24, 2020 11:16

LemonBoy force-pushed the revive-6680 branch 2 times, most recently from 42c19c8 to da72233 Compare November 26, 2020 17:03

LemonBoy changed the title ~~Revive 6680~~ Change how u8 slices/array are formatted with {} Nov 26, 2020

Vexu reviewed Nov 26, 2020

View reviewed changes

LemonBoy force-pushed the revive-6680 branch 4 times, most recently from e01874a to 061b427 Compare November 27, 2020 17:59

Vexu added the standard library This issue involves writing Zig code for the standard library. label Dec 25, 2020

ryuukk and others added 14 commits January 2, 2021 10:48

Formatting fix

b5a9c7a

std: Refactor the slice formatting code

a6644f3

Also fix the `*` specifier for more types, print an error message if we can't show the value address.

Add formatting for arrays

001b025

Small cleanup

1d6514a

Use same brace pairs for arrays/slices/vectors

a1e4770

std: Use {s} instead of {} when printing strings

e26ab46

stage2: Use {s} instead of {} when formatting strings

50c1e27

tests: Use {s} instead of {} when formatting strings

7e51cae

std: Disable the special casing of {} for u8 slices/arrays

6ae835c

Unless {s} is specified the contents won't be treated as a string.

Fix more stray uses of {} for formatting strings

77910dd

langref: Update langref to use {s}

6d41eb1

stage2: Use {z} instead of {s} in generated Zig code

f7b3fe2

Decrement max_depth when printing slice elements

d296e59

LemonBoy force-pushed the revive-6680 branch from c374942 to 0996965 Compare January 2, 2021 11:35

Remove some unwanted changes

db468c0

Leftovers after a long rebase.

LemonBoy force-pushed the revive-6680 branch from 0996965 to db468c0 Compare January 2, 2021 12:00

andrewrk added the breaking Implementing this issue could cause existing code to no longer compile or have different behavior. label Jan 3, 2021

andrewrk closed this in fb37c1b Jan 3, 2021

marler8997 mentioned this pull request Jan 3, 2021

Assert compile error for unspecified array/slice format #7675

Closed

g-w1 mentioned this pull request Jan 6, 2021

comptime string with {} then formatted producing byte array not string #7703

Closed

mlarouche mentioned this pull request Jan 9, 2021

Proposal: Add String to the type system #7734

Closed

mikdusan added the release notes This PR should be mentioned in the release notes. label Jan 24, 2021

andrewrk added this to the 0.9.0 milestone Apr 18, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Change how u8 slices/array are formatted with {} #6870

Change how u8 slices/array are formatted with {} #6870

LemonBoy commented Oct 29, 2020 •

edited

This comment was marked as resolved.

LemonBoy Oct 30, 2020

LemonBoy Oct 30, 2020

data-man Oct 30, 2020

data-man commented Oct 30, 2020

LemonBoy commented Oct 30, 2020

LemonBoy commented Oct 31, 2020

data-man commented Nov 1, 2020

data-man commented Nov 6, 2020

jedisct1 commented Nov 6, 2020

LemonBoy commented Nov 6, 2020

Vexu Nov 19, 2020

Vexu Nov 19, 2020

LemonBoy Nov 19, 2020

Vexu Nov 19, 2020

LemonBoy commented Nov 24, 2020

MasterQ32 commented Nov 24, 2020

andrewrk commented Nov 25, 2020

LemonBoy commented Nov 26, 2020 •

edited

MasterQ32 commented Nov 26, 2020

LemonBoy commented Nov 26, 2020

Vexu Nov 26, 2020

LemonBoy commented Dec 8, 2020

FireFox317 commented Dec 9, 2020

andrewrk commented Jan 1, 2021 •

edited

LemonBoy commented Jan 2, 2021

		\\pub const output_mode = OutputMode.{s};
		\\pub const link_mode = LinkMode.{s};

Change how u8 slices/array are formatted with {} #6870

Change how u8 slices/array are formatted with {} #6870

Conversation

LemonBoy commented Oct 29, 2020 • edited

This comment was marked as resolved.

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

data-man commented Oct 30, 2020

LemonBoy commented Oct 30, 2020

LemonBoy commented Oct 31, 2020

data-man commented Nov 1, 2020

data-man commented Nov 6, 2020

jedisct1 commented Nov 6, 2020

LemonBoy commented Nov 6, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

LemonBoy commented Nov 24, 2020

MasterQ32 commented Nov 24, 2020

andrewrk commented Nov 25, 2020

LemonBoy commented Nov 26, 2020 • edited

MasterQ32 commented Nov 26, 2020

LemonBoy commented Nov 26, 2020

Choose a reason for hiding this comment

LemonBoy commented Dec 8, 2020

FireFox317 commented Dec 9, 2020

andrewrk commented Jan 1, 2021 • edited

LemonBoy commented Jan 2, 2021

LemonBoy commented Oct 29, 2020 •

edited

LemonBoy commented Nov 26, 2020 •

edited

andrewrk commented Jan 1, 2021 •

edited