Translate enum types as the underlying integer type. Translate enum constants
as top-level integer constants of the correct type (which does not necessarily
match the enum integer type).
If an enum constant's type cannot be translated for some reason, omit it.
See discussion https://github.com/ziglang/zig/issues/2115#issuecomment-827968279Fixes#9153
* Remove parser error on double ampersand
* Add failing test for double ampersand case
* Add error when encountering double ampersand in AstGen
"Bit and" operator should not make sense when one of its operands
is an address.
* Check that 2 ampersands are adjacent to each other in source string
* Remove cases of unused variables in tests
* Don't skip the TLS initialization (Fixes#9083)
* Add a test case where a PIE program is built and run
* Refactor the common initialization code in the Linux startup
sequence.
This is for consistency with the documentation on sentinel-terminated
{arrays,slices,pointers} which already use `N` for a comptime-inferred
size rather than `X`.
Also adds a behavioral test to assert that a string literal is returned.
This was already the case, but the documentation failed to point out
that the returned value is of type `*const [N:0]u8`, i.e. that of a
string literal.
Also adds a behavioral test to assert that this is the case.
Don't move static local variables into the top-level scope since this
can cause name clashes if subsequently-defined variables or parameters
in different scopes share the name.
Instead, use a variable within a struct so that the variable's lexical
scope does not change. This solution was suggested by @LemonBoy
Note that a similar name-shadowing problem exists with `extern` variables
declared within block scope, but a different solution will be needed since
they do need to be moved to the top-level scope and we can't rename them.
Since v0.23 release of Wasmtime, if we want to iterate a directory
Y then directory Y needed to have been granted `fd_readdir` right.
However, it is now also required for directory X to carry `fd_readdir`
right, and so on, up-chain all the way until we reach the preopen
(which possesses all rights by default).
This caused problems for us since our libstd implementation is more
fine-grained and allowed for parent dirs not to carry the right while
allow for iterating on its children. My proposal here is to always
grant `fd_readdir` right as part of
`std.fs.Dir.OpenDirOptions.access_sub_paths`. This seems to be the
approach taken by Rust also, plus we should be justified to take this
approach since WASI is experimental and snapshot1 will be discontinued
eventually and replaced with a new approach to access management
that will require a complete rewrite of our libstd anyhow.
This small change makes working with tuple types much easier, allowing
the use of anonymous (eg. obtained with meta.ArgsTuple) tuples in more
places without the need for specifying each (quoted!) field name in the
initializer.
