fix IDE features should work on unsaved files #1080

[asukaminato0721]

fix #1080

[yangdanny97]

sweet, thanks! I'll give this a more detailed review when I have time, but it might take a week or two. This will likely conflict with notebook support given that the plumbing touches the same code, and I'd like to merge the notebook support before this change.

[kinto0]

could you add more details on your approach?

why does the untitled uri work? is it something VSCode sends when we say we accept it? why? does it work on other editors?

[asukaminato0721]

The server already knew how to treat non-filesystem buffers via ensure_path_for_open, which fabricates a stable path under __pyrefly_virtual__ and stores the contents in open_files; every feature later resolves the handle by checking open_files first

VS Code simply wasn’t telling Pyrefly about unsaved editors before. Extending the documentSelector so the client advertises support for {scheme: 'untitled', language: 'python'}

VS Code assigns untitled: URIs to unsaved editors. It only starts an LSP session for those buffers if the language client’s documentSelector claims that scheme. After our selector changes, the client receives didOpen/didChange for the buffer, forwards them to the server, and the server converts the URI to an in-memory ModulePath::memory entry.

ref https://code.visualstudio.com/api/references/document-selector#document-selectors

The untitled scheme is for new files that have not yet been saved to disk.

The logic is editor agnostic as long as the client can deliver URIs for transient buffers. Different editors pick different schemes (e.g., Neovim’s buffer:

If their LSP client advertises those schemes in the documentSelector, Pyrefly will accept them because ensure_path_for_open handles any scheme by generating a unique virtual path

Editors that don’t expose unsaved buffers through LSP yet would need equivalent client-side support, but nothing additional is required in the server.

[meta-codesync]

@kinto0 has imported this pull request. If you are a Meta employee, you can view this in D86696372.

[kinto0]

awesome!! I wonder if we could limit the size of server.rs and make it a cleaner API if it was it's own struct. thoughts?

looks like there are some merge conflicts too

[asukaminato0721]

works now

[kinto0]

Review automatically exported from Phabricator review in Meta.

[yangdanny97]

@asukaminato0721 the test image in the PR doesn't seem to exercise the feature - that open file seems to be named already, whereas the feature in question is for files that are completely new/unsaved/untitled.

I'm not able to get this working while manually testing with a local build of the extension.

the repro I've been trying is ctrl+n to open a new file, select Python as the language, and write some code. In those cases, I'm not getting any LSP requests to Pyrefly, despite our capabilities specifying that we can take files with the untitled scheme. I'm fairly confident that things would work if we did get those requests given that you wrote tests, but VS code isn't sending the requests at all, it seems.

Are you able to successfully repro using those steps on your end?

[asukaminato0721]

cargo build -p pyrefly
cd lsp
code .

in the setting, set the binary path to /path/to/target/debug/pyrefly

then press F5, so the extension debug vscode launches.

Screencast_20251113_012623.webm

[yangdanny97]

Oops, I wasn't building the right changeset. Sorry for the confusion

[yangdanny97]

I've successfully validated the PR manually, thanks for your patience and help here.

I've patched it internally to avoid passing URIs representing regular file paths into the UnsavedFileTracker - even though it returns immediately without caching it, I didn't find the data flow to be intuitive.