Closes ziglang#13325

Similar to what was done for EdDSA, allow incremental creation
and verification of ECDSA signatures.

Doing so for ECDSA is trivial, and can be useful for TLS as well
as the future package manager.

These utility functions allow reading from (stage2) packed memory at
runtime-known offsets.

Packed memory has a well-defined layout that doesn't require
conversion from an integer to read from. Let's use it :-)

This change means that for bitcasting to/from a packed value that
is N layers deep, we no longer have to create N temporary big-ints
and perform N copies.

Other miscellaneous improvements:
  - Adds support for casting to packed enums and vectors
  - Fixes bitcasting to/from vectors outside of a packed struct
  - Adds a fast path for bitcasting <= u/i64
  - Fixes bug when bitcasting f80 which would clear following fields

This also changes the bitcast memory layout of exotic integers on
big-endian systems to match what's empirically observed on our targets.
Technically, this layout is not guaranteed by LLVM so we should probably
ban bitcasts that reveal these padding bits, but for now this is an
improvement.

Further enhance explanation of why expression is evaluated at comptime

Perform C-style arithmetic conversions on operands to division operator
in macros

Closes ziglang#13162

There's probably plenty of room to optimize these further in the
future, but for the moment this gives ~3x improvement on Intel
x86-64 processors, ~5x on AMD, and ~10x on M1 Macs.

These extensions are very new - Most processors prior to 2020 do
not support them.

AVX-512 is a slightly older alternative that we could use on Intel
for a much bigger performance bump, but it's been fused off on
Intel's latest hybrid architectures and it relies on computing
independent SHA hashes in parallel. In contrast, these SHA intrinsics
provide the usual single-threaded, single-stream interface, and should
continue working on new processors.

AArch64 also has SHA-512 intrinsics that we could take advantage
of in the future

This feature detection must be done at comptime so that we avoid
generating invalid ASM for the target.

This gets us most of the way back to the performance I had when
I was using the LLVM intrinsics:
  - Intel Intel(R) Core(TM) i7-1068NG7 CPU @ 2.30GHz:
       190.67 MB/s (w/o intrinsics) -> 1285.08 MB/s
  - AMD EPYC 7763 (VM) @ 2.45 GHz:
       240.09 MB/s (w/o intrinsics) -> 1360.78 MB/s
  - Apple M1:
       216.96 MB/s (w/o intrinsics) -> 2133.69 MB/s

Minor changes to this source can swing performance from 400 MB/s to
1400 MB/s or... 20 MB/s, depending on how it interacts with the
optimizer. I have a sneaking suspicion that despite LLVM inheriting
GCC's extremely strict inline assembly semantics, its passes are
rather skittish around inline assembly (and almost certainly, its
instruction cost models can assume nothing)

Comptime code can't execute assembly code, so we need some way to
force comptime code to use the generic path. This should be replaced
with whatever is implemented for ziglang#868, when that day comes.

I am seeing that the result for the hash is incorrect in stage1 and
crashes stage2, so presumably this never worked correctly. I will follow
up on that soon.

This also fixes a bug where the feature gating was not taking
effect at comptime due to ziglang#6768

Introduce `std.mem.readPackedInt` and improve bitcasting of packed memory layouts

crypto.sha2: Use intrinsics for SHA-256 on x86-64 and AArch64

Closes ziglang#1897

Closes ziglang#9415

…able

Closes ziglang#12721

…ointer

Closes ziglang#12042

Closes ziglang#13295

Closes ziglang#12768

Before, the code for building glibc stubs used a special case of the
Cache API that did not add any file inputs, and did not use
writeManifest(). This is not really how the Cache API is designed to
work and it shows because there was a race condition.

This commit adds as an input file the abilists file that comes with
Zig's installation, which has the added benefit of making glibc stub
caching properly detect cache invalidation when the user decides to
overwrite their abilists file. This harmonizes with the rest of how Zig
works, which intentionally allows you to hack the installation files and
have it behave properly with the cache system.

Finally, because of having any file inputs, the normal API flow of the
Cache system can be used, eliminating the one place that used the Cache
API in a special way. In other words, it uses writeManifest() now and
properly obeys the cache hit/miss semantics.

closes ziglang#13160

glibc: fix race condition when building stubs

Also add some NAME_MAX or equivalent definitions where necessary

… name components

Each u16 within a file name component can be encoded as up to 3 UTF-8 bytes, so we need to use MAX_NAME_BYTES to account for all possible UTF-8 encoded names.

Fixes ziglang#8268

…orms

This is a slightly weird situation, because the 'real' value may depend on the host platform that the WASI is being executed on.

Make the test use the minimum length and set MAX_NAME_BYTES to the maximum so that:
- the test will work on any host platform
- *and* the MAX_NAME_BYTES will be able to hold the max file name component on any host platform

Plan9: Fix The Backend

C backend fixes

Windows: Fix Iterator name buffer size not handling all possible file name components

closes ziglang#12689

We have to balance the timings to end up below the two hour mark.

It was temporarily disabled due to a self-hosted compiler
miscompilation.

closes ziglang#12178

Correctly handle calculating encompassing atoms for local
relocations (`r_extern == 0`).

See ziglang#13357

macho: fix performance regression for x86_64 and -dead_strip

this is a hack meant to restore functionality for the upcoming release,
a proper analysis of the new zir structure is required to make a robust
change.

Better Autodoc Src File Links

* std.os.uefi: integer backed structs, add tests to catch regressions

device_path_protocol now uses extern structs with align(1) fields because
the transition to integer backed packed struct broke alignment

added comptime asserts that device_path_protocol structs do not violate
alignment and size specifications

We need to be careful to respect side-effects/branching in these
cases, but otherwise this behaves very similarly to multiplication.
`lhs and rhs == false` if either lhs or rhs is comptime-known `false`,
just like `lhs * rhs == 0` if either lhs or rhs is comptime-known to
be zero.

Similar reasoning applies to `lhs or rhs`.

While continue expressions can access the capture, so ensure that it is
unwrapped in an outer scope.

Same as preceding change, but for stage2.

This avoids a crash analyzing check_comptime_control_flow.

Previously, if you used `zig test -ofmt=c -target foobar` then Zig would
try to compile the generated C code with the native target instead of
"foobar".

With this change, `--test-cmd` with e.g. QEMU still won't work, but at
least the binary will get compiled for the correct target.

Instead of making the memory alignment functions more complicated, I
added more API documentation for their existing semantics.

closes ziglang#12118
closes ziglang#12135

closes ziglang#11112
closes ziglang#12496

…)"

This reverts commit 06310e3, reapplying
commit a430630.

I deeply apologize to @moosichu and those affected by this bug. The
original fix was actually fine. When I reverted it, I misremembered
how the Cache API works. I thought the fix was going to introduce
nondeterminism into the hash, but I forgot that the order of files in
the manifest doesn't actually matter when checking for a cache hit.

Actually, it does matter a little bit. This fix has a subtle downside
which is that it does introduce the possibility of false negatives when
checking for cache hits of 2+ iterations ago. For example, if the code
goes from "foo", to "bar", and then back to "foo", it may look like a
cache miss when it should have been a hit because 2 iterations ago the
code was the same. However, this is an uncommon use case, and all it
does is cause a bit of wasted time and disk space. That said, my
suggestion from earlier still applies and would be a nice follow-up
enhancement to this fix:

The proper solution to this is to, in whole cache mode, append the hash
inputs to some data structure, and then after the compilation is
complete, do some kind of sorting on the hash inputs so that they will
be the same order every time, then apply them in sequence. No lock on
the Cache object is needed for this scheme.

closes ziglang#11063

closes ziglang#13333

AstGen: avoid access to capture defined in an inner scope from a continue expression

closes ziglang#13192

Make `x and false` and `x or true` comptime-known

When a number of bytes to be allocated is so great that alignForward()
is not possible, return `error.OutOfMemory`.

Companion commit to 3f30030.

Repeat of a4eb221 for the newly-synchronized zld code.

Restores ability to compile Zig for WASI.

Depending on how ziglang#13366 is resolved, this code should arguably have
been rejected with a compile error in the first place.

 * Fix _start on aarch64.
 * Add fallbacks when a float type is unsupported.

Fixes ziglang#13357

…iglang#13386)

Fixes ziglang#13378

When Wasm extern functions contain the same name, but have a
different module name such as `extern "a"` vs `extern "b"` LLVM will
currently resolve the two functions to the same symbol. By mangling
the name of the symbol, we ensure the functions are resolved
seperately. We mangle the name by applying <name>|<module> where
module is also known as the library name.

This adds a simple linker test to ensure the built library contains
an import entry for each extern function call that was mangled.

Rewrite GHASH to use 128-bit multiplication over non-reversed
integers, and up to 8 blocks aggregated reduction.

lib/std/crypto/benchmark.zig results:

Xeon E5:
  Before: 1604 MiB/s
   After: 4005 MiB/s

Apple M1:
  Before: 2769 MiB/s
   After: 6014 MiB/s

This also makes AES-GCM faster by the way.

- Fixed missing airRetPtr implementation
- Fixed wrong pop_regs order
- Fixed wrong source and destination register in store

Fixes regression introduced in ziglang@0b47e69

Vectors are not yet implemented in the C backend, so no reason to
prevent code using the standard library from compiling in the meantime.

…rget.ofmt`

This will have to be replaced with manual volatile stores.

Multiple outputs work now, so use that instead of deleting clobbers.