| Age | Commit message (Collapse) | Author |
|
Good riddance!
|
|
I'm not sure why the other commits in this branch caused this fix to be
necessary. Also, there seems to be more fixes necessary before tests
will pass.
|
|
Storing defers this way has the benefits that the defer doesn't get
analyzed multiple times in AstGen, it takes up less space, and it
makes Sema aware of defers allowing for 'unreachable else prong'
error on error sets in generic code.
The disadvantage is that it is a bit more complex and errdefers with
payloads now emit a placeholder instruction (but those are rare).
Sema.zig before:
Total ZIR bytes: 3.7794370651245117MiB
Instructions: 238996 (2.051319122314453MiB)
String Table Bytes: 89.2802734375KiB
Extra Data Items: 430144 (1.640869140625MiB)
Sema.zig after:
Total ZIR bytes: 3.3344192504882812MiB
Instructions: 211829 (1.8181428909301758MiB)
String Table Bytes: 89.2802734375KiB
Extra Data Items: 374611 (1.4290275573730469MiB)
|
|
Previously if a decl failed its capture scope would be deallocated and
set to undefined which would then lead to invalid dereference in
`zirClosureGet`. To avoid this set the capture scope to a special
failed state and fail the current decl with dependency failure if
the failed state is encountered in `zirClosureGet`.
Closes #12433
Closes #12530
Closes #12593
|
|
Closes #12769
|
|
Closes #12750
|
|
Stage2 fixes
|
|
|
|
|
|
|
|
Closes #12291
|
|
Closes #11769
|
|
Closes #12698
|
|
Closes #12698
|
|
|
|
Closes #12706
|
|
When instantiating a generic function, there is a period of time where
the function is inserted into monomorphed_funcs map, but is not yet
initialized. Despite semantic analysis being single-threaded, generic
function instantiation can happen recursively, meaning that the hash
and equality functions for monomorphed_funcs entries are potentially
invoked for an uninitialized function.
This problem was mitigated by pre-setting the hash field on the newly
allocated function, however it did not solve the problem for hash
collisions in which case the equality function would be invoked. That it
was solved for hash() but not eql() explains why the problem was
difficult to observe. I tested this patch by temporarily sabotaging the
hash and making it always return 0.
This fix is centered on adding a new field to Module.Fn which is the one
checked by eql() and is populated pre-initialization.
closes #12643
|
|
This is problematic because in practice it depends on whether the
compiler backend supports it too, as evidenced by the TODO comment about
LLVM not supporting some architectures that in fact do support tail
calls.
Instead this logic is organized strategically in src/target.zig, part of
the internal compiler source code, and the behavior tests in question
duplicate some logic for deciding whether to proceed with the test.
The proper place to expose this flag is in `@import("builtin")` - the
generated source file - so that third party compilers can advertise
whether they support tail calls.
|
|
|
|
Closes #12656
|
|
Closes #12290
|
|
Closes #12679
|
|
Closes #4301
Closes #5692
Closes #6281
Closes #10786
Closes #11149
Closes #11776
|
|
|
|
different order
Closes #12667
|
|
Closes #12645
|
|
Closes #12376
|
|
Closes #12649
|
|
Closes #12651
|
|
Adds error for taking a non comptime parameter in a function returning a
comptime-only type but not when that type is dependent on a parameter.
Co-authored-by: Veikka Tuominen <git@vexu.eu>
|
|
We call `sema.resolveTypeFields` in order to get the fields of structs
and unions inserted into their data structures. If it isn't called, it
can happen that the fields of a type is queried before those fields are
inserted into (for instance) `Module.Union.fields`, which would result in
a wrong 'no field named' error.
Fixes: #12486
|
|
This fixes a bug exposed by cd1833044ab7505bc101c85f59889bd3ea3fac80
where a function type would be converted to generic_poison even after
being instantiated due to containing comptime only types.
This could also be fixed by just checking `is_generic_instantiation`
but this way also provides better type names.
Closes #12625
|
|
Previously, Zig had inconsistent semantics for an enum like this:
`enum(u8){zero = 0}`
Although in theory this can only hold one possible value, the tag
`zero`, Zig no longer will treat the type this way. It will do loads and
stores, as if the type has runtime bits.
Closes #12619
Tests passed locally:
* test-behavior
* test-cases
|
|
Stage2 fixes
|
|
stage2+stage1: remove type parameter from bit builtins
|
|
Closes #12622
|
|
Closes #12566
|
|
Closes #12621
|
|
Closes #12616
|
|
Closes #12573
|
|
Closes #12529
Closes #12511
Closes #6835
|
|
Closes #12570
|
|
Closes #12572
|
|
Closes #12537
|
|
Closes #12512
Closes #12513
|
|
Closes #12519
Closes #12505
|
|
The struct might be a top level struct in which case it might not have Zir.
Closes #12548
|
|
Closes #12514
|
|
Closes #12543
|
|
return type
|