Fsharp: Rename often not working with records

[abelbraaksma]

In the most recent 15.9.0 I notice that Rename is still often not working with record types. I'm currently just reporting this as a fact, since each time when I try to repro it on a smaller scale, it "just works". But in my code (which compiled before the rename), it fails to see record labels that are even in the same file. Other times, it garbles the rename.

If this is a known issue (after #5520 was resolved), I'd be happy to close this with a reference to that. If not, I'll try to come up with a proper repro.

Repro steps

See below: https://github.com/dotnet/fsharp/issues/5919#issuecomment-678628266

Expected behavior

Rename should work for all references of a label or identifier.

Actual behavior

It missed 41 of 44 references in my most recent attempt to use Rename (usually I just resort to Search All).

Known workarounds

Use Replace All or Search All.

Related information

VS 2017 15.9.0 Professional, Windows 7 and 10, F# 4.5.

[abelbraaksma]

Ok, I've rollbacked all changes and tried the following:

• Rebuild-All
• Rename one identifier
• Rebuild-All
• Rename other identifier or label

etc.

Not sure what happens behind the scene, but perhaps Rename is not supposed to work on large projects? I.e., perhaps the internal build times out and it leaves the resulting code garbled? (it was not only missing renames, but whole lines that ended up garbled with the new name added in the middle of irrelevant other lines).

[cartermp]

Rename requires that files are saved on disk. If you ensure that all files are saved, does it still happen?

[abelbraaksma]

@cartermp , tx. I am not 100% sure whether the files were saved or not. Esp. when I did one rename after another.

But if this is indeed a requirement and it can go horribly wrong if the requirement isn't met, perhaps a popup saying "Rename requires documents to be saved, to continue, click 'Save all'" (or something along those lines.

A couple of more renames further, the cycle with Rebuild-All seems safe (but slow, but so is Rename). I'll try my next cycles with a simple Ctrl-Shift-S and see what happens.

[BentTranberg]

I used to use Rename intensely, and my experience was that it was highly reliable until a few months back, not sure exactly when and which version. Suddenly it failed almost every time, garbling text. It never garbled text before that, even when it could not succeed. So I stopped using it, but have tested it now and then, and it's still not usable. I'm at 15.9.3 now.

[cartermp]

@BentTranberg Do you have a repro? As mentioned above, rename requires files to be saved on disk. If they are not saved, then it can mange things.

[BentTranberg]

I think what I do is compile before Rename, because that will not only save the files, but also, I think, make sure Rename has the information it needs. I may be wrong about how it works, but I've been sure it's a failsafe approach. But I suspect text is still mangled in the later versions.

I can try to create a repro after 15th Dec. Far too busy before that.

[cartermp]

If you have in-memory cross-project references turned off, then you would need to compile your project. Otherwise, it isn't necessary.

[abelbraaksma]

@BentTranberg I've seen the mangling too, where the renamed name seems copied into a wrong location in the file or line, or even the wrong line. But this happens solely (in my case at least) when I forgot to save.

Though, @cartermp, this isn't very intuitive now, perhaps the feature can be changed such that it auto-saves before it does anything? Since basically, when not everything is saved, the potential damage to your code is big and, well, the feature has no merit unless it is saved anyway.

[cartermp]

We don't have the control to auto-save your documents - #2204 is the canonical issue when there are dirty buffers; my main question is if there are any other scenarios in which you see this.

[abelbraaksma]

@cartermp, other actions manage it, though, for instance, when you do a build, it auto-saves. And this seems to be (almost) in the same league. Can't we borrow from that technique?

[majocha]

Maybe we could use this SaveFileIfDirty on the open documents.

[cartermp]

I'd actually be in favor of something like this, though it would have to be called before we call into FCS. Given the low usage of Rename (regardless of language, not just F#) I think the majority of people who would use the feature would be fine with auto-saving dirty documents. The main concern is that those who don't use source control and instead use saved/unsaved to track state would be affected by this, but I find that group of people also very unlikely to use productivity features heavily.

[majocha]

The other option is check the RunningDocumentTable for dirty documents and display unobtrusive suggestion to save all on the status bar.

[cartermp]

IIRC there are some dragons involved with the running document table, but I'm not sure if they are applicable here. That would get sussed out in an actual trial implementation, though.

[abelbraaksma]

Maybe we could ask the user the first time, similar to F5 debug, with an option to not ask again and remember the choice?

Though that could be an improvement.

Note that currently, when you rename, after the renaming is applied, it already saves all dirty documents anyway, so anybody currently using this feature won't see a change in behavior. We're just going to save before and after the rename.

[cartermp]

@abelbraaksma Have you noticed this reproducing when you ensure that the file(s) are saved? If not, then this can be closed since the rename-not-working-for-unsaved-files bug is already tracked.

As an aside, @TIHan has been making some wonderful infrastructural changes to the language service and we have a build that fixes that rename bug (and numerous other issues). It's not ready enough to get into a pull request though, but you can expect a future VS update to have the fix 😄

[abelbraaksma]

I'm not sure, I've stayed away from rename because it failed now often than it succeeded in general, but I should give it another go.

[abelbraaksma]

@cartermp Tried it a few times again with the recent VS 2019 and yeah, it still happens. A few things that need to be there seem to trigger this:

• A large project with the identifiers to change in the most common or root project, and references don't need to be many, but they need to be far
• The issue may have something to do with timeouts of the rename waiting for a rebuild and my full builds takes about 2 - 3 minutes
• Now change a name (having preview on or off doesn't matter, it triggers preview anyway). Typing will be really slow when doing the rename (1 sec per char or so)
• Click Apply
• Now rename the same (or another) again
• Click Apply

Doing this a few times will bring the VS editor to a crawl (and it won't recover until you restart). This is on a 2 CPU, combined 24 cores and 48GB of memory and modern, fast SSD, so the system itself doesn't seem to be the slowing factor here.

After a few times, you will notice that some names are only changed halfway (i.e., just a bunch of characters). Compiling shows where it goes wrong, so it is not that big a deal, but that the Rename feature has become reliable? I'm afraid not yet :S.

[abelbraaksma]

@cartermp, can I somehow create a trace of this so that we can investigate better? It would be nice to stabilize this feature.

[cartermp]

@abelbraaksma have you been able to reproduce this outside of the case listed here? https://github.com/dotnet/fsharp/issues/2204

[abelbraaksma]

@cartermp, here's a video of renaming going totally berserk, and this isn't a record, just a type alias. I managed to repeat it a couple of times, but requirement was to build before rename, otherwise the rename never ended (requiring me to hit Cancel):

Repro:

• Open VisualFSharp.sln
• Open ServiceLexing.fsi
• Rename type Range

It doesn't matter whether you wait for the dialog to show that it'll rename X references or not. After rename, the name is garbled to RangeXRangeXRangeXRangeX, while I only added an X.

(apologies for the lengthy vid, renaming is a slow process ;) )

[abelbraaksma]

Same happens on a record field:

After this second change, the project didn't compile anymore, because in several places it was properly replaced, leading to a mismatch with the declaration.

A little bit disturbing is that Ctrl-Z didn't rollback the change either...

[abelbraaksma]

What I didn't see anymore, at least not yet, is changes in the wrong position of the line, which can ultimately crash VS. But I don't use Rename so often (I primarily work on large projects, where Rename would be useful, but it is just way too slow) to be sure those bugs are gone.