AstGen provides all function call arguments with a result location,
referenced through the call instruction index. The idea is that this
should be the parameter type, but for `anytype` parameters, we use
generic poison, which is required to be handled correctly.
Previously, generic instantiations and inline calls worked by evaluating
all args in advance, before resolving generic parameter types. This
means any generic parameter (not just `anytype` ones) had generic poison
result types. This caused missing result locations in some cases.
Additionally, the generic instantiation logic caused `zirParam` to
analyze the argument types a second time before coercion. This meant
that for nominal types (struct/enum/etc), a *new* type was created,
distinct to the result type which was previously forwarded to the
argument expression.
This commit fixes both of these issues. Generic parameter type
resolution is now interleaved with argument analysis, so that we don't
have unnecessary generic poison types, and generic instantiation logic
now handles parameters itself rather than falling through to the
standard zirParam logic, so avoids duplicating the types.
Resolves: #16566Resolves: #16258Resolves: #16753
Well, this was a journey!
The original issue I was trying to fix is covered by the new behavior
test in array.zig: in essence, `ty` and `coerced_ty` result locations
were not correctly propagated.
While fixing this, I noticed a similar bug in struct inits: the type was
propagated to *fields* fine, but the actual struct init was
unnecessarily anonymous, which could lead to unnecessary copies. Note
that the behavior test added in struct.zig was already passing - the bug
here didn't change any easy-to-test behavior - but I figured I'd add it
anyway.
This is a little harder than it seems, because the result type may not
itself be an array/struct type: it could be an optional / error union
wrapper. A new ZIR instruction is introduced to unwrap these.
This is also made a little tricky by the fact that it's possible for
result types to be unknown at the time of semantic analysis (due to
`anytype` parameters), leading to generic poison. In these cases, we
must essentially downgrade to an anonymous initialization.
Fixing these issues exposed *another* bug, related to type resolution in
Sema. That issue is now tracked by #16603. As a temporary workaround for
this bug, a few result locations for builtin function operands have been
disabled in AstGen. This is technically a breaking change, but it's very
minor: I doubt it'll cause any breakage in the wild.
llvm: convert more things to use Builder
* finish converting intrinsics
* finish converting attributes
* finish converting instructions
* finish converting globals
* pass behavior tests with no dependence on the llvm api (`-fno-libllvm`)
* autodoc: init guide TOC work
* autodoc: working guides toc navigation
* autodoc: more improvements
* autodoc: ui refinements
* autodoc: new layout and init descriptions for namespaces in std.zig
* renamed enum_big_numbers_quoted option to enum_nonportable_numbers_as_strings
* updated stringify doc to mention the option
I also reversed the logic to determine whether an integer is nonportable,
it seemed easier to reason about.
I also took a stab at applying the new option to floats, but, I got stuck
at trying to print large floats, not sure if Zig supports that yet.
The previous magic numbers used `1 << 52`, which did not account for the
implicit leading one in the floating point format. The RFC is correct
when it uses an exponent of 53. Technically these exclusive endpoints
are also representable, but everyone including the RFC seems to use them
exclusively.
Also, delete special case optimizations related to the type which have
already been implemented in the zig compiler to produce comptime values
for tautological runtime comparisons.
std.json follows interoperability recommendations from RFC8259 to limit
JSON number values to those that fit inside an f64. However, since Zig
supports arbitrarily large JSON numbers, this breaks roundtrip data
congruence.
To appease both use cases, I've added an option `emit_big_numbers_quoted`
to StringifyOptions. It's disabled by default which preserves roundtrip
but can be enabled to favor interoperability.
Before this commit, you could use readElfDebugInfo independently with
one catch: the data is not freed since the deinitialization functions
for ModuleDebugInfo are private. This change makes them public so the
users of such function and similar can free the memory after the
debug symbols have been used.
