fix drivers: zig {cc,c++}
- `-dynamiclib` is an alias to `-shared`
- associate `-dynamiclib` with zig `.shared` semantics
fix drivers: zig {cc,c++,build-lib,build-exe}
- use `-dynamic` for {exe,dylib}
- for dylib this fixes a regression
- for exe this replaces incorrect use of `-static`
A warning is emitted when using the debug option --debug-log when the compiler
was not compiled using the build option -Dlog. Additionnaly, the scopes are not
added to log_scopes as they have no effect.
The current implementation of the target C ABI rules is hopelessly bad,
let's tack some more rules on top in order to prevent some
miscompilations.
Truth to be told the same rule should be applied also to parameters, but
I really can't stand stage1.
The modification to the grammar in the comment is in line with the
grammar in the zig-spec repo.
Note: checking if the previous token is a colon is insufficent to tell
if a block has a label, the identifier must be checked for as well. This
can be seen in sentinel terminated slicing: `foo[0..1:{}]`
Given a pointer operand `ptr` and a signed integer operand `idx`
`ptr + idx` and `idx + ptr` -> ptr + @bitCast(usize, @intCast(isize, idx))
`ptr - idx` -> ptr - @bitCast(usize, @intCast(isize, idx))
Thanks @LemonBoy for pointing out that we can take advantage of wraparound
to dramatically simplify the code.
Clang docs say:
> Like -MMD, but also implies -E and writes to stdout by default.
Previously, Zig handled this option by forwarding it directly to Clang,
and disabling depfiles. However this did not adhere to Clang's documented
behavior of these flags.
Now, in addition to being forwarded directly to Clang, `-MM` also
sets c_out_mode = .preprocessor, just like `-E`.
Another issue I noticed is that Zig did not recognize the aliases for
-MG, -MM, or -MMD. The aliases are now recognized.
The presence of ZIG_VERBOSE_LINK now enables --verbose-link.
The presence of ZIG_VERBOSE_CC now enables --verbose-cc.
These are useful when debugging usage of `zig cc` which does not have
CLI flags for these options, since they are not valid C compiler flags.
* Now it supports being an lvalue (see additional lines in the test
case).
* Properly handles a pointer result location (see additional lines in
the test case that assign the result of the orelse to a variable
rather than a const).
* Properly sets the result location type when possible, so that type
inference of an `orelse` operand expression knows its result type.
We can now codegen optionals! This includes the following instructions:
- is_null
- is_null_ptr
- is_non_null
- is_non_null_ptr
- optional_payload
- optional_payload_ptr
- br_void
Also includes a test for optionals.
