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.
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
Functions generated by Fiat-crypto are not prefixed by their description any more. This matches an upstream change.
We can now use a single type for different curves and implementations.
The field type is now generic, so we can properly handle the base field and scalars without code duplication.
