Motoko Language Server not finding "Problems"

Developers Language Support
1

Has anyone run across an issue where the motoko language server won’t run and add errors and warnings to the “Problems” tab in VS Code?

When I start my current project from a clone it asks me what motoko file I want to debug and I select the project I’ve set up to reference all my other libraries in the project. In the output tab I get some messages that it can’t find the canister ids. I then start dfx and run dfx canister create --all. This creates the canister_id file in .dfx. Now when I try to manually re-start the service and select my project I get the Motoko LS initialized, but nothing shows up in the Output and nothing seems to show up in the Problems tab even though building the projects definitely shows warnings and errors.

I’d love to figure out what is going on, because having to manually build each time is a real pain.

2

I was able to load up the extension in vs code in debug mode, but after client.start(); gets called, I don’t know what to grab a hold of to inspect or watch to see what is happening. I’m guessing it does something with dfx _language-service, but when I try running that from the terminal with force tty it just kind of sits there…I don’t know how to poke it with a stick.

Looks like I need to call it with some json rpc calls? What is the port it operates on? What command would I send it to make it try to build a project and return back any errors/warnings? Maybe I can figure out where things are going wrong. dfx version 11.1

3

I think it produces output in a log file, but I don’t know where off hand. It might even be configurable from Vscode settings, but I’m not sure.

In the past, IIRC, I’ve found that errors are only reported after modifying and saving a file. Does that not work either?

4

Unfortunately no. It seems to be an issue across my system as even my old projects where it was working fine are now not responding to file saves.

…Ok…cool…I found the log files Developer: Open Extensions Logs Folder from the command pallet.

I can convert that the trade is sending notifications… I see

5-Motoko language server.log

[Trace - 6:12:19 AM] Sending notification 'textDocument/didSave'.
Params: {
    "textDocument": {
        "uri": "file:///Users/afat/Dropbox/development/origyn/code/origyn_nft/src/tests/all_ref.mo"
    },
    "text": "....my file was heree...."
}

But do I don’t ever see a response come back for anything except

[Trace - 6:14:51 AM] Sending request 'textDocument/hover - (4)'.
Params: {
    "textDocument": {
        "uri": "file:///Users/afat/Dropbox/development/origyn/code/origyn_nft/src/tests/all_ref.mo"
    },
    "position": {
        "line": 29,
        "character": 27
    }
}

[Trace - 6:14:51 AM] Received response 'textDocument/hover - (4)' in 2ms.

No result returned.
5

I’m just trying to document how this stuff works…

It looks like sdk/language_service.rs at master · dfinity/sdk · GitHub doesn’t really have many log messages…but really it is just calling mo-ide.

mo-ide seems to have a --debug option that I can run manually, but the ide doesn’t talk to this instance.

I tried adding --debug to the standalone arguments in the extension settings, but I don’t think this is doing anything since this is a dfx project.

6

Downgrading my DFX version to 10.1 in my dfx.json file fixed this. Other devs are reporting that 11.0 seems to work, but 11.1 and 11.2 do not. @claudio @rvanasa

1 Like
7

Oh interesting, did some Motoko last few days and also had no error detected in VS Code. Thought it was me since I am no VS code expert but, maybe not then.

I use dfx v0.11.2. That’s my project repo (if someone needs one to debug).

8

Which version of the VS Code extension are you using?

The VS Marketplace listing is over a year out of date (fixing this just became a top-priority ticket in our IT department, and we’re trying to resolve this as soon as possible).

A few days ago, we released v0.4.1 on GitHub, which includes a fallback language server for environments without a local dfx installation. You can try unchecking the “Legacy Dfx Support” setting (and then restarting the language server) in case this works as a short-term solution.

Let me know if you continue running into issues on the latest version, and I’ll do my best to replicate on my end so we can fix this for everyone.

1 Like
9

I have installed this updated version and I’m still having issues.

I even downloaded peterparker’s code and opened it in VSCode. I put in an Array.append command and saved…nothing showed up in the problems tab.

log file is below…note that responses are not coming back:

1 Like
10

Replicated in the papyrs/ic repository. Unchecking the “Motoko: Legacy Dfx Support” option in the VS Code settings works for me, and I’ll see if there’s a way to quickly fix the issue with the OCaml language server.

1 Like
11

Unchecking this makes it run on my other project, but it doesn’t seem to be finding vessel includes. It complains that the package is not defined.

Has vessel been updated or changed?

Interestingly vessel verify fails:

Failed to run "moc" "--check" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/Nat64.mo" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/RBTree.mo" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/Option.mo" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/Heap.mo" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/List.mo" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/Error.mo" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/Deque.mo" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/TrieSet.mo" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/None.mo" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/Time.mo" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/Iter.mo" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/Principal.mo" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/Nat8.mo" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/Random.mo" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/ExperimentalInternetComputer.mo" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/Nat.mo" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/Char.mo" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/Order.mo" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/Float.mo" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/Bool.mo" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/TrieMap.mo" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/Int64.mo" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/Int16.mo" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/Int32.mo" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/Stack.mo" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/Debug.mo" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/Prelude.mo" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/Buffer.mo" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/Text.mo" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/ExperimentalCycles.mo" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/Hash.mo" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/AssocList.mo" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/Result.mo" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/CertifiedData.mo" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/Func.mo" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/IterType.mo" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/HashMap.mo" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/ExperimentalStableMemory.mo" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/Int8.mo" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/Trie.mo" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/Int.mo" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/Blob.mo" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/Array.mo" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/Nat16.mo" ".vessel/base/494824a2787aee24ab4a5888aa519deb05ecfd60/src/Nat32.mo"
Error: Failed to verify: ["base"]
1 Like
12

It’s possible that the issue is related to dfx being unable to resolve canister:* import aliases, which is causing some sort of unhandled error in the OCaml LSP.

A few additional debugging questions:

  • Does running dfx deploy (and then restarting the OCaml language server) change anything?
  • What happens if you run vessel install --force base? This is a new feature, so if this works but doesn’t fix the issue, there might be some regression that I’ll fix as soon as possible.

The Vessel resolution errors are expected, since the new LSP only supports the base library at the moment. I’m working on adding Vessel support right now, since this is something I can fix in the extension itself (compared to waiting for the next version of dfx).

Thanks for bearing with us. There’s a lot of technical debt to clean up in Vessel and the VS Code extension, so there might be a few bumps along the road as we bring these projects out of hibernation.

1 Like
13

Thanks! Yep worked out. Had to restart VS code though. Just restarting the language server after having updated the setting did not work out for me.

1 Like
14

Hooray! Glad this worked as a short-term solution.

As a general announcement, the extension is now fully up-to-date on VS Marketplace! Feel free to replace the GitHub version so you can automatically receive the upcoming bugfixes / improvements for the new LSP.

2 Likes
15

What version of vessel is everyone on? I don’t have --force.

16

No worries; that’s the only recent addition to Vessel, so you’ll only need to upgrade if you want the ability to force-reinstall packages.

We just released v0.4.2 of the Motoko extension, which includes Vessel package support for the new LSP and several bugfixes for Windows users.

GitHub issue tracking the missing errors / warnings:

Let me know if the Vessel integration works for you, and if you run into anything else with the new LSP.

More improvements coming soon (tomorrow).

1 Like
17

Things are working much better now. The change now is that the language server seems to only evaluate open files. Before I had to specify which canister I wanted it to evaluate and then it would cascade and find issues with files even if I hadn’t opened them up.

Thanks for the quick turn around on these!

1 Like
18

Hello rvanasa! I had such a problem and I was not using Vessel.Could you help me to fix it?

1663817535533
1663817535533824×404 93.6 KB

1 Like
19

Despite these error messages, I can still run my project

20

I’d be happy to take a look. Would you mind sending me a direct message with everything from the “Output” → “Motoko Language Server” logs?