VBA Rubberducking

12:01 AM

RELOAD!

[rubberduck-vba/Rubberduck] 2 issue comments.

[SimonForsberg/minesweeper-api] 1 commit.

[SimonForsberg/minesweeper-server] 33 commits.

[SimonForsberg/minesweeperflagsgdx] 5 commits.

[Zomis/minesweeper-flags-client] 5 commits.

1 hour later…

1:16 AM

@ScottDennison This is belated and others already replied but just to share an idea - I would look at the compiler directives as essentially generating two separate file. Therefore a module that contains a single #If ... #Else ... #End If should have 2 resulting parse trees. Currently, Rubberduck isn't set up to handle multiple parse trees but if we were going to solve that, that is how it would be done, I think.

@Comintern Also belated but - I'm more inclined to keep the derived types in the same file with the generic definition of the converter. That way, it's obvious.

In fact I might put it at the top so that I have to read down to the implementation and that aids the readability, I think.

[rubberduck-vba/Rubberduck] bclothier synchronized pull request #4820: Implement ThunderCode inspections

1:42 AM

[rubberduck-vba/Rubberduck] build for commit c22ae5ea on unknown branch: AppVeyor build succeeded

[rubberduck-vba/Rubberduck] bclothier opened issue #4821: Designer code generation & csproj layout

> I noticed that the resource files weren't updating the designer. I furthermore noticed this:
![image](https://user-images.githubusercontent.com/2367644/53293827-24e8a700-37a1-11e9-8e0b-dc10ddccec3b.png)

Changed the dropdown to `Public`, and the designer got updated. Furthermore, the `csproj` file got altered as shown:

https://github.com/rubberduck-vba/Rubberduck/blob/c22ae5eafb0c9ecde111e53146e76acc24b5fe57/Rubberduck.Resources/Rubberduck.Resources.csproj#L24-L45

Though in theory, gl

[rubberduck-vba/Rubberduck] bclothier added label discussion to issue #4821: Designer code generation & csproj layout

[rubberduck-vba/Rubberduck] bclothier added label development-issue to issue #4821: Designer code generation & csproj layout

5 hours later…

Vogel612

6:53 AM

@Duga ~sigh oh, visual studio, why isn't it ever simple with you?

6 hours later…

Scott Dennison

1:07 PM

@this That makes sense. However, it also complicates my plans at little :(
As part of a current piece of work I'm assigned at work, I'm needing to automatically modify VB6 code by injecting new code based on certain patterns (E.G: Add a method call below the start of every method entry), which I was doing via a series of visitors over the parse tree. Once the modifications are complete, I call getText() on the top level rule to get a string containing the complete source file with all modifications.

Having just done a scan through all currently used VB6 code in my company's repositories, I can see no #if precompiler directives in the code as it currently stands.
I'm tempted to do a precompiler grammar pass, and upon detecting any #if precompiler directives, reject the file.

M.Doerner

1:26 PM

If your injections would differ based on different constants being set, that would pose a problem for recombination, indeed.

However, if you just hide the non-active code from the parser by moving the tokens to another channel, you can still get the entire code from the ITokenStream. (The top level rule only gets what the parser saw, AFAIR.)

2 hours later…

3:12 PM

[rubberduck-vba/Rubberduck] ScottDennison created comment on pull request #4815: Reduce target language dependence of grammar

> I had a little of look and I couldn't see what the procedure was for completely replacinng a grammar, as opposed to just making small changes of it.
I know if I was using the old grammar, I would be annoyed if it got replaced with the new out of warning.
Any ideas?

Also, which grammars would be pushed. Just the core grammar or the precompiler grammar as well?

It might be better for someone more knowledgeable than me to do that pull request.

[rubberduck-vba/Rubberduck] ScottDennison edited comment on pull request #4815: Reduce target language dependence of grammar

> @Vogel612 I had a little of look and I couldn't see what the procedure was for completely replacinng a grammar, as opposed to just making small changes of it.
I know if I was using the old grammar, I would be annoyed if it got replaced with the new out of warning.
Any ideas?

Also, which grammars would be pushed. Just the core grammar or the precompiler grammar as well?

It might be better for someone more knowledgeable than me to do that pull request.

Scott Dennison

3:36 PM

@M.Doerner If the function name would differ between branches like in the earlier example, then it would screw it up. Probably just easier to leave it as a known future expansion and reject such files.

2 hours later…

Hosch250

5:25 PM

Which one do I use??

All of them.

which one has more stars on github?

BCrypt-Official has the most downloads... I would go with that unless I have a particular reason to use another one.

so, this code is legal and compiles (but won't parse):

Public Sub Test()
    GoTo -1

    Debug.Print "don't print me, bro!"

-1:

    Debug.Print "done"
End Sub

@this Sounds like a feature to me.

Hosch250

@Dair BCrypt-Official is a port of Damien Miller's implementation.

But BCrypt.Net-Next.StrongName has Damien's name on it, says it's an updated version, and has a lot of downloads too.

The relevant grammar are: numberLiteral : HEXLITERAL | OCTLITERAL | FLOATLITERAL | INTEGERLITERAL; and INTEGERLITERAL : DECIMALLITERAL INTEGERTYPESUFFIX?;, fragment DECIMALLITERAL : DIGIT+;, and fragment DIGIT : [0-9];

Note that none of those allows for a - sign. Is there a particular why it won't recognize a negative sign as part of number? I assume to handle the unary operator.

5:33 PM

@Hosch250 I would go with the updated version.

@Dair except, that isn't very "What you type is what you get"

I suppose to avoid screwing up the grammar around the actual numeric literals in the code, the line numbers could be given a couldBeNegativeNumberLiteral rule. #FunTimes

@this I'm kidding haha, although it seems like a somewhat questionable way to code...

I sincerely hope there is no production version of VB* code out there that uses this.... "feature".

thinking about it, it might be more useful for malicious intentions.

is it really a bug if nobody produces it? hmmmmmm

well, ThunderFrame produced it, so it's a bug now.

5:39 PM

Maybe ThunderFrame is the real bug.

(Of course, I'm just kidding in case it wasn't obvious)

6:34 PM

[rubberduck-vba/Battleship] vbamagician forked us into vbamagician/Battleship

7:07 PM

[rubberduck-vba/Rubberduck] D3vlin forked us into D3vlin/Rubberduck

2 hours later…

9:06 PM

[rubberduck-vba/Rubberduck] bclothier synchronized pull request #4820: Implement ThunderCode inspections

[rubberduck-vba/Rubberduck] bclothier created comment on pull request #4820: Implement ThunderCode inspections

> Please note that the grammar has been updated to handle the bogus "negative" line number to allow it to be inspected and warned. With that, we now have a total of 5 ThunderCode™ inspections.

9:25 PM

[rubberduck-vba/Rubberduck] build for commit d32e89d5 on unknown branch: AppVeyor build succeeded

9:45 PM

[rubberduck-vba/Rubberduck] bclothier commented on Rubberduck.Resources/Inspections/InspectionInfo.resx of pull request #4820: Implement ThunderCode inspections

1 hour later…

IvenBach

11:00 PM

@Comintern can have the icon say TO DO on two lines in the sticker if it fits.

11:40 PM

@Duga @this Do we care that line numbers and labels are not semantically equivalent?

> Executing a <statement-label-definition> has no observable effect.

...or does it....

When you step through with the debugger, it treats -1: as a numbered line with an empty statement. Compiler is doing something messed up there.

And, my new favorite line in the spec:

> The name value of the <IDENTIFIER> in <identifier-statement-label> may not be "Randomize".

@Comintern My assumption was that it is used internally unsigned

That was my assumption too.

Therefore what we "see" as -1 is in fact int32.MaxValue

oops, uint32

> If <statement-label> is an <INTEGER>, it data value must be in the inclusive range 0 to
2,147,483,647.

Uhuh.

someone didn't check this when writing the specs, apparently

@Comintern do you have an example where it matters?

11:53 PM

I'm not sure. I mainly thought it was odd how the compiler handled it.

I'd say Erl, but that's borked anyway.

TBH I struggle to conceive how you would create a label using digitts

Normally one would quote it but I doubt it works like that

Interesting. It overflows Erl:

Public Sub Test()
    On Error Resume Next
-1:
    Debug.Print 1 / 0
    Debug.Print Erl
End Sub

Outputs 65535

there's also other part in the MS-VBAL that's wrong about the range for the error number...