Normally when using LLD to link, Zig uses a file named "lld.id" in the
same directory as the output binary which contains the hash of the link
operation, allowing Zig to skip linking when the hash would be unchanged.
In the case that the output binary is being emitted into a directory which
is externally modified - essentially anything other than zig-cache - then
this flag would be set to disable this machinery to avoid false positives.
* Better defaults when using -fno-LLVM
* Fix compiler_rt and libc static libraries were getting a .zig
extension instead of .a extension.
* when using the stage1 backend, put the object file next to the
stage1.id file in the cache directory. this prevents an object file
from polluting the cwd when using zig from the CLI.
* prefix with the message level
* if the scope is not default, also prefix with the scope
This makes the stack trace test pass, with no changes to the
test case, because errors returned from main() now print
`error: Foo` just like they do in master branch.
* Don't try to generate C header files yet since it will only cause a
crash saying the feature is unimplemented.
* Rename the CLI options for release modes to use the `-O` prefix to
match C compiler precedent. Options are now `-ODebug`,
`-OReleaseFast`, `-OReleaseSafe`, `-OReleaseSmall`. The optimization
mode matches the enum tags of std.builtin.Mode. It is planned to, at
some point, rename std.builtin.Mode to std.builtin.OptimizationMode
and modify the tags to be lower case to match the style convention.
- Update build.zig code to support this new CLI.
* update std.zig.binNameAlloc to support an optional Version and update
the implementation to correctly deal with dynamic library version
suffixes.
* Reorganize crypto/aes in order to separate parameters, implementations and
modes.
* Add a zero-cost abstraction over the internal representation of a block,
so that blocks can be kept in vector registers in optimized implementations.
* Add architecture-independent aesenc/aesdec/aesenclast/aesdeclast operations,
so that any AES-based primitive can be implemented, including these that don't
use the original key schedule (AES-PRF, AEGIS, MeowHash...)
* Add support for parallelization/wide blocks to take advantage of hardware
implementations.
* Align T-tables to cache lines in the software implementations to slightly
reduce side channels.
* Add an optimized implementation for modern Intel CPUs with AES-NI.
* Add new tests (AES256 key expansion).
* Reimplement the counter mode to work with any block cipher, any endianness
and to take advantage of wide blocks.
* Add benchmarks for AES.
Password hashing functions are not general-purpose KDFs, and KDFs
don't have to satisfy the same properties as a PHF.
This will allow fast KDFs such as the HKDF construction to be in a
category of their own, while clarifying what functions are suitable
for using passwords as inputs.
