Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rubberduck parsing error when attempting to wrap a COM object property that is a VBA reserved word. #6161

Open
MarkJohnstoneGitHub opened this issue Oct 1, 2023 · 4 comments
Labels
antlr Issue is easier to resolve with knowledge of Antlr4 bug Identifies work items for known bugs has-workaround There is some way of working around this limitation / bug that is confirmed to work

Comments

@MarkJohnstoneGitHub
Copy link

MarkJohnstoneGitHub commented Oct 1, 2023

Rubberduck version information
Version 2.5.9.6296
OS: Microsoft Windows NT 10.0.19045.0, x64
Host Product: Microsoft Office 2016 x64
Host Version: 16.0.5317.1000
Host Executable: MSACCESS.EXE

Description
Rubberduck parsing error when attempting to wrap a COM object property that is a VBA reserved word.

To Reproduce
Require a COM object with a property name that would conflict with a VBA reserved word.
For the example the COM object MatchSingleton has a property named Empty as displayed screenshot.

When attempting to wrap the MatchSingleton.Empty property, displayed below and selecting the RD parse icon it produces a 'Parse Error'. Commenting out the Set EmptyMatch = this.MatchSingleton.Empty() there is no parse error.
Notes:
Renamed the wrapper property to EmptyMatch as Empty is VBA reserved word.
Code compiles.

To avoid the Rubberduck 'Parse Error' issue I've renamed the COM object property MatchSingleton.Empty property to MatchSingleton.EmptyMatch and parses ok. i.e. Set EmptyMatch = this.MatchSingleton.EmptyMatch()

'@Description("Gets the empty group. All failed matches return this empty match.")
Public Property Get EmptyMatch() As DotNetLib.Match
   Set EmptyMatch = this.MatchSingleton.Empty()
End Property

Expected behavior
No parsing error.

Screenshots
image
image

@MarkJohnstoneGitHub MarkJohnstoneGitHub added the bug Identifies work items for known bugs label Oct 1, 2023
MarkJohnstoneGitHub added a commit to MarkJohnstoneGitHub/VBA-DotNetLib that referenced this issue Oct 1, 2023
Renamed member MatchSingleton.Empty to MatchSingleton.EmptyMatch due to Rubberduck 'Parse Error' issue with the VBA reserved word  'Empty'.  It compiled fine, fix is to address the RD issue added rubberduck-vba/Rubberduck#6161
@Vogel612
Copy link
Member

Could you do me a favor and check whether referencing Empty as a foreign name also fixes the issue?

    Set EmtpyMatch = this.MatchSingleton.[Empty]()

@MarkJohnstoneGitHub
Copy link
Author

MarkJohnstoneGitHub commented Dec 24, 2023

Could you do me a favor and check whether referencing Empty as a foreign name also fixes the issue?

    Set EmtpyMatch = this.MatchSingleton.[Empty]()

@Vogel612 Appears referencing Empty as a foreign name as shown below works around the RD parsing issue due to Empty being a reserved word. Not enclosing within the [] i.e. Set EmptyMatch = this.MatchSingleton.Empty() still causes a RD parsing error.

''
'@Static
'@Description("Gets the empty group. All failed matches return this empty match.")
''
Public Property Get EmptyMatch() As DotNetLib.Match
   Set EmptyMatch = this.MatchSingleton.[Empty]()
End Property

image

@Vogel612 Vogel612 added antlr Issue is easier to resolve with knowledge of Antlr4 has-workaround There is some way of working around this limitation / bug that is confirmed to work labels Dec 24, 2023
@MarkJohnstoneGitHub
Copy link
Author

MarkJohnstoneGitHub commented Dec 26, 2023

@Vogel612 Where do you find any documentation for VBA referencing as a foreign name. A little rusty on the topic, probably have used it in the ancient past. Educated guess when usually dealing with recordsets. At least the work around fixes the issue.

@Vogel612
Copy link
Member

Vogel612 commented Dec 26, 2023

@MarkJohnstoneGitHub At this point when I'm dealing with grammar issues I look at the MS-VBAL language specification. It used to be a tad more difficult to find, these days it's available as an open specification under https://learn.microsoft.com/en-us/openspecs/microsoft_general_purpose_programming_languages/MS-VBAL/d5418146-0bd2-45eb-9c7a-fd9502722c74

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
antlr Issue is easier to resolve with knowledge of Antlr4 bug Identifies work items for known bugs has-workaround There is some way of working around this limitation / bug that is confirmed to work
Projects
None yet
Development

No branches or pull requests

2 participants