diff options
| author | mlugg <mlugg@mlugg.co.uk> | 2024-12-23 20:39:19 +0000 |
|---|---|---|
| committer | mlugg <mlugg@mlugg.co.uk> | 2024-12-24 02:18:41 +0000 |
| commit | 3afda4322c34dedc2319701fdfac3505c8d311e9 (patch) | |
| tree | 467873c408750cb4223f3ccf31775e42ec9fbd5c /src/codegen.zig | |
| parent | 40aafcd6a85d3c517f445f17149c17523c832420 (diff) | |
| download | zig-3afda4322c34dedc2319701fdfac3505c8d311e9.tar.gz zig-3afda4322c34dedc2319701fdfac3505c8d311e9.zip | |
compiler: analyze type and value of global declaration separately
This commit separates semantic analysis of the annotated type vs value
of a global declaration, therefore allowing recursive and mutually
recursive values to be declared.
Every `Nav` which undergoes analysis now has *two* corresponding
`AnalUnit`s: `.{ .nav_val = n }` and `.{ .nav_ty = n }`. The `nav_val`
unit is responsible for *fully resolving* the `Nav`: determining its
value, linksection, addrspace, etc. The `nav_ty` unit, on the other
hand, resolves only the information necessary to construct a *pointer*
to the `Nav`: its type, addrspace, etc. (It does also analyze its
linksection, but that could be moved to `nav_val` I think; it doesn't
make any difference).
Analyzing a `nav_ty` for a declaration with no type annotation will just
mark a dependency on the `nav_val`, analyze it, and finish. Conversely,
analyzing a `nav_val` for a declaration *with* a type annotation will
first mark a dependency on the `nav_ty` and analyze it, using this as
the result type when evaluating the value body.
The `nav_val` and `nav_ty` units always have references to one another:
so, if a `Nav`'s type is referenced, its value implicitly is too, and
vice versa. However, these dependencies are trivial, so, to save memory,
are only known implicitly by logic in `resolveReferences`.
In general, analyzing ZIR `decl_val` will only analyze `nav_ty` of the
corresponding `Nav`. There are two exceptions to this. If the
declaration is an `extern` declaration, then we immediately ensure the
`Nav` value is resolved (which doesn't actually require any more
analysis, since such a declaration has no value body anyway).
Additionally, if the resolved type has type tag `.@"fn"`, we again
immediately resolve the `Nav` value. The latter restriction is in place
for two reasons:
* Functions are special, in that their externs are allowed to trivially
alias; i.e. with a declaration `extern fn foo(...)`, you can write
`const bar = foo;`. This is not allowed for non-function externs, and
it means that function types are the only place where it is possible
for a declaration `Nav` to have a `.@"extern"` value without actually
being declared `extern`. We need to identify this situation
immediately so that the `decl_ref` can create a pointer to the *real*
extern `Nav`, not this alias.
* In certain situations, such as taking a pointer to a `Nav`, Sema needs
to queue analysis of a runtime function if the value is a function. To
do this, the function value needs to be known, so we need to resolve
the value immediately upon `&foo` where `foo` is a function.
This restriction is simple to codify into the eventual language
specification, and doesn't limit the utility of this feature in
practice.
A consequence of this commit is that codegen and linking logic needs to
be more careful when looking at `Nav`s. In general:
* When `updateNav` or `updateFunc` is called, it is safe to assume that
the `Nav` being updated (the owner `Nav` for `updateFunc`) is fully
resolved.
* Any `Nav` whose value is/will be an `@"extern"` or a function is fully
resolved; see `Nav.getExtern` for a helper for a common case here.
* Any other `Nav` may only have its type resolved.
This didn't seem to be too tricky to satisfy in any of the existing
codegen/linker backends.
Resolves: #131
Diffstat (limited to 'src/codegen.zig')
| -rw-r--r-- | src/codegen.zig | 17 |
1 files changed, 9 insertions, 8 deletions
diff --git a/src/codegen.zig b/src/codegen.zig index 898629d69b..7b607f13f9 100644 --- a/src/codegen.zig +++ b/src/codegen.zig @@ -817,7 +817,7 @@ fn genNavRef( pt: Zcu.PerThread, src_loc: Zcu.LazySrcLoc, val: Value, - ref_nav_index: InternPool.Nav.Index, + nav_index: InternPool.Nav.Index, target: std.Target, ) CodeGenError!GenResult { const zcu = pt.zcu; @@ -851,14 +851,15 @@ fn genNavRef( } } - const nav_index, const is_extern, const lib_name, const is_threadlocal = switch (ip.indexToKey(zcu.navValue(ref_nav_index).toIntern())) { - .func => |func| .{ func.owner_nav, false, .none, false }, - .variable => |variable| .{ variable.owner_nav, false, .none, variable.is_threadlocal }, - .@"extern" => |@"extern"| .{ @"extern".owner_nav, true, @"extern".lib_name, @"extern".is_threadlocal }, - else => .{ ref_nav_index, false, .none, false }, - }; + const nav = ip.getNav(nav_index); + + const is_extern, const lib_name, const is_threadlocal = if (nav.getExtern(ip)) |e| + .{ true, e.lib_name, e.is_threadlocal } + else + .{ false, .none, nav.isThreadlocal(ip) }; + const single_threaded = zcu.navFileScope(nav_index).mod.single_threaded; - const name = ip.getNav(nav_index).name; + const name = nav.name; if (lf.cast(.elf)) |elf_file| { const zo = elf_file.zigObjectPtr().?; if (is_extern) { |
