Roslyn: [VB.NET] Editor has variable name casing issue in ElseIf statement

[VBAndCs]

Version Used:
VS Community 16.7.6

In the next code snippet:
```VB.NET
Dim Test = 1
If Test = 1 Then

ElseIf test = 2 Then

End If
```

The name test is auto converted to Test after leaving the if line, but the same doesn't happen when leaving ElseIf line. The only thing to force this to happen is to make any change in the if line, but making changes in the ElseIf line doesn't have any effect.
I never detected this in VB editor, and I think it relates to a recent update.

[CyrusNajmabadi]

@VBAndCs Would you be interested in contributing a fix here?

[CyrusNajmabadi]

I've checked and it doesn't look like our behavior has changed here. If you are interested in contributing a fix, LMK and i can walk you through it. The issue here is simply at:

https://github.com/dotnet/roslyn/blob/9907769fd1cb8392bb41ed999c4b0724c6c2c6be/src/EditorFeatures/VisualBasic/LineCommit/CommitBufferManager.vb#L192-L198

This logic is not valid there are two potential fixes:

1. don't think of us as being on an end-construct. after all, this is not the end if, this is an else if.
2. even if we think we're on an end-construct, in order to fixup the indentation of a larger span, we still need to do a semantic fixup of this statement.

@VBAndCs i'm ok with you taking either approach, though my guess is '1' is easiest, but '2' is most thorough and won't lead to any indentation regressions.

[VBAndCs]

@CyrusNajmabadi
You seem to think I get what you are saying :). I know nothing about this subject, and I find these issues because I am sinking in a deep VB app, that needs months to complete.
Sorry, I will fail you here too.

[CyrusNajmabadi]

@VBAndCs I'm happy to help teach you how to fix these issues.

You seem to think I get what you are saying

I'm giving some pointers as to where the issue is (for either you, or anyone else interested in fixing). If you get interested in fixing, we can go from this to an actual fix.

I know nothing about this subject

Everyone starts somewhere :)

Sorry, I will fail you here too.

If you have any time in the future, just let us know, and we may be able to make progress on some of these corner issues you've run into that have bothered you. If not, no worries.

[VBAndCs]

I've checked and it doesn't look like our behavior has changed here

Just an idea: the change could happened in one methods/properties in the call chain. I ever never saw something like this since I began with VB4 until few days ago.

Thanks for generous help offer, I will seriously consider it.

[VBAndCs]

Another idea: Is this issue relative only to elseif, or can happen in other similar blocks?
This is another reason to search when and where it started.
And another question: Isn't there tests to detect such behaviour changes?

[CyrusNajmabadi]

like this since I began with VB4 until few days ago.

VB4 was in 1995. It's 25 years old. This behavior goes back as far as i can tell in Roslyn. Which means it's at least 10 years old.

This is another reason to search when and where it started.

Roslyn was a complete rewrite. So it likely came about when roslyn was created.

Isn't there tests to detect such behaviour changes?

Yes. We have numerous tests of this feature. But no amount of testing is exhaustive. If it was, then we wouldn't ever have any bugs. I can point you to the tests here as they would certainly be updated for any fix here. This would help this precise issue from regressing, but is no assurance that no other bugs exist here.

[paul1956]

@CyrusNajmabadi I spent yesterday looking at the Lines L192-L198 above and then looking for tests that hit it. Unfortunately since I no longer have Professional that feature of CodeLens is not available, so I searched for the test that hits it so far no luck. If someone has Pro or above and wants to point out test that hits this I will create new failing tests, then if no one else wants to fix I will look at that but it will not be until mid-November.

[VBAndCs]

Which means it's at least 10 years old.

I write VB code every year. But I think this issue is hidden by the intellisense, since we usually hit space or dot to choose the selected name from the auto complete list. It I don't know why I had this issue in WPF, maybe after a paste operation :)

[CyrusNajmabadi]

@paul1956 Tests are likely in CommitWithViewTests.vb

[VBAndCs]

As I suspected, it doean't happen in `ElseIf`` only. This is another place, and there could be more:

        Dim Test = 1

        Do

        Loop While test = 1 ' Happens here too

[VBAndCs]

And here too:

        Dim Test = 1

        Try

        Catch ex As Exception When test = 1

        End Try

Note that all keywords are fixed, but not the var name. For example, write:
Catch ex As Exception where test = 1
Then fix where to when. It will converted to When and coloured in blue, but test will remain as is.

[VBAndCs]

Here too:

        Dim Test = 1

        For Test = 0 To 10

        Next test ' <----

[paul1956]

@VBAndCs, could you update examples and put $ on where the cursor is when you press return I assume the comments are not part of the test? I will create a bunch of tests (5-6) additional tests today an push a PR with SKIP that someone can pick up, I also have it the issue down to a few lines and will look at history to see if something changed.

[VBAndCs]

It doesn't relate to return only. The change should also happen if you made a modification to a line, then moved the caret to another line.

[VBAndCs]

There is also another behaviour that annoys me:
Id I change the var casing in the declaration statement and leave the line (say test instead of Test), the editor doesn't apply this change to all the places where the var is used. I need to make any change to the enclosing block (like adding a trivial space at the end of the function declaration statement), so, the editor reformat the whole block and apply the change in the var name!

[CyrusNajmabadi]

@VBAndCs this is as I said in : https://github.com/dotnet/roslyn/issues/48745#issuecomment-711485983

[paul1956]

I did PR #48807 to fix, it was a performance optimization that did not take into account the difference between C# and VC Block's. @VBAndCs let me know if fixes all your issue.

[paul1956]

@jinujoseph how do I get this assigned to me as I already did PR #48807 to address?

[jinujoseph]

Done, Thanks for the fix @paul1956

[paul1956]

@jinujoseph what is the state of this I thought PR #48807 was on hold because the file it is in was undergoing major changes?

[jinujoseph]

thanks for the ping @paul1956 , Cyrus is taking a look at this again.