more accurately model how build system modules work #2510
Conversation
Techatrix
force-pushed
the
techatrix/model-build-system
branch
2 times, most recently
from
725af1e to
31481f3
Compare
fyi - it seems that can't really be relied upon https://gist.github.com/dotcarmen/7f186613f1f839427a839c33306af9dd <- the output is: what happens when a module is imported by multiple roots? i think it's best to not resolve |
The completions are ordered like this: - the `std` module - the `builtin` module - the `root` module - other modules - files This is the same as the source.organizeImports code action.
This allows the build runner check to handle paths that are in the local or global zig cache.
Techatrix
force-pushed
the
techatrix/model-build-system
branch
from
31481f3 to
fa96d31
Compare
I turns out that I have misunderstood the semantic of
Resolve it to all of them. ZLS has something called "either types" that can be used to represent a type that can be one of a given set of types but it's unknown which one it will be. So const root = switch (unknown) {
0 => @import("main.zig"),
1 => @import("main2.zig"),
};If complete example: https://gist.github.com/Techatrix/80b625e5965ca6177ff4360713ffded3 |
|
i've been running this build pretty successfully, however, as of this only occurred after i added |
| const gop_import = try gop.value_ptr.import_table.map.getOrPut(allocator, name); | ||
| // This does not account for the possibility of collisions (i.e. modules with same root source file import different modules under the same name). | ||
| if (!gop_import.found_existing) { | ||
| gop_import.value_ptr.* = try std.fs.path.resolve(allocator, &.{ cwd, import.root_source_file.?.getPath2(import.owner, null) }); |
There was a problem hiding this comment.
this is the line that results in the aforementioned panic
ZLS had an inaccurate view of how modules work in the build system. It would previously merge every module in the entire build graph into one single module which can easily lead to incorrect results in any non trivial project that contains multiple modules. This PR will keep track of each individual module so that analysis can differentiate between them just like how the compiler does it.
Some examples of what has been improved:
@import("root")now actually figures out in which module a given file is in.@importwill only show the modules that have been directly added to the module that the current file belongs to@import("some_name")will resolve the correct module if there are multiple modules that have imported different modules with"some_name"as their name.One issue this PR doesn't fully address is when there are multiple modules with the same root source file that have conflicting definitions. This is only achievable using multiple compilation units because Zig fortunately disallows sharing a root source file within a single compilation unit.
Related PR #2308