Skip to content

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

Closed
LemonBoy wants to merge 15 commits into
ziglang:masterfrom
LemonBoy:revive-6680
Closed

Change how u8 slices/array are formatted with {}#6870
LemonBoy wants to merge 15 commits into
ziglang:masterfrom
LemonBoy:revive-6680

Conversation

@LemonBoy

@LemonBoyLemonBoy commented Oct 29, 2020

Copy link
Copy Markdown
Contributor

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}.

Comment threadlib/std/fmt.zig Outdated
Comment threadlib/std/fmt.zig
Comment threadlib/std/fmt.zig
if (max_depth == 0) {
return writer.writeAll("[ ... ]");
}
if (ptr_info.child == u8) {

This comment was marked as resolved.

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@data-man

Copy link
Copy Markdown
Contributor

Pretty formatting for arrays:

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

@LemonBoy

Copy link
Copy Markdown
ContributorAuthor

Pretty formatting for arrays:

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

@LemonBoy

Copy link
Copy Markdown
ContributorAuthor

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

@data-man

Copy link
Copy Markdown
Contributor

Why so few thumbs up? 😄

@data-man

Copy link
Copy Markdown
Contributor

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

@jedisct1

Copy link
Copy Markdown
Contributor

+1. That would be very useful.

@alexnaskalexnask closed this Nov 6, 2020
@alexnaskalexnask reopened this Nov 6, 2020
@LemonBoy

Copy link
Copy Markdown
ContributorAuthor

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.

Comment threadlib/std/fmt.zig Outdated
}
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) {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Comment threadlib/std/fmt.zig Outdated
{
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..]});

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
ContributorAuthor

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.

@ikskuh

Copy link
Copy Markdown
Contributor

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

Copy link
Copy Markdown
Member

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

LemonBoy commented Nov 26, 2020

Copy link
Copy Markdown
ContributorAuthor

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.

@ikskuh

Copy link
Copy Markdown
Contributor

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

Copy link
Copy Markdown
ContributorAuthor

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}.

@LemonBoy
LemonBoyforce-pushed the revive-6680 branch 2 times, most recently from 42c19c8 to da72233CompareNovember 26, 2020 17:03
@LemonBoyLemonBoy changed the title Revive 6680Change how u8 slices/array are formatted with {}Nov 26, 2020
Comment threadsrc/Compilation.zig Outdated
Comment on lines +2364 to +2365
\\pub const output_mode = OutputMode.{s};
\\pub const link_mode = LinkMode.{s};

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@LemonBoy
LemonBoyforce-pushed the revive-6680 branch 4 times, most recently from e01874a to 061b427CompareNovember 27, 2020 17:59
@LemonBoy

Copy link
Copy Markdown
ContributorAuthor

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

Copy link
Copy Markdown
Contributor

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

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

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

andrewrk commented Jan 1, 2021

Copy link
Copy Markdown
Member

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.

ryuukkand others added 14 commits January 2, 2021 10:48
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

Copy link
Copy Markdown
ContributorAuthor

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.
@andrewrkandrewrk added the breaking Implementing this issue could cause existing code to no longer compile or have different behavior. label Jan 3, 2021
g-w1 added a commit to g-w1/zig that referenced this pull request Jan 5, 2021
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: d9572442561168
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
Fixesziglang#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 "Fixziglang#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: aa0906e7e64dc4
Author: Andrew Kelley <andrew@ziglang.org>
Date: Mon Jan 4 13:40:51 2021 -0700
Merge branch 'g-w1-stage2-evalbranch'
closesziglang#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: c8e44d8807dc56
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: 5cc13100151f3b
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.
Fixesziglang#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
Fixesziglang#7657
commit 6838141
Merge: d8f3f1433e53d7
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: 3d151fb6548322
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: db1e97d974c008
Author: Andrew Kelley <andrew@ziglang.org>
Date: Sat Jan 2 19:03:37 2021 -0700
Merge branch 'LemonBoy-revive-6680'
closesziglang#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: a9c75a2763d807
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
Fixziglang#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.
Closesziglang#7188
@mikdusanmikdusan added the release notes This PR should be mentioned in the release notes. label Jan 24, 2021
@andrewrkandrewrk added this to the 0.9.0 milestone Apr 18, 2024
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

breakingImplementing this issue could cause existing code to no longer compile or have different behavior.release notesThis PR should be mentioned in the release notes.standard libraryThis issue involves writing Zig code for the standard library.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

11 participants

@LemonBoy@data-man@jedisct1@ikskuh@andrewrk@marler8997@Tetralux@FireFox317@Vexu@alexnask@mikdusan