Update value in signature file.

[nojaf]

WHAT

🤖 Generated by Copilot at ffe2cca

This pull request adds a new code fix feature that updates the value declaration in a signature file to match the implementation file, and integrates it into the language server and the test suite. It also refactors and cleans up some existing test modules and utilities for code fixes, and adds a new module for a code fix that converts string concatenation to interpolated strings.

🤖 Generated by Copilot at ffe2cca

We're the crew of the FsAutoComplete ship We sail the seas of code with skill and wit We fix the strings and values as we go And test them all with testCaseAsync so

🧵🔄🧪

WHY

HOW

🤖 Generated by Copilot at ffe2cca

• Add two new code fixes for string concatenation and value declaration mismatch (link, link, link, link, link, link, link)
  • The ToInterpolatedString.fix function converts string concatenation expressions to interpolated strings using the $ syntax (link)
  • The UpdateValueInSignatureFile.fix function updates the value declaration in a signature file to match the implementation file using the FSharpSymbolUse information (link)
  • The signature files ToInterpolatedString.fsi and UpdateValueInSignatureFile.fsi declare the public types and values of the new code fix modules (link, link)
  • The AdaptiveFSharpLspServer and FSharpLspServer types can handle the new code fixes by adding them to the list of code fix providers (link, link)
  • The UpdateValueInSignatureFileTests.fs file contains the test cases for the UpdateValueInSignatureFile code fix, using the checkFixAt function with different document identifiers (link)
  • The tests function in Tests.fs runs the new code fix tests along with the existing ones (link)
• Enhance the test utilities to support code fixes that affect multiple files (link, link, link, link)
  • The checkFixAt function takes a new parameter editsFrom that specifies the text document identifier from which the code fix edits should be extracted (link)
  • The checkFixAt function applies the code fix edits to the document specified by editsFrom, which may not be the same as the document that triggered the code fix (link)
  • The checkFix and checkFixAll functions pass the document identifier of the untitled or shared document to the checkFixAt function, which is the same as the document that triggered the code fix (link, link)
• Format and refactor the test code and utilities for readability and consistency (link, link, link, link, link, link, link, link, link, link, link, link, link, link, link, link, link, link, link, link, link, link, link, link)
  • The RenameParamToMatchSignatureTests.fs file adds new lines before each testCaseAsync expression to improve the readability and consistency of the test code (link, link, link, link, link, link, link, link, link, link, link, link, link, link, link)
  • The RenameParamToMatchSignatureTests.fs file removes an extra empty line at the end of the module (link)
  • The CursorbasedTests.fs and CursorbasedTests.fsi files remove some unused open statements from the Utils.CursorbasedTests module (link, link, link, link)
  • The CursorbasedTests.fs file removes some extra spaces and new lines from the diagnosticsIn, checkFixAt, and checkFixAll functions (link, link, link, link)

Dog feeding https://github.com/fsharp/FsAutoComplete/pull/1158 a bit. I think I'm doing something wrong on the Expecto side. dotnet run isn't exiting correctly.

The actual code fix needs to be expanded a bit more. I would, however, very much like to have this. I could use a first round of feedback if anybody is up for it.

[nojaf]

This can actually be solved quite easily if the newly added extended data is available.

@baronfel any ideas on how we want to expose this optional information in the Diagnostic type?

[nojaf]

@TheAngryByrd I'm able to get the extended data from the diagnostic in the check results. This is heaven-sent.

[baronfel]

This is great @nojaf - using extended data was what came to my mind immediately. Let me take a look at the way you're using it - we may want to think of some kind of protocol for single-fix vs whole-file fixes, for example.

[TheAngryByrd]

I know LSP kind of defines categories but they’re not explicit. Had to go looking thru the vscode code to see what was supported.

[nojaf]

Let me take a look at the way you're using it - we may want to think of some kind of protocol for single-fix vs whole-file fixes, for example.

Could that be part of a separate effort? I feel like this one is good to go, nothing to lose here.

And could someone re-run the failed builds? I don't think all of them are problematic. Thx!

[TheAngryByrd]

And could someone re-run the failed builds? I don't think all of them are problematic.

3 of them (mac/ubuntu) seem to be formatting failures.

src/FsAutoComplete.Core/Commands.fs needs formatting

Is this just newline/encoding nonsense?

[nojaf]

Serious doubt there. Did you re-run them?

[nojaf]

Could this one get merged please?

[nojaf]

Thanks Jimmy!