After this commit, `pub export fn main() c_int { ... }` will be
correctly detected as the intended entry point, and therefore start code
will not try to export its own conflicting `main` function.
* Implement basic union support
- lots of stuff is still TODO, including runtime field access
- also TODO: resolving the union tag type
- comptime field access is implemented
* DRY up some code by using the `Zir.DeclIterator` for skipping over
decls in structs and unions.
* Start to clean up Sema with regards to calling `.value()` to find out
a const value. Instead, Sema code should call one of these two:
- `resolvePossiblyUndefinedValue` (followed by logic dealing with
undefined values)
- `resolveDefinedValue` (a compile error will be emitted if the value
is undefined)
* An exported function with an unspecified calling convention gets the
C calling convention.
* Implement comptime field access for structs.
* Add another implementation of "type has one possible value" in Sema.
This is a bit unfortunate since the logic is duplicated, but the one
in Type asserts that the types are resolved already, and is
appropriate to call from codegen, while the one in Sema performs
type resolution if necessary, reporting any compile errors that occur
in the process.
The goal is to get start code to be able to inspect the calling
convention of `main` in order to determine whether to export a main for
libc to call, or to allow the root source file to do it.
Coming from other languages it might be tempting for programmers to
accidentally leave out the return type instead of returning 'void'.
The error for this used to be
error: invalid token: '{'
pub fn main() {
^
which is misleading. The '{' is expected but only after a return type.
The new message is
error: expected return type (use 'void' to return nothing), found: '{'
pub fn main() {
^
which not only points out the real error but also hints at a (probably)
very common case where someone coming from e.g. Go is used to not
specifying a return type if a function returns nothing and thus forgets
to put 'void' there.
It might seem overkill to hint at the 'void' option but then the
compiler error messages are our user interface to the programmer. We
can be better than other languages in our error messages and leaving
out the return type seems to be a rather clear indication of the above
mentioned issue. Adding this will help more than distract.
during an incremental update change detection,
the function call to get the old contents hash took place
after mangling the old ZIR index, making it access the wrong
array index.
The results have been cross-checked with LLVM's APFloat implementation
by randomly sampling the f32/f64 space, while the f16 one was completely
checked given the small size.
The presence of a trailing comma in the single and only input/output
declaration confused the parser and made zig fmt discard any element
placed after the comma.
PR #7827 added some new `std.Target.Os.Tag` before `other`.
The corresponding enum in stage1.h was not updated, which caused a
mismatch in the underlying integer values. While attempting to target
`other`, I encountered crashes.
This PR updates the stage1.h enum to include the added OS tags.
The new tags also had to be added to various switch cases to fix
compiler warnings, but have not been tested in any way.
On OpenBSD, connecting to a newly-allocated port on an unspecified IPv4
host address causes EINVAL. This was found by @mikdusan when running TCP
tests on OpenBSD.
This commit fixes TCP tests on OpenBSD by having all tests that allocate
a new host-port pair to have the host IPv4/IPv6 address point to the
host's loopback adapter (on localhost).
There are some small problems here and there, mostly due to the pointers
having the lsb set and disrupting the fn alignment tests and the
`@FrameSize` implementation.
To be honest all this detection logic is starting to become a real PITA,
the ARM32 version can be possibly removed as the generic version
optimizes pretty well...
* UTF16 gets its own section, `__TEXT,__ustring`
* TLV data and bss sections have to aligned to the same max alignment
according to Apple rdar comment in the latest ld64
