hide dune prefix in type annotations

etanter commented 4 years ago

Hi, I'm 100% new to VSCode (let alone VSCode-OCaml), so sorry if that's trivial. For some reason, all the type annotations that are inferred have some dune-related prefix: At some point, I had the same problem in the hover type info, but after a server restart, it disappeared and looks fine:

How can I hide the dune-related prefixes in the inferred type annotations?

thanks!

rgrinberg commented 4 years ago

Can you post the .merlin file generated in the directory where this source file lives?

etanter commented 4 years ago

» more .merlin                                                                   [15:49:04]
EXCLUDE_QUERY_DIR
B /Users/etanter/.opam/4.11.0/lib/alcotest
B /Users/etanter/.opam/4.11.0/lib/alcotest/engine
B /Users/etanter/.opam/4.11.0/lib/astring
B /Users/etanter/.opam/4.11.0/lib/bytes
B /Users/etanter/.opam/4.11.0/lib/cmdliner
B /Users/etanter/.opam/4.11.0/lib/containers
B /Users/etanter/.opam/4.11.0/lib/containers/monomorphic
B /Users/etanter/.opam/4.11.0/lib/containers/unix
B /Users/etanter/.opam/4.11.0/lib/fmt
B /Users/etanter/.opam/4.11.0/lib/ocaml
B /Users/etanter/.opam/4.11.0/lib/re
B /Users/etanter/.opam/4.11.0/lib/seq
B /Users/etanter/.opam/4.11.0/lib/stdlib-shims
B /Users/etanter/.opam/4.11.0/lib/uchar
B /Users/etanter/.opam/4.11.0/lib/uuidm
B /Users/etanter/.opam/4.11.0/lib/uutf
B ../_build/default/TestLib/.testLib.objs/byte
B ../_build/default/gc/.main_compile.eobjs/byte
S /Users/etanter/.opam/4.11.0/lib/alcotest
S /Users/etanter/.opam/4.11.0/lib/alcotest/engine
S /Users/etanter/.opam/4.11.0/lib/astring
S /Users/etanter/.opam/4.11.0/lib/bytes
S /Users/etanter/.opam/4.11.0/lib/cmdliner
S /Users/etanter/.opam/4.11.0/lib/containers
S /Users/etanter/.opam/4.11.0/lib/containers/monomorphic
S /Users/etanter/.opam/4.11.0/lib/containers/unix
S /Users/etanter/.opam/4.11.0/lib/fmt
S /Users/etanter/.opam/4.11.0/lib/ocaml
S /Users/etanter/.opam/4.11.0/lib/re
S /Users/etanter/.opam/4.11.0/lib/seq
S /Users/etanter/.opam/4.11.0/lib/stdlib-shims
S /Users/etanter/.opam/4.11.0/lib/uchar
S /Users/etanter/.opam/4.11.0/lib/uuidm
S /Users/etanter/.opam/4.11.0/lib/uutf
S ../TestLib
S .
FLG -open Dune__exe -w @1..3@5..28@30..39@43@46..47@49..57@61..62-40 -strict-sequence -strict-formats -short-paths -keep-locs -warn-error -A

rgrinberg commented 4 years ago

No clue why the prefixes remain. The FLG -open Dune__exe and -short-paths is supposed to take care of this. Perhaps @voodoos knows?

etanter commented 4 years ago

meanwhile, is there a setting to hide these inferred annotations?

rgrinberg commented 4 years ago

You can disable code lenses for OCaml sources I suppose. On Aug 28, 2020, 12:52 PM -0700, Éric Tanter notifications@github.com, wrote:

meanwhile, is there a setting to hide these inferred annotations? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

etanter commented 4 years ago

I couldn't find the ocaml-specific setting for that, only the global editor.codeLens. When turning it off, type annotations indeed disappear and the rest (type info when hovering, peeking defs, etc.) still works fine. Not ideal, but ok meanwhile. Thanks!

rgrinberg commented 4 years ago

Perhaps this should work:

"[ocaml]": {
          "editor.codeLens": false
}

in your settings.json.

etanter commented 4 years ago

one more bit of info: the problem manifests for types that are brought in scope of the file through an open Abc directive (where abc.ml defines the corresponding types, and there's no abc.mli file).

FYI I've tried deleting the build files and the .merlin file, no change

etanter commented 4 years ago

the problem also manifests in the "outline":

voodoos commented 4 years ago

I do not encounter this problem with OCaml 4.11.0, dune 2.7.0, latest vscodium and latest ocaml-lsp-server.

Dit you check that the OCaml Platform extension uses the correct switch ?

etanter commented 4 years ago

yes:

dune version is 2.7.0, vscode is just updated, and ocamllsp is 1.0.0-7-g0d8bd3b. In case it may matter, I'm on macOS (10.15)

etanter commented 4 years ago

Ok, here's a minimal setup that manifests the problem:

dune:

(executable
(name main)
(modules lib main))

lib.ml:
```
type test = A of int | B of string
```
main.ml:
```
open Lib
```

let f (t : test) = match t with | A n -> string_of_int n | B s -> s

let () = print_endline (f @@ A 1)


see the type annotation for `f`:
<img width="217" alt="Screen Shot 2020-08-29 at 7 36 35 AM" src="https://user-images.githubusercontent.com/1315554/91635913-6081b400-e9ca-11ea-9988-5ed51095ff9a.png">

files: [Archive.zip](https://github.com/ocamllabs/vscode-ocaml-platform/files/5145151/Archive.zip)

The generated `.merlin` file:

» more .merlin [7:38:30] EXCLUDE_QUERY_DIR B _build/default/.main.eobjs/byte S . FLG -open Dune__exe -w @1..3@5..28@30..39@43@46..47@49..57@61..62-40 -strict-sequence -strict-formats -short-paths -keep-locs

voodoos commented 4 years ago

I was able to reproduce, thanks. Code lens is indeed showing Dune__exe prefixes while hovering on f does not. And merlin also gives the right answer:

I don't know how CodeLens is implemented in OCaml LSP ?

etanter commented 4 years ago

I tried another organization of the code to see if that was happening as well:

subfolder tool, with lib.ml as above, and f.ml which only has the function f defined. The dune file makes tool a library
main.ml in the root, being the executable, using the Tool library. In main.ml I create an alias let g = f.

Interestingly, the codelens in main.ml shows the proper type for g (Tool.Lib.test → string) --although arguably, since Tool.Lib has been opened, the prefix should not be there either---, while in the f.ml file, it shows up Dune__exe.Lib.test → string instead of test → string:

note sure if that helps in any way to track the problem...

rgrinberg commented 4 years ago

I don't know how CodeLens is implemented in OCaml LSP ?

It's just merlin's Outline query.

etanter commented 4 years ago

in the example above, do we agree that in main.ml it should display test → string for g, considering the prior open Tool.Lib?

voodoos commented 4 years ago

It is in fact an already known issue of Merlin: https://github.com/ocaml/merlin/issues/971

etanter commented 4 years ago

thanks for tracking down the problem to a Merlin bug. Hopefully it gets addressed there soon!

etanter commented 4 years ago

FYI, there's an approved PR that fixes the problem in Merlin https://github.com/ocaml/merlin/pull/1166

rgrinberg commented 4 years ago

Indeed. I will cherry pick it ocamllsp as soon as it is merged.

ocamllabs / vscode-ocaml-platform

hide dune prefix in type annotations #341