module in build.zig is not considered as a BuildConfig packages

[evopen]

Zig Version

0.12.0-dev.1684+ea4a07701

Zig Language Server Version

38a1998

Steps to Reproduce

I'm using nested structure in a monorepo which contains multiple Zig packages (multiple build.zig.zon and build.zig) and there is a build.zig in the root directory.
A package A in the subdirectory contains a test target with a associated test step and a bare module without a step. Another package B reference A in its zon file and build.zig. Zig builds package B fine.

First I thought I was the build.zig discovery mechanism introduced in #688. The root build.zig does not reference package A. Package A's build.zig does but the build runner fails to find them, because

1. The package is referenced by the addTest of package A which is named root in build runner and uriAssociatedWithBuild consider uri unmatched.
2. A bare module added with b.addModule is not deemed as a package in build runner.

ZLS in this case choose the root build.zig as the associated build file for package A and everything falls apart.

A simple workaround in my case would be to change root build.zig to a normal zig file and run with zig run.

But the root cause is the module handling I think. Did I miss something?

Expected Behavior

ZLS finds the correct module when parsing package B.

Actual Behavior

ZLS cannot parse the @import statement resulting in an unknown type.

[llogick]

Hi,

Is there a repository I can checkout? I'd like to see the build.zig files and where the expected @import is.

For reference (not saying it's the same) :
here's a package that has no steps and exports a module
https://github.com/ziglibs/known-folders/blob/master/build.zig
zls is able to resolve the import

zls/src/Server.zig

Line 20 in 35351a6

const known_folders = @import("known-folders");

[evopen]

Hi, I've created a simple reproduce repo. https://github.com/evopen/zls-issue-1629.
The gist is, in /myapp/src/main.zig, const mylib is unknown type.
If you mv /build.zig to /meow.zig, ZLS resolve mylib in myapp correctly.

My thought is

1. ZLS did not recognize /mylib/build.zig as a valid build.zig to mylib module, because the module is named root in the build runner which doesn't match the name mylib.
2. And ZLS resolve myapp's dependency mylib to use /build.zig, because build.zig higher in filesystem tree takes precedence.

In your example, known-folders/build.zig is the sole build.zig in known-folders' filesystem hierarchy. ZLS can only associate this build.zig to the module.

[llogick]

build.zig discovery logic aside, this seems to be a timing issue - try opening the myapp/build.zig first then (maybe wait a few seconds) the myapp/src/main.zig.

zls/src/DocumentStore.zig

Line 1081 in 35351a6

fn createDocument(self: *DocumentStore, uri: Uri, text: [:0]const u8, open: bool) error{OutOfMemory}!Handle {

calls

zls/src/DocumentStore.zig

Line 1110 in 35351a6

const build_file = self.getOrLoadBuildFile(build_file_uri) orelse continue;

which calls

zls/src/DocumentStore.zig

Line 975 in 35351a6

fn createBuildFile(self: *DocumentStore, uri: Uri) error{OutOfMemory}!BuildFile {

which queues up a build runner run

zls/src/DocumentStore.zig

Lines 1008 to 1010 in 35351a6

	server.job_queue.writeItemAssumeCapacity(.{
	.load_build_configuration = try server.allocator.dupe(u8, build_file.uri),
	});

which happens after

zls/src/DocumentStore.zig

Line 1034 in 35351a6

_ = try build_file.collectBuildConfigPackageUris(self.allocator, &package_uris);

=> package_uris.items.len == 0 in most cases.

[evopen]

Ok I think you are right. Build Config is read before write. And build file walker walks from root towards the file of interest, I got it wrong. Sorry for drawing the wrong conclusion.