Project

General

Profile

Bug #10928

Skip some parsing rules from runtime parsing

Added by Alexandru Lungu 8 months ago. Updated 8 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
Due date:
% Done:

0%

billable:
No
vendor_id:
GCD
case_num:
version_reported:
version_resolved:
reviewer:
production:
No
env_name:
topics:

History

#1 Updated by Alexandru Lungu 8 months ago

In #10919, Danut identified some cases where the conversion database was generated at run-time. This was because certain rules in the grammar called Java code that ended up in DBHelper.connect() (creating folders and the DB). This is being fixed in #10919 by checking at runtime if the conversion context is run-time and simply do not connect to the conversion database and return null / empty collections. Most of the attempts are to check whether a certain OO class exists (or similar use-cases). However, none of these use-cases are possible for run-time conversion.

The goal of this task is to go the extra mile and rule out the parsing step completely and do not attempt to go down a certain parsing rule if the run-time conversion is ongoing. This is similar to how we restrict the rules, to avoid executing some of them for runtime. This should also happen for the parser.

Concretely, primary_expr was trying to match new_phrase, which required sym.canLoadClass(LT(2).getText(). However, the dynamic conversion couldn't possibly hold a new phrase or a class, so this is redundant, yet the parser has this whole overhead. Danut made canLoadClass mostly a no-op for run-time, but the parsing step is still attempted. For other clauses it may make sense to rule out completely (e.g. method_call, function_call, etc.).

Also available in: Atom PDF