Rubberduck: Indenter indents line numbers/labels that include line continuations

[ThunderFrame]

After indent:

Sub foo()
 _
    10
 _
    foo _
    : Beep

20 bar: Beep
End Sub

[comintern]

Clarification for my own sanity. The compiler is treating 10 as a line number here, but the IDE is as confused as I am by this syntax - it doesn't follow its formatting rule of pinning the line number to the left margin.

I can't even figure out how this is compiling by stepping through it with the debugger:

    foo _
    : Beep

By my read, foo should be a recursive call to Sub foo() (followed by a Beep after the line combining :) and this should never exit.

It seems to be interpreted like this:

Sub foo()
10
foo: Beep
20 bar: Beep
End Sub

Note that this is a parse error too.

[ThunderFrame]

No, foo is a line label on the line after the line number, then an instruction separator then the label termination colon is on the next line, then the beep statement. i.e. statements with line-numbers 10 and 20 are identical, and should be read as:

Sub foo()
10 foo: Beep    
20 bar: Beep
End Sub

[MDoerner]

I have no idea how the compiler interprets the code example. Per spec, line labels must be at the start of the logical line.

[ThunderFrame]

IIUC, when determining the logical line, the VBE treats the physical line continuation as if it is:

" *_ *\n *"

and then treats line-continuations as if they don't exist, so, to the VBE, the line number _looks_ like it is at the start of the logical line.

[comintern]

I'm still not exactly clear on why the foo: label is on line 10.

This outputs 10, but I'm not sure if that's because of the behavior of Erl (it always just returns the last number encountered) or the compile itself:

Sub foo()
On Error GoTo bar
 _
    10
 _
    foo _
    : Debug.Print 1 / 0

20 bar: Debug.Print Erl
End Sub

This also outputs 10:

Sub test()
On Error GoTo label
10
    Debug.Print 1 / 0
label:
    Debug.Print Erl
End Sub

Do we think that all whitespace (_including_ newlines) is ignored after a line number?

[bclothier]

I'm not so sure.

There is a missing line continuation for the line where 10 is.

This works:

Sub foo()
 _
    10 _
 _
    foo _
    : Beep

20 bar: Beep
End Sub

and adding that one changes how debugger will highlight the lines. That one is more like the

Sub foo()
10 foo: Beep    
20 bar: Beep
End Sub

because in both cases, the yellow highlight starts from 10 to the beep in the logical line 10 foo: Beep.

In contrast, the following code seems more like the original sample:

Sub foo()
10 
foo: Beep    
20 bar: Beep
End Sub

the original code and this sample has same highlighting behavior (e.g. it only highlights the foo: Beep but not the 10).

Note further, that in all cases, GoTo 10 and GoTo foo essentially does the same thing.

[MDoerner]

I think I have an idea how to fix the parser to accept the line continuations in front of the line number. However, I will have to test whether that brakes something else.

[ThunderFrame]

I'm convinced it's a single logical line, but it seems like a little tool called vbWatchdog might be of use here, or even a p-code analysis. I'm AFK. Maybe @WaynePhillipsEA can help determine the lines are a single logical line?

[WaynePhillipsEA]

Line labels are lost at the excode level, but it basically gets compiled to:

Sub foo()
10 Beep    
20 Beep
End Sub

[ThunderFrame]

@WaynePhillipsEA - Thanks for the confirmation.

[comintern]

Now to the harder? question. Given this...

Sub Foo()
 _
10
 _
foo _
: Beep

20 bar: Beep
End Sub

...what do we expect the output from the indenter should be (assuming default settings)?