As of Clang 16.x, it will by default read extra flags from /etc/clang.
I'm sure the person who implemented this means well, but they have a lot
to learn about abstractions and where the appropriate boundaries between
them are. The road to hell is paved with good intentions. Fortunately it
can be disabled.
Currently `zig cc`, when confronted with a linker argument it does
not understand, skips the flag and emits a warning.
This has been causing headaches for people that build third-party
software (including me). Zig seemingly builds and links the final
executable, only to segfault when running it.
If there are linker warnings when compiling software, the first thing we
have to do is add support for ones linker is complaining, and only then
go file issues. If zig "successfully" (i.e. status code = 0) compiles a
binary, there is instead a tendency to blaim "zig doing something
weird". (I am guilty of this.) In my experience, adding the unsupported
arguments has been quite easy; see #11679, #11875, #11874 for recent
examples.
With the current ones (+ prerequisites below) I was able to build all of
the CGo programs that I am encountering at $dayjob. CGo is a reasonable
example, because it is exercising the unusual linker args quite a bit.
Prerequisites: #11614 and #11863.
Tested by: created a "hello world" C file and compiled with:
zig cc -v main.c -Wl,--sort-section=name -o main
... and verified the `--sort-section=name` is passed to ld.lld.
Refs https://github.com/zigchroot/zig-chroot/issues/1
When the following is specified
```
$ zig build-obj -fcompiler-rt example.zig
```
the resulting relocatable object file will have the compiler-rt
unconditionally embedded inside.
```
$ nm example.o
...
0000000012345678 W __truncsfhf2
...
```
This is just a simple/hacky feature to report the source of a linking
error. I found this helpful in fixing-up some of my libs when recently
switching from an x86_64 to aarch64 device, so thought it might be
useful to others a well before zld has a fully featured error reporting
system.
Some examples using {#syntax_block|zig|...#} either have a valid syntax
or it is easy to make the syntax valid. Update these example to use
{#code_begin|syntax|...#}.
Remove extra whitespace in the error_union_parsing_u64.zig example.
Replace size_t with usize in the call_malloc_from_zig.zig example.
This makes it so that when there is a tree of std.Build objects, only
one zig-cache is used (the top-level application) instead of polluting
package directories with zig-cache folders.
* Use std.Build.Cache.Directory instead of a string for storing the
cache roots and build roots.
* Set up a std.Build.Cache in build_runner.zig and use it in
std.Build.RunStep for avoiding redundant work.
Now that this API is used by the build system, these debug logs are
problematic because build scripts run in debug mode, making these logs
noisy output.
This provides file path as a command line argument to the command being
run, and returns a FileSource which can be used as inputs to other APIs
throughout the build system.
Unfortunately, it is implemented by pooping a ton of temporary files
into zig-cache/tmp for the time being. I think one of the very next
improvements to the build system should be moving the compiler's cache
system to the standard library and using it in the build system. I had a
look at the dependencies and it is already pretty untangled.
Deprecate CompileStep.run. The problem with this function is that it
does the RunStep with the same build.zig context as the CompileStep, but
this is not desirable when running an executable that is provided by a
dependency package. Instead, users should use `b.addRunArtifact`.
This has the additional benefit of conforming to the existing naming
conventions.
Additionally, support enum literals in config header options values.
Ascon has been selected as new standard for lightweight cryptography
in the NIST Lightweight Cryptography competition.
Ascon won over Gimli and Xoodoo.
The permutation is unlikely to change. However, NIST may tweak
the constructions (XOF, hash, authenticated encryption) before
standardizing them. For that reason, implementations of those
are better maintained outside the standard library for now.
In fact, we already had an Ascon implementation in Zig:
`std.crypto.aead.isap` is based on it. While the implementation was
here, there was no public API to access it directly.
So:
- The Ascon permutation is now available as `std.crypto.core.Ascon`,
with everything needed to use it in AEADs and other Ascon-based
constructions
- The ISAP implementation now uses std.crypto.core.Ascon instead of
keeping a private copy
- The default CSPRNG replaces Xoodoo with Ascon. And instead of an
ad-hoc construction, it's using the XOFa mode of the NIST submission.
This reverts commit abc9530a88d24350481d9264edcde300f293929a.
This patch implies that the idiomatic Zig way of handling anytype
parameter is to write a bunch of boilerplate instead of directly
accessing type information and relying on the compiler to be useful.
I don't want it to be this way.
It is the compiler's job to make useful error messages when the wrong
field of a type info result is accessed, and it is the zig programmer's
job to understand what it means when a compile error points at the field
access of `@typeInfo` (along with the relevant callsites).
One thing that might be useful would be having the compiler be aware of
module boundaries and highlighting the boundaries of them. The first
reference note after crossing a module boundary is likely the most
interesting one.
- Copy and adjust __divmodsi4 tests for __divmoddi4 and __divmodti4.
- Assuming d = a/b does not overflow (MIN/-1) or uses div by 0,
then tmp = (d * b) = (a/b * b) = a does not overflow.
=> Remove wraparound for remainder in applicable routines.
These are unused in LLVM, but in gcc used for example by rl78.
Move test files into common file, add tests for aforementioned routines
and missing ones for __lshrti3.
