Trying asm-lsp with x86 + Nasm

[ldelossa]

Hey.

I was trying out your LSP but I'm getting a lot of false diagnostics.

I created a project local config which uses the NASM compiler with x86 assembler language.

Here is what I'm getting:

It thinks the push instructions are wrong. Any idea here? My config is on the right

[ldelossa]

Ah, okay I needed to set compiler = nasm to get the corrected diagnostics.

It's a bit odd that we need to save the buffer for diagnostics to update, I think usually the LSP would get file changed updates as you make changes. Just a heads up.

[WillLillis]

Ah, okay I needed to set compiler = nasm to get the corrected diagnostics.

Glad you got it figured out! :)

It's a bit odd that we need to save the buffer for diagnostics to update, I think usually the LSP would get file changed updates as you make changes. Just a heads up.

This is definitely something I'd like to fix at some point, but I don't see a clear path forward currently. We provide diagnostics by invoking the provided compiler/assembler on the source file in a child process, parsing the output, and displaying those as diagnostics. This approach allows the user to use existing build processes (i.e. the compile_commands.json format) with whatever tooling they want (so long as it's installed on their system). The obvious downside is that we can only generate diagnostics for content written to disk. In order to provide diagnostics for changes that haven't been committed to disk, we could:

• Create and maintain Rust bindings to any number of desired compilers/assemblers on a number of target architectures. I don't feel confident in my ability to take on this level of work.
  • It looks like clang has Rust bindings. However, this would require us to statically link to clang and LLVM, which would balloon compile times and binary size.
• Create a "shadow" version of the project in a temporary directory, commit every edit the user makes to this copy, and generate diagnostics off of the shadow copy.
  • I'd be open to spending some time on this as an experimental feature (after I've cleared out some of the existing feature requests), but I expect interacting with the filesystem that much would significantly increase the server's latency.
• Some other approach I haven't thought of yet

[ldelossa]

I see.

Would you need a shadow copy of the entire project? Or is each asm file a single translation unit?

Lets say the editor open only two files. The LSP gets an event that those two files are opened, at which point you can load them into memory. You should get file change events from there, and you can concurrently update the inmemory rep of the file and then pipe those bits out to the stdin of the compiler being used in real time? Im probably missing something tho.

[WillLillis]

I think that approach could work pretty well. Naively I think there may be some edge cases where a user's build commands might depend on the larger project structure. I think it still would make sense to give this a shot, though. I'll open up a tracking issue later today.

[ldelossa]

Hmm, yeah. Clangd config basically lets the user modify build args in the fly (both additions and removals). Not sure if that would be helpful here or not, but there is a precedent of doing that with clang.

[WillLillis]

Currently we source build areas from the server's config file (.asm-lsp.toml) as well as any compile_flags.txt/ compile_commands.json files in the project's root/ root build directory. These files get read at startup time and currently aren't editable without a restart. I would really like to add this kind of thing to the project, but honestly I haven't looked into it too closely yet. I'm not sure if we'd have to implement our own file watching for non-source files, or if the lsp spec has something we can hook into.

As an aside, my first pass on the diagnostics-related code has proven to be rather buggy. I think a small rewrite as part of the improvements you outlined would go a long ways for correctness/ maintenance burden.