bug(vfs): cairo-language-server unable to convert URI to filepath

[mkaput]

@0xLucqs commented on 30.08.2023, 12:24:07:

Bug Report

Cairo version:

v2.2.0

Current behavior:

When trying to jump to the definition of a function or a trait defined with the #[generate_trait] macro the language server fails and outputs unable to convert URI to filepath: vfs://201/generate_trait.cairo

Expected behavior:

It shouldn't fail and jump to the definition.

Steps to reproduce:

Related code:

use bar::{A, DummyTrait};

fn main() {
    let a = A { b: 1 };
    a.dummy()
}
mod bar {
    #[derive(Drop)]
    struct A {
        b: u8
    }
    #[generate_trait]
    impl Dummy of DummyTrait {
        fn dummy(self: A) {}
    }
}

Now when trying to jump to the definition of a.dummy() or DummyTrait it fails

Other information:

Proposed solution

Drop the vfs:// scheme and write virtual files to a temporary directory just for presentation purposes instead. All of this should happen entirely within CairoLS without modifying Cairo compiler codebase.

[mkaput]

@xJonathanLEI commented on 17.09.2023, 23:44:13:

(All code links in this comment were taken from commit starkware-libs/cairo@2fbb7b1)

Note that this issue only happens on non-VS-Code editors (e.g. Helix) but not VS Code. I originally thought that this is a universal problem, and thus submitted helix-editor/helix#6000 to Helix to ignore vfs URLs altogether. However, @LucasLvy reminded me that it works in VS Code so I took a look and it does indeed work. Good news right? Not really...

Upon further debugging, it turns out that the Cairo LSP defines a custom method vfs_provide:

https://github.com/starkware-libs/cairo/blob/2fbb7b142c96d9007886ddacc0a10889c951cd2a/crates/cairo-lang-language-server/src/lib.rs#L89-L91

How the heck does VS Code know about this method then?? Well, in the extension:

https://github.com/starkware-libs/cairo/blob/2fbb7b142c96d9007886ddacc0a10889c951cd2a/vscode-cairo/src/extension.ts#L357-L363

So... basically the Cairo LSP is proprietary... Any other editors that expect a compliant LSP wouldn't work 100% with the Cairo LSP.

IMO, the ideal way to handle ephemeral files is to simply use a directory like target to actually generate the file and serve the actual path (instead of vfs) to clients.

[mkaput]

@mkaput commented on 2.08.2024, 15:45:40:

Writing down my proposed solution to this:

Instead of employing a custom vfs/provide method, CairoLS should lazily emit virtual files as temporary files in /tmp (follow platform conventions). These files should only be written whenever an URL for them is being generated. Implementor should pay great attention that unused files are deleted by OS (for example on system shutdown).