-
Notifications
You must be signed in to change notification settings - Fork 16
Add a bit of documentation for typed COBOL AST #576
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
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -38,9 +38,9 @@ type artifacts = | |
|
|
||
| type outputs = | ||
| { | ||
| ptree: Cobol_ptree.compilation_group; | ||
| group: Cobol_unit.Types.group; | ||
| artifacts: artifacts; | ||
| ptree: Cobol_ptree.compilation_group; (* Parse tree to access information missing in the typed AST. Is this field supposed to be stable? Should it only be used to access things that are inaccessible from cobol_unit ? *) | ||
| group: Cobol_unit.Types.group; (* The typed AST view as an unordered set of cobol_unit *) | ||
| artifacts: artifacts; (* Other typing artifacts *) | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Since it is for easing direct access with a pipeline setup it is obviously not mandatory but the question is more: do we want Cobol_typeck clients to see and use this or is it an internal quirk for LSP ? |
||
| } | ||
| type t = outputs | ||
|
|
||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -52,9 +52,12 @@ type unit_config = | |
|
|
||
| (* data items *) | ||
|
|
||
| (** data_definitions exposes two views on the records in DATA DIVISION: | ||
| - [data_items] contains all the fields with direct access by name. | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Note it's not "fields" but "items": an item is either a field or a table, and a table is always anonymous. |
||
| - [data_records] is a list of record trees where each element represent a record root (typically at level 01) *) | ||
|
GBertholon marked this conversation as resolved.
|
||
| type data_definitions = | ||
| { | ||
| data_items: Cobol_data.Types.data_definition named_n_ordered; | ||
| data_items: Cobol_data.Types.data_definition named_n_ordered; (* FIXME: Is the ordered part useful here ? Isn't it already exposed in a more structured way by data_records... *) | ||
| data_records: Cobol_data.Types.record list; | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Here it makes sense to keep the ordered alternative as some data items are anonymous (fillers) and therefore do not belong to the resolution map. Additionally the
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Which information is only accessible through |
||
| } | ||
|
|
||
|
|
@@ -90,8 +93,8 @@ and arg_passing_style = | |
|
|
||
| type procedure = | ||
| { | ||
| procedure_using: procedure_using with_loc option; (* PROCEDURE DIVISION USING ... *) | ||
| procedure_blocks: procedure_block named_n_ordered; | ||
| procedure_using: procedure_using with_loc option; | ||
| } | ||
|
|
||
| (* main *) | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the idea of extending
item_redefinitionsinstead, probably with a record like{ item_redefinitions_redefine: Cobol_ptree.qualname with_loc; item_redefinitions: item_definition wiith_loc nel; }, and then havingfield_redefinitions: item_redefinitions option;or something like that.