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

[evopen]

Zig Version

0.12.0-dev.1684+ea4a07701

Zig Language Server Version

38a199813a1018305d4e85233950c2e6c8ca30a1

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 https://github.com/zigtools/zls/blob/35351a6ce059b6b0213b98c84793a94685f25441/src/Server.zig#L20

[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.

https://github.com/zigtools/zls/blob/35351a6ce059b6b0213b98c84793a94685f25441/src/DocumentStore.zig#L1081 calls https://github.com/zigtools/zls/blob/35351a6ce059b6b0213b98c84793a94685f25441/src/DocumentStore.zig#L1110 which calls https://github.com/zigtools/zls/blob/35351a6ce059b6b0213b98c84793a94685f25441/src/DocumentStore.zig#L975 which queues up a build runner run https://github.com/zigtools/zls/blob/35351a6ce059b6b0213b98c84793a94685f25441/src/DocumentStore.zig#L1008-L1010 which happens after https://github.com/zigtools/zls/blob/35351a6ce059b6b0213b98c84793a94685f25441/src/DocumentStore.zig#L1034 => 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.