When there is more than one line continuation character before or after the period (.) in member access expression, the parsing fails

[neorobin]

Rubberduck version information The info below can be copy-paste-completed from the first lines of Rubberduck's log or the About box:

Version 2.5.9.6291 OS: Microsoft Windows NT 10.0.19045.0, x64 Host Product: Microsoft Office x86 Host Version: 16.0.16827.20130 Host Executable: EXCEL.EXE

Description

The following are examples of rubberduck parsing failures, but they are all compiled successfully in VBE. VBE allows any number of consecutive line continuation characters.

     a = b _
  _
     . _
     c

or

     a = b _
      . _
  _
     c

or

     a = b _
  _
      . _
  _
     c

[MDoerner]

I guess I will have a look into this next week, when I have time again.

[retailcoder]

Interesting, that's the kind of legal-but-unlikely code @ThunderFrame would have thrown at it! I could have sworn at least one of the thousands of tests covered similarly evil continuation placements... thanks for the report!

[neorobin]

I am trying to create my own VBA syntax parser. Therefore, I conducted detailed tests based on the syntax rules provided by [MS-VBAL]. Some of the coding styles I tested are rarely used or mentioned by others. During the testing process, I discovered some rules mentioned by [MS-VBAL] that, in fact, even the VBE hasn't implemented. Additionally, there are some rules from [MS-VBAL] where the actual implementation in VBE is inconsistent. There are also some editorial errors in [MS-VBAL]. I aim to ensure that my syntax parser can handle the grammar approved by VBE to the greatest extent possible while also rejecting syntax that VBE deems illegal. I'm well aware that this is very challenging. During testing, I encountered some difficulties and areas that few people pay attention to. I will also test these with Rubberduck. If I find discrepancies between Rubberduck's performance and VBE's, I will try to provide feedback. Thank you all!