It seems the webassembly backend does not want the exception that
`structFieldAlignmentExtern` makes for 128-bit integers. Perhaps that
logic should be modified to check if the target is wasm.
Without this, this branch fails the C ABI tests for wasm, causing this:
```
wasm-ld: warning: function signature mismatch: zig_struct_u128
>>> defined as (i64, i64) -> void in cfuncs.o
>>> defined as (i32) -> void in test-c-abi-wasm32-wasi-musl-ReleaseFast.wasm.o
```
When struct types have no field names, the names are implicitly
understood to be strings corresponding to the field indexes in
declaration order. It used to be the case that a NullTerminatedString
would be stored for each field in this case, however, now, callers must
handle the possibility that there are no names stored at all. This
commit introduces `legacyStructFieldName`, a function to fake the
previous behavior. Probably something better could be done by reworking
all the callsites of this function.
This changeset fixes the handling of alignment in several places. The
new rules are:
* `@alignOf(T)` where `T` is a runtime zero-bit type is at least 1,
maybe greater.
* Zero-bit fields in `extern` structs *do* force alignment, potentially
offsetting following fields.
* Zero-bit fields *do* have addresses within structs which can be
observed and are consistent with `@offsetOf`.
These are not necessarily all implemented correctly yet (see disabled
test), but this commit fixes all regressions compared to master, and
makes one new test pass.
Previously it would canonicalize or not depending on some volatile
internal state of the compiler, now it forces resolution of the element
type to determine the alignment if it needs to.
All of the logic in `Value.elemValue` is quite questionable, but
printing an error is definitely better than crashing. Notably, this
should stop us from hitting crashes when dumping AIR.
This also modifies AstGen so that struct types use 1 bit each from the
flags to communicate if there are nonzero inits, alignments, or comptime
fields. This allows adding a struct type to the InternPool without
looking ahead in memory to find out the answers to these questions,
which is easier for CPUs as well as for me, coding this logic right now.
Structs were previously using `SegmentedList` to be given indexes, but
were not actually backed by the InternPool arrays.
After this, the only remaining uses of `SegmentedList` in the compiler
are `Module.Decl` and `Module.Namespace`. Once those last two are
migrated to become backed by InternPool arrays as well, we can introduce
state serialization via writing these arrays to disk all at once.
Unfortunately there are a lot of source code locations that touch the
struct type API, so this commit is still work-in-progress. Once I get it
compiling and passing the test suite, I can provide some interesting
data points such as how it affected the InternPool memory size and
performance comparison against master branch.
I also couldn't resist migrating over a bunch of alignment API over to
use the log2 Alignment type rather than a mismash of u32 and u64 byte
units with 0 meaning something implicitly different and special at every
location. Turns out you can do all the math you need directly on the
log2 representation of alignments.
It is very common, and well-defined, for a pointer on one side of a C ABI
to have a different but compatible element type. Examples include:
- `char*` vs `uint8_t*` on a system with 8-bit bytes
- `const char*` vs `char*`
- `char*` vs `unsigned char*`
Without this flag, Clang would invoke UBSAN when such an extern
function was called.
Might be nice to file an upstream issue and find out if there is a more
precise way to disable the problematic check.
`-fsanitize-cfi-icall-generalize-pointers` looks promising according to
the documentation, but empirically it does not work.
release/17.x branch, commit 8f4dd44097c9ae25dd203d5ac87f3b48f854bba8
This adds the flag `-D_LIBCPP_PSTL_CPU_BACKEND_SERIAL`. A future
enhancement could possibly pass something different if there is a
compelling parallel implementation. That libdispatch one might be worth
looking into.
* some manual fixes to generated CPU features code. in the future it
would be nice to make the script do those automatically. I suspect
the sm_90a thing is a bug in LLVM.
* add liteos to various target OS switches. I know nothing about this
OS; someone will need to work specifically on support for this OS
when the time comes to support it properly in zig.
* while waiting for the compiler, I went ahead and made more
conservative choices about when to use `inline` in std/Target.zig
Currently, the compiler (like @typeName) writes it `fn(...) Type` but
zig fmt writes it `fn (...) Type` (notice the space after `fn`).
This inconsistency is now resolved and function types are consistently
written the zig fmt way. Before this there were more `fn (...) Type`
occurrences than `fn(...) Type` already.
Safety is not a global flag that should be enabled or disabled for all
stores - it's lowered by the frontend directly into AIR instruction
semantics. The flag for this is communicated via the `store` vs
`store_safe` AIR instructions, and whether to write 0xaa bytes or not
should be decided in `airStore` and passed down via function parameters.
This commit is a step backwards since it removes functionality but it
aims our feet towards a better mountain to climb.
C99 introduced designated initializers for structs. Omitted fields are
implicitly initialized to zero. Some C APIs are designed with this in
mind. Defaulting to zero values for translated struct fields permits Zig
code to comfortably use such an API.
Closes#8165
This introduces the concept of a "weak global name" into translate-c.
translate-c consists of two passes. The first is important, because it
discovers all global names, which are used to prevent naming conflicts:
whenever we see an identifier in the second pass, we can mangle it if it
conflicts with any global or any other in-scope identifier.
Unfortunately, this is a bit tricky for structs, unions, and enums. In
C, these types are not represented by normal identifers, but by separate
tags - `struct foo` does not prevent an unrelated identifier `foo`
existing. In general, we want to translate type names to user-friendly
ones such as `struct_foo` and `foo` where possible, but we can't
guarantee such names will not conflict with real variable names.
This is where weak global names come in. In the initial pass, when a
global type declaration is seen, `struct_foo` and `foo` are both added
as weak global names. This essentially means that we will use these
names for the type *if possible*, but if there is another global with
the same name, we will mangle the type name instead. Then, when actually
translating the declaration, we check whether there's a "true" global
with a conflicting name, in which case we mangle our name. If the
user-friendly alias `foo` conflicts, we do not attempt to mangle it: we
just don't emit it, because a mangled alias isn't particularly helpful.
