The container we want to get the fields from might not be declared in the
same file as the block we are analyzing, so we should get the AST from
the decl's file instead.
The enum we want to get the fields from might not be declared in the
same file as the block we are analyzing, so we should get the AST from
the decl's file instead.
Closes#12950.
cmpxchg_weak and cmpxchg_strong are not very common; demote them to
extended operations to make some headroom.
This commit does not change any behavior, only memory layout of the
compiler.
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#12433Closes#12530Closes#12593
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.
