(include_subdirs qualified) leads to some spurious ocaml-lsp errors

[tjdevries]

Expected Behavior

No errors from ocaml-lsp (project successfully compiled), for example this succeeds.

❯ dune build @check   

(You can see the code here: https://github.com/tjdevries/thereactagen/blob/2dfcfc8b7473f771f3f14927fc75c90bb3609131/lib/models/dune )

Actual Behavior

(Same error in .ml file and .mli file for lib/models/storage/custom.mli

Reproduction

• PR with a reproducing test:

1. I'm not sure how to reproduce outside of the project, but pretty sure it's from the qualified usage. I linked the

Specifications

• Version of dune (output of dune --version): 3.9.1
• Version of ocaml (output of ocamlc --version): 5.0.0
• Operating system (distribution and version): Pop OS

(cc @anmonteiro, i can give more info if needed)

[Alizter]

Hi, your explanation of the reproduction looks a bit cut-off; do you have any more information? Particularly I am not sure I understood if the error is coming from ocamllsp or dune? If it is possible, could you create a minimal example of the issue, maybe inside a cram test?

p.s. love your videos :)

[tjdevries]

Sorry! I didn't see this reply (and so happy to hear you like the videos!!)

This was only from the LSP, not from dune. Dune was able to successfully build, but @anmonteiro said this would be a better spot to leave an issue (or at least, mentioned it in passing on stream). I can try and make a smaller repro at some point

[psb]

I've come across the same problem. I posted this message about it in the Discord:

I've been working on a NextJS app which uses folders for routing. Some have suggested adding a dune file per folder and some have suggested using the stanza (include_subdirs qualified) in a parent folder so that you don't have to add a dune file for every route, which would get tedious quickly if you have lots of routes. I have tried both ways, and using (include_subdirs qualified) gives me red squiggles in my editor but the app compiles fine (no dune errors), and adding dune files to every route folder gets rid of the red squiggles.

With (include_subdirs qualified):

With dune files in each folder:

The code to reproduce the error is in this branch.

[jake-87]

Also happening to me.
See this branch, lib/ for another replication: Khasmc branch.
Dune 3.10.X, opam version 2.1.5 .
I can also confirm with fairly high confidence that it is the usage of qualified - this emerged immediately after I moved said project over to include_subdirs qualified.

I happen to be getting a message at the very top of the file:
Unbound module Frontend
despite the fact that the cm* files are being generated in _build/install/default/<project specific stuff>/khasmc__Frontend.cm{i,x,t}

Out of curiosity, @psb, what's in those dune folders? For me, just empty dune folders doesn't seem to work - I'd like to see if your solution works for me too.

[rgrinberg]

A great way to move this forward is for someone to create a minimal reproducible test case demonstrating the issue and add it to our test suite. Although we can't test ocamllsp, we do have tests that demonstrate we output the correct configuration for ocamllsp and merlin. One could use those to point out where the configuration is wrong.

[jake-87]

@rgrinberg Apologies, I don't know your preferred style for adding tests and whatnot, but this is an MRE for the issue as far as I can tell: ocamllsp MRE. Code compiles fine, warnings in the editor in lib/one/onefile.ml. This is with a completely fresh install of ocamllsp and dune, so I don't think it's outside config or factors causing the issue.

[psb]

Also happening to me. See this branch, lib/ for another replication: Khasmc branch. Dune 3.10.X, opam version 2.1.5 . I can also confirm with fairly high confidence that it is the usage of qualified - this emerged immediately after I moved said project over to include_subdirs qualified.

I happen to be getting a message at the very top of the file: Unbound module Frontend despite the fact that the cm* files are being generated in _build/install/default/<project specific stuff>/khasmc__Frontend.cm{i,x,t}

Out of curiosity, @psb, what's in those dune folders? For me, just empty dune folders doesn't seem to work - I'd like to see if your solution works for me too.

They are just library definitions, e.g.,:

(library
  (name joke_route)
  ...

I then include this library in the src/app/api/dune file:

(library
  (name api)
  (libraries joke_route)
  ...

[jake-87]

Right, I see. Unfortunately that doesn't work for my usecase, but it does seem to work if your directories aren't codependent.
Much appreciated nonetheless.

[jake-87]

@rgrinberg Apologies if I wasn't clear earlier - I'm more then happy to create a testcase for dune, but I'm not sure what I'm looking for in regard to dune's generated files being correct. I've tried looking through what files are accessed while ocamllsp or merlin are running (It seems to affect both), but without knowing the underlying formats, I'm not getting far. I'd much appreciate if you would be able to point me to where I might find the documentation for these formats that dune produces, so that I might figure out what's going on and try to make a testcase?

[Tchou]

Here is a repro case. Note, that there is nothing wrong with the invocation of dune build, but it seems that either the information that gets sent to ocamllsp is wrong or ocamllsp itself is buggy in that respect (and I don't know how to test this later part).

$ tree dune_test_qualified 
dune_test_qualified
├── a
│   ├── b
│   │   ├── mod_b1.ml
│   │   └── mod_b2.ml
│   ├── dune
│   └── mod_a.ml
└── dune-project

3 directories, 5 files
$ cat dune_test_qualified/dune-project

(lang dune 3.7)

$ cat dune_test_qualified/a/dune

(include_subdirs qualified)
(library
 (name a))

$ cat dune_test_qualified/a/mod_a.ml

let f () = B.Mod_b1.f ()

$ cat dune_test_qualified/a/b/mod_b1.ml

let f () = Mod_b2.T.f ()

$ cat dune_test_qualified/a/b/mod_b2.ml

module T =
struct
  let f () = ()
end

Now doing dune build works. But after that, opening the project is VSCode gives:

So it seems that in the context of the mod_b2.ml tab, the scope (for ocamllsp) is the toplevel module A. And indeed, if I replace with the full path, that is:

let f () = B.Mod_b2.T.f ()

the error disappears in VSCode and f() gets resolved to the correct identifier (e.g. if I run Go to Definition the editor jumps to the definition of f in T in mod_b2.ml), but obviously this is wrong and dune build signals a cyclic dependency:

Error: Module Mod_b1 in directory _build/default/a depends on B.
This doesn't make sense to me.

I can upload a tarball somewhere to ease the reproduction if needed (but the example here is pretty small).

[AdamBrodzinski]

I'm running into this as well. I've pushed a minimal repro here:
https://github.com/AdamBrodzinski/dune-issue-8297-repro

• dune build (no issues building)
• vist bin/utils/calc.ml in an editor with ocaml lsp

[rgrinberg]

Should be fixed in #9659. Thanks for the detailed reports everyone.