* riscv64: adjust alignment and size of 128-bit integers.
* take ofmt=c into account for ABI alignment of 128-bit integers and
structs.
* Type: make packed struct support intInfo
* fix f80 alignment for i386-windows-msvc
This makes `0123` and `u0123` etc. illegal.
I'm now confident that this is a good change because
I actually caught two C header translation mistakes in `haiku.zig` with this.
Clearly, `0123` being octal in C (TIL) can cause confusion, and we make this easier to read by
requiring `0o` as the prefix and now also disallowing leading zeroes in integers.
For consistency and because it looks weird, we disallow it for integer types too (e.g. `u0123`).
Fixes#11963Fixes#12417
The following, from the documentation as of the time of writing, illustrates
the problem:
```zig
// Compile time coercion of float to int
test "implicit cast to comptime_int" {
var f: f32 = 54.0 / 5;
_ = f;
}
```
It is not clear how to unify the types of 54.0 and 5 to perform the
division. We can either
- cast 54.0 to comptime_int resulting in @as(comptime_int, 10), which is
casted to @as(f32, 10), or
- cast 5 to comptime_float resulting in @as(comptime_float, 10.8), which
is casted to @as(f32, 10.8)
Since the two resulting values are different, a compiler error is appropriate.
If we know that casting to either type will result in the same value we
don't need to error. For instance, 10.0 / 2 is okay, as is 10 / 2.0.
Fixes: #12364
The `Value.eql` function has to test for value equality *as-if* the lhs
value parameter is coerced into the type of the rhs. For tagged unions,
there was a problematic case when the lhs was an anonymous struct,
because in such case the value is empty_struct_value and the type
contains all the value information. But the only type available in the
function was the rhs type.
So the fix involved making `Value.eqlAdvanced` also accept the lhs type,
and then enhancing the logic to handle the case of the `.anon_struct` tag.
closes#12418
Tests run locally:
* test-behavior
* test-cases
When lowering a struct type to an LLVM struct type, keep track of
whether there are any underaligned fields. If so, then make it a packed
llvm struct. This works because we already insert manual padding bytes
regardless.
We could unconditionally use an LLVM packed struct; the reason we bother
checking for underaligned fields is that it is a conservative choice, in
case LLVM handles packed structs less optimally. A future improvement
could simplify this code by unconditionally using packed LLVM structs
and then make sure measure perf is unaffected.
closes#12190
`validateExternType` does not require the type to be resolved so we can
check it earlier. Only doing it in `resolveTypeFully` lead to worse or
missing compile errors.
