Hi, with 64da7695421acc25143e5d25732d0779ae0c10d0 the whitespaces token (WS) was removed from VisualBasic6.g4. I get the point, that parsing whitespace induces suboptimal parsing performance. However, in Visual Basic 6.0 whitespace is relevant for semantics.
With WS in the grammar SomeProcedure .Name is parsed as ICS_B_ProcedureCall and SomeObject.Name as ICS_B_MemberProcedureCall. Without WS both calls are parsed as ICS_B_MemberProcedureCall.
WITH Customer
SomeProcedure .Name
END WITH
WITH Customer
SomeObject.Name
END WITH
Distinguishing these both cases is relevant for semantic analysis of the AST, i. e. whether to look up procedures or variables. Insofar: Could you please review the commit?
I will certainly review the commit. I suspect that the problem is not with WS but with handling <token>.<token> as a single token rather than two tokens separated by a ".", however I will review.
Hi, with 64da7695421acc25143e5d25732d0779ae0c10d0 the whitespaces token (WS) was removed from VisualBasic6.g4. I get the point, that parsing whitespace induces suboptimal parsing performance. However, in Visual Basic 6.0 whitespace is relevant for semantics.
With WS in the grammar SomeProcedure .Name is parsed as ICS_B_ProcedureCall and SomeObject.Name as ICS_B_MemberProcedureCall. Without WS both calls are parsed as ICS_B_MemberProcedureCall.
Distinguishing these both cases is relevant for semantic analysis of the AST, i. e. whether to look up procedures or variables. Insofar: Could you please review the commit?