Synchronize code_lens request & provide better UX for forc-fmt <> sway-lsp interaction.

[JoshuaBatty]

Description

This PR adds 3 things:

1. Adds a benchmark for the format LSP request.

2. Calls session.wait_for_parsing(); before computing the code_lens request. This fixes the original issue reported in Conflicts between language server and forc-fmt #4893 where run buttons where being placed incorrectly after formatting.

3. If a file open in a code editor contains unsaved changes we write a lock file to .forc/lsp_locks/. This file is removed when the file is saved and there are no pending changes. If forc-fmt is run in a terminal we check if the path has a lock file associated with it. If unsaved changes are detected we bail from formatting with an error message instructing the user to save changes before continuing. See video below.

Screen.Recording.2023-09-13.at.4.34.34.pm.mov

closes #4893

Checklist

• I have linked to any relevant issues.
• I have commented my code, particularly in hard-to-understand areas.
• I have updated the documentation where relevant (API docs, the reference, and the Sway book).
• I have added tests that prove my fix is effective or that my feature works.
• I have added (or requested a maintainer to add) the necessary Breaking* or New Feature labels where relevant.
• I have done my best to ensure that my PR adheres to the Fuel Labs Code Review Standards.
• I have requested a review from the relevant team or maintainers.

[anton-trunov]

What if the user changes their files on disk using something different from forc-fmt, e.g. sed? I understand that it's less likely, though.

I believe, if possible, it would be nice to have forc-fmt and sway-lsp not aware of each other.

[JoshuaBatty]

I believe, if possible, it would be nice to have forc-fmt and sway-lsp not aware of each other.

Yeah I agree this would be ideal. I'm going to put this PR in draft mode while I ponder on this a bit more. Thanks Anton

[tritao]

I believe, if possible, it would be nice to have forc-fmt and sway-lsp not aware of each other.

Not sure what's the best approach here, but just as another data point, Cargo and rust-analyzer also seem to have some kind of integration, as if cargo is running from the VS Code LSP session, then cargo from the command line will wait until it's finished before starting.

[anton-trunov]

Ah, that's interesting, didn't know about that integration. I'd guess they use some kind of file system lock. @tritao can you share some more details how they do it?

[tritao]

Ah, that's interesting, didn't know about that integration. I'd guess they use some kind of file system lock. @tritao can you share some more details how they do it?

I don't know how they do it, but I would assume a filesystem lock too.

[tritao]

Ah, that's interesting, didn't know about that integration. I'd guess they use some kind of file system lock. @tritao can you share some more details how they do it?

This is the message I see: Blocking waiting for file lock on build directory

[sdankel]

We should get thing 1 and thing 2 in regardless!

This is the message I see: Blocking waiting for file lock on build directory

Taking a lock on the build directory is clever because it links it to the specific sway project, doesn't prevent editing the file in other editors at the same time, and should only ever be touched by forc.

Both forc-fmt and forc-client (forc build) would also need to wait for a lock on the build directory.

We could have LSP take a lock on the build directory on format_text, but I'm concerned it would block other operations for a long time because sometimes it's very slow. What results did you get from benchmarking? Is get_page_text_edit the reason it's sometimes slow?

[JoshuaBatty]

What results did you get from benchmarking? Is get_page_text_edit the reason it's sometimes slow?

It's actually pretty fast. Averaging ~98ms to complete. I think the slowness is coming from the client <> server interaction.

[JoshuaBatty]

Thanks for the tips everyone. I'm going to look into a nice solution this week.

[JoshuaBatty]

Ok i'm pretty happy with this now.

Any unsaved changes for a file in LSP now creates a hashed lock file in ~/.forc/.lsp_locks/. When a file is saved or closed and changes are discarded then the lock file is removed. The formatter checks for the existence of this lock file before formatting. If one exists then the user is instructed to save the file before continuing. See the updated video in the description.

[sdankel]

LGTM, just need to clean up eprintlns