Parser errors though code translates properly

[docbobo]

Thanks for this language server, exactly what was looking for right now.

I am trying to use this in nvim to compile some Amiga code targeting 68020 and am getting some Parser errors. Here's a test case, which compiles but produces that error:

    machine  68020
start:
    move.w    .base(pc,d7.l*2),d1
    end

[grahambates]

Hey, thanks for reporting this. Glad the project is useful to you!

The tree-sitter parser is currently missing support for some 68020+ addressing modes, including scaled indexes in this case. I'll make a start on implementing it.

[docbobo]

Should this already fix the reported snippet?

[grahambates]

Yeah it should. I tested it briefly but haven't tagged a new release yet.

[docbobo]

Hmm. Doesn't look that way here. I've uninstalled the old m68-lsp-server. Ran nvim, error (no m68k-lsp-server). Pulled the new stuff from git, installed it. Ran nvim, which now starts the new server. However, still got the parser error.

Now, given the other issue, I could fully understand that you are doubting my sanity - I am doing that as well...

Do I need a specific configuration for that to work?

[docbobo]

Tried on a second machine. Same, same. So at least I am again convinced that I didn't screw things up completely.

[grahambates]

I must have screwed something up then! I'll do some proper testing and sort it tonight.

[grahambates]

Just to check how you're linking the nvim lsp config up to your local version rather than expecting a global npm package, the way I do it is to override the cmd option to specify the full path of the script:

lspconfig.m68k.setup {
  cmd = {'node', '/Users/batesgw1/m68k-lsp/server/cli.js', '--stdio'},
   ...

Make sure you run npm install and npm run build in your local checkout.

You probably already know all this but I'm tearing my hair out a bit because I'm still seeing that the latest commit resolves the issue for me! I'll keep investigating.

[docbobo]

I had completely uninstalled the global variant. If I am doing a ps, I can see the following:

docbobo    12592  2.8  0.5 2735184 82000 pts/4   Sl+  20:43   0:00 node --no-experimental-fetch /home/docbobo/.local/bin/m68k-lsp-server --stdio

It does run however, if I start it with the cmd from above.... So apparently your fix did work - thanks! Now I need to figure out why it didn't work the other way...

[docbobo]

Oh - BTW. That executable above was a link to /home/docbobo/Sources/github.com/m68k-lsp/client/node_modules/.bin/m68k-lsp-server

So both should be running code from the same server directory. Or shouldn't they?

[grahambates]

No, that's your problem right there. The vscode client still has a dependency on the latest server npm package, which as I haven't make a release yet will still be v0.8.0 and won't include the fix. To test the unreleased server code you need reference it like I described. cli.js is effectively the local filename of the executable.

Mystery solved I think!

[grahambates]

I've released v0.8.1 including the fix so you should be able to just install the latest package now. Let me know if you're still having any problems. Thanks again for reporting this.

Just to warn you, I'm aware that there are other 68020+ addressing modes that will currently cause a parser error including base and outer displacements. I've created a separate issue on tree-sitter-m68k and I'll look at this when I get some time.