-
Notifications
You must be signed in to change notification settings - Fork 25
Statement providers
Due to the macro definitions, copy file includes and statement generation, it is difficult to determine which statement to process next. For this reason, we define abstraction over various sources of statements called statement providers.
Unlike statement processors, statement providers are ordered based on the priority (lower index, greater priority):
- Macro definition statement provider
- Copy definition statement provider
- Opencode statement provider
In each iteration of the processing manager, providers are asked whether they have statements to provide based on the ordering. That is because after each iteration, a provider with greater priority than the previously used one can be activated.
Processors | Macro provider ends | Copy provider ends | Opencode provider ends |
---|---|---|---|
Opencode | continue | continue | finish |
Copy | finish | continue | finish |
Macro | finish | continue | finish |
Lookahead | finish | continue | finish |
For the main loop to be correctly defined, the end of the opencode provider triggers the terminal condition for all statement processors. Hence, when the opencode provider finishes, all the processors finish as well and the processing ends (see the table above).
In HLASM language, it is difficult to parse statements into one common structure due to its representational ambiguity; the major difference between operand fields of different instruction formats. Moreover, when parsing statements, the instruction format can be yet unknown. Therefore, operand fields are stored as strings. This means that during statement passing when instruction format is deduced, the provider has the responsibility to produce the correct statement format. The following steps are applied in the statement passing (see also the picture below):
-
The provider retrieves the instruction field part of the statement.
-
The provider calls the processor method
get_processing_status
with the instruction field as a parameter. -
The return value of the call determines the required format of the operand field for the processor; the whole statement can be retrieved correctly.
-
The provider returns the correctly formatted statement to the processor.
These providers are activated when a COPY instruction copies a file into the source code or when a macro is visited, respectively. They provide a sequence of statements to an arbitrary processor until all statements from the copy or macro definition are provided. After that, if there is no nested invocation, a provider with a lower priority is selected.
To avoid infinite macro recursion, the HLASM language itself has a restriction for the level of nested macro invocation depending on the complexity of nested macros. We set the limit to 100 as it suffices in all tested code.
For COPY members, recursion is forbidden.
The opencode provider is active as long as there are statements in the source file. It retrieves statements from the source code with the help of the lexer and parser.
The statement field parser is an interface passed to the statement providers by the processing manager. It is implemented by the parser.
At first, it is used during statement passing. In some cases the provider is requested to provide a specific format of a string-stored statement. The string is re-parsed with the according format. Then the field is returned back to the statement provider.
Another use of the field parser is in the opencode processor as model statements are resolved there. After variable symbol substitution, the resulting string field is re-parsed with the field parser.
I. Project overview
II. Component description
-
Language server
4.1 LSP and DAP
4.2 Language server overview
4.3 IO handling
4.4 LSP and DAP server
4.5 Request manager -
Workspace manager
5.1 Parser library API
5.2 Libraries configuration
5.3 Workspace manager overview -
Analyzer
6.1. LSP data collector
6.2. Processing manager
6.2.1 Statement providers
6.2.2 Statement processors
6.2.3 Instruction processors
6.2.4 Expressions
6.3. Instruction format validation
6.4. Lexer
6.5. Parser
6.6. HLASM context tables - Macro tracer
- Extension
III. Dependencies and Build Instructions