As of 6249a24, align() is not allowed on packed struct fields
and as such the align(4) was removed from the first field of
EdidOverrideProtocolAttributes. The endgame here is packed struct
backed by explicit integers, in this case a u32, but until that
is implemented put the align(4) on the pointer to avoid breaking
someone's UEFI code in a hard to debug way.
This reverts commit 136a43934bc08dc3aee85f1182904b97456601d3, reversing
changes made to 9dd839b7ed15d1191f3303d069cffe0473e03e83.
This broke the behavior of `zig run`.
This implements #10113 for the self-hosted compiler only. It removes the
ability to override alignment of packed struct fields, and removes the
ability to put pointers and arrays inside packed structs.
After this commit, nearly all the behavior tests pass for the stage2 llvm
backend that involve packed structs.
I didn't implement the compile errors or compile error tests yet. I'm
waiting until we have stage2 building itself and then I want to rework
the compile error test harness with inspiration from Vexu's arocc test
harness. At that point it should be a much nicer dev experience to work
on compile errors.
* goals
- zig as linker for object files generated by other compilers
- zig-specific runtime features for eventual standardisation
* changes
- missing routines are marked with `missing`
- structure inspired by libgcc docs, but improved order and wording
- rename misspelled functions
- reorder and rephrase compiler_rt.zig to reflect documentation
- potential decimal float or fixed-point arithmetic support:
* 'Decimal float library routines' ca. 120 functions
* 'Fixed-point fractional library routines' ca. 300 functions
thanks to @Vexu for multiple reviews and @scheibo for review
In Mach engine we're seeing command line arguments to `zig build-lib`
exceed the 32 KiB limit that Windows imposes, due to the number of
sources and compiler flags we must pass in order to build gpu-dawn.
This change fixes the issue by having `Builder` check if the arguments
to a `zig build-*` command are >30 KiB and, if so, writes the arguments
to a file `zig-cache/args/<SHA2 of args>`. Then the command invocation
merely becomes `zig build-lib @<that file>`.
Fixes#10693Fixeshexops/mach#167
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
This reverts commit baead472d7641bdd96130354bafadc1fb1ed223b.
Let's go through the proposal process on this one. I want to push back
on this. My position is that, at the very least, a full trace of command
lines of sub-processes should be printed on failure, with the exception
of opt-in flags such as `--prominent-compile-errors`.
If a '(' is found where the continue expression was expected and it is
on the same line as the previous token issue an error about missing
colon before the continue expression.
Address https://github.com/ziglang/zig/issues/3477
This provides a mechanism for builds to fully report an error to the user and prevent zig from piling on extra noise.
For some errors if the found token is not on the same line as
the previous token, point to the end of the previous token.
This usually results in more helpful errors.
std.fmt.parseHexFloat allow both 0x and 0X as prefix, so in order to
keep things consistent. This commit modifies std.fmt.parseWithSign to
check for the prefix case insensitively in order to allow both upper
case and lower case prefix.
This change now allows: 0O, 0B and 0X as prefixes for parsing.
