See https://eprint.iacr.org/2019/1492.pdf for justification.
8 rounds ChaCha20 provides a 2.5x speedup, and is still believed
to be safe.
Round-reduced versions are actually deployed (ex: Android filesystem
encryption), and thanks to the magic of comptime, it doesn't take much
to support them.
This also makes the ChaCha20 code more consistent with the Salsa20 code,
removing internal functions that were not part of the public API any more.
No breaking changes; the public API remains backwards compatible.
Bring this in line with how variable declarations are handled.
Open a new indentation level for the initialization expression to handle
nested expressions like blocks.
Closes#7618
The main realization here was that getting rid of the early returns
in renderWhile() and rewriting the logic into a mostly unified execution
path took things from ~200 lines to ~100 lines and improved consistency
by deduplicating code.
Also add several test cases and fix a few issues along the way:
Fixes https://github.com/ziglang/zig/issues/6114
Fixes https://github.com/ziglang/zig/issues/8022
Add failing testcase to reproduce issue 8088
Tidy up renderWhile(), factoring out renderWhilePayload()
Ensure correct newline is used before 'then' token in while/for/if
Handle indents for 'if' inside 'for' or 'while'
Stop special-casing 'if' compared to 'for' and 'while'
liburing commit: 1bafb3ce5f
As stated in the liburing commit message, this fixes a regression,
reverting code that was added specutively to avoid a syscall in some
cases.
The modification to the grammar in the comment is in line with the
grammar in the zig-spec repo.
Note: checking if the previous token is a colon is insufficent to tell
if a block has a label, the identifier must be checked for as well. This
can be seen in sentinel terminated slicing: `foo[0..1:{}]`
In order to update the printed progress string the code tried to move
the cursor N cells to the left, where N is the number of written bytes,
and then clear the remaining part of the line.
This strategy has two main issues:
- Is only valid if the number of characters is equal to the number of
written bytes,
- Is only valid if the line doesn't get too long.
The second point is the main motivation for this change, when the line
becomes too long the terminal wraps it to a new physical line. This
means that moving the cursor to the left won't be enough anymore as once
the left border is reached it cannot move anymore.
The wrapped line is still stored by the terminal as a single line,
despite now taking more than a single one when displayed. If you try to
resize the terminal you'll notice how the contents are reflowed and are
essentially illegible.
Querying the cursor position on non-Windows systems (plot twist,
Microsoft suggests using VT escape sequences on newer systems) is
extremely cumbersome so let's do something different.
Before printing anything let's save the cursor position and clear the
screen below the cursor, this way we ensure there's absolutely no trace
of stale data on screen, and after the message is printed we simply
restore it.
