Saving a script file under a different name results in loss of colorization

[dsyme]

Saving a script file under a different name results in loss of colorization

Repro steps

Provide the steps required to reproduce the problem

1. Take script1.fsx containing some F# code. Observe its colors

2. Save it as script2.fsx. Observe its colors

Expected behavior

Colorized in both cases

Actual behavior

Colorized only prior to the save-as operation

Known workarounds

close/open the file

[dsyme]

We should test similar scenarios in projects as well (e.g. adding/deleting/renaming files in projects)

[cartermp]

I can't repro this on master from up until here: 4b8aafd

[rojepp]

Can't repro either, using VisualFSharpOpenSource from a few days ago.

[cartermp]

Got it to repro:

It looks like reserved keywords aren't getting colorized, but type information is.

Repro steps (on latest master):

1. Create Script1.fsx in a new Console Application
2. Type the following code:

type BST<'T> =
    | Empty
    | Node of 'T * BST<'T> * BST<'T>

let getStringAsync(str: string) = async { return str }

let fooAsync() = async {
    let! str1 = getStringAsync "hello"
    let! str2 = getStringAsync "world"
    return str1 + str2
}

Now rename it to Script2.fsx, and observe the above.

[cartermp]

Looks like IEditorClassificationService.AddSyntacticClassificationsAsync isn't invoked on a rename, as per @brettfo's suspicions.

[saul]

I didn't even need to rename the file. I added the file to an existing project, pasted the code, saved it and then I suffered the same discolouration as above.

[cartermp]

@Pilchie @brettfo Is this something we can address from the Roslyn side? Syntactic Classification isn't called for script files under certain circumstances.

[Pilchie]

This would happen if the ITextSnapshot doesn't correspond to a Document that is part of the Workspace. I don't think this a Roslyn issue.

[majocha]

Simple repro is to rename a script file in Solution Explorer.

Cause of this bug is that we currently don't handle script file renaming. Roslyn exports a MiscellaneousFilesWorkspace which tracks renaming scripts by implementing IVsRunningDocTableEvents2 but we don't use it.

[saul]

The reason this is happening is because in FSharpLanguageService we're listening on Workspace.DocumentClosed. This is fired when the script file is renamed, and so we remove the single-file project. DocumentOpened is never fired again and neither is SetupNewTextView (what we use to setup single file projects).

@Pilchie do you know what the proper way to setup single-file projects is? What event should we be listening to that will fire when a document is renamed?

[saul]

@majocha We can't use MiscellaneousFileWorkspace until dotnet/roslyn#17263 is made available. See dotnet/roslyn#17263 (comment)

[dsyme]

I can confirm that this does not appear to be fixed by #3025

[cdutcher]

Is there any eta or plan for this fix?

[cartermp]

Not at the moment, no.

[saul]

Shame - I fixed this is #2909.

[cartermp]

I’m actually keen on getting that PR worked on, or at least chunks pulled out and merged. But we sinply lack the bandwidth right now due to .NET Core platform and tooling bringup.

[saul]

I’ll pull out the fix for this issue now and take a stab at using the MiscellaneousFilesWorkspace - that’s the proper fix (but we couldn’t use it back then)

[cartermp]

@saul Awesome! Just in terms of timeframe, VS 15.6 release is unlikely to take a fix like this since we're nearly locked down, but 15.7 is still quite open.

[cartermp]

Just as an update, renaming a .fs file to a .fsx triggers this issue, forcing a re-open of the document.

Now that we depend on updated Roslyn and editor binaries, we could probably fix this a lot easier than before.

[saul]

Fixed by @TIHan's PR: #5733

[cartermp]

Closing as fixed. Note that we're also in the process of letting Roslyn effectively handle this all for us with a proper workspace here: dotnet/roslyn#31134