1
0
mirror of https://github.com/Ed94/gencpp.git synced 2025-07-13 08:58:59 -07:00
This commit is contained in:
2024-12-16 21:48:01 -05:00
parent 04ae75c698
commit 9c968967e2
28 changed files with 65 additions and 65 deletions

@ -15,7 +15,7 @@ In order to abstract away constant use of `AST*` its wrapped in a Code type whic
When its the [C generated variant of the library](../gen_c_library/)
```c
typedef AST* Code;
tyepdef AST_<name>* Code<name>;
typedef AST_<name>* Code<name>;
...
```

@ -6,7 +6,7 @@
# AST Types Documentation
While the Readme for docs covers the data layout per AST, this will focus on the AST types avaialble, and their nuances.
While the Readme for docs covers the data layout per AST, this will focus on the AST types available, and their nuances.
## Body
@ -37,7 +37,7 @@ s32 NumEntries;
The `Front` member represents the start of the link list and `Back` the end.
NumEntries is the number of entries in the body.
Parent should have a compatible CodeType type for the type of defintion used.
Parent should have a compatible CodeType type for the type of definition used.
Serialization:
@ -95,7 +95,7 @@ Serialization:
<Content>
```
The parser will perserve comments found if residing with a body or in accepted inline-to-definition locations.
The parser will preserve comments found if residing with a body or in accepted inline-to-definition locations.
Otherwise they will be skipped by the TokArray::__eat and TokArray::current( skip foramtting enabled ) functions.
The upfront constructor: `def_comment` expects to recieve a comment without the `//` or `/* */` parts. It will add them during construction.
@ -289,7 +289,7 @@ Serialization:
## Execution
Just represents an execution body. Equivalent to an untyped body.
Will be obsolute when function body parsing is implemented.
Will be obsolete when function body parsing is implemented.
Fields:

@ -4,7 +4,7 @@
<- [docs - General](Readme.md)
# Parser's Algorithim
# Parser's Algorithm
gencpp uses a hand-written recursive descent parser. Both the lexer and parser currently handle a full C/C++ file in a single pass.
@ -399,7 +399,7 @@ Below is an outline of the general alogirithim used for these internal procedure
## `parse_function_after_name`
This is needed as a function defintion is not easily resolvable early on, as such this function handles resolving a function
This is needed as a function definition is not easily resolvable early on, as such this function handles resolving a function
after its been made ceratin that the type of declaration or definition is indeed for a function signature.
By the point this function is called the following are known : export module flag, attributes, specifiers, return type, & name
@ -548,7 +548,7 @@ In the future statements and expressions will be parsed.
### Implementation Constraints
* Cannot definitively distinguish nested namespaces with identical names
* Cannot distinguish nested namespaces with identical names
* Return type detection requires parser enhancement
* Template parameter validation is syntax-based only
* Future enhancement: Implement type parsing with rollback capability
@ -595,7 +595,7 @@ Notes:
## `parse_operator_after_ret_type`
This is needed as a operator defintion is not easily resolvable early on, as such this function handles resolving a operator after its been made ceratin that the type of declaration or definition is indeed for a operator signature.
This is needed as a operator definition is not easily resolvable early on, as such this function handles resolving a operator after its been made ceratin that the type of declaration or definition is indeed for a operator signature.
By the point this function is called the following are known : export module flag, attributes, specifiers, and return type
@ -639,7 +639,7 @@ By the point this function is called the following are known : export module fla
## `parse_operator_function_or_variable`
When this function is called, attribute and specifiers may have been resolved, however what comes next can still be either an operator, function, or varaible.
When this function is called, attribute and specifiers may have been resolved, however what comes next can still be either an operator, function, or variable.
1. Initial Type Resolution
1. Push parsing scope
@ -792,7 +792,7 @@ This will get changed heavily once we have better support for typename expressio
## `parse_variable_after_name`
This is needed as a variable defintion is not easily resolvable early on, it takes a long evaluation period before its known that the declaration or definition is a variable. As such this function handles resolving a variable.
This is needed as a variable definition is not easily resolvable early on, it takes a long evaluation period before its known that the declaration or definition is a variable. As such this function handles resolving a variable.
By the point this function is called the following are known : export module flag, attributes, specifiers, value type, name
1. Initialization Processing
@ -1090,7 +1090,7 @@ Limitations:
This implementatin will be updated in the future to properly handle functional typename signatures.
### Current Algorithim
### Current Algorithm
Anything that is in the qualifier capture of the function typename is treated as an expression abstracted as an untyped string
@ -1119,7 +1119,7 @@ Anything that is in the qualifier capture of the function typename is treated as
8. Check for varaidic argument (param pack) token:
1. Consume varadic argument token
### WIP - Alternative Algorithim
### WIP - Alternative Algorithm
Currently wrapped up via macro: `GEN_USE_NEW_TYPENAME_PARSING`
Anything that is in the qualifier capture of the function typename is treated as an expression abstracted as an untyped string
@ -1152,7 +1152,7 @@ Anything that is in the qualifier capture of the function typename is treated as
7. Check for varaidic argument (param pack) token:
1. Consume varadic argument token
### **Later: Algorithim based on typename expressions**
### **Later: Algorithm based on typename expressions**
## `parse_typedef`

@ -10,7 +10,7 @@ The library features a naive single-pass parser, tailored for only what the libr
This parser does not, and should not do the compiler's job. By only supporting this minimal set of features, the parser is kept (so far) around ~7000 loc. I hope to keep it under 10-15k loc worst case.
You can think of this parser as *frontend parser* vs a *semantic parser*. Its intuitively similar to WYSIWYG. What you ***precerive*** as the syntax from the user-side before the compiler gets a hold of it, is what you get.
You can think of this parser as *frontend parser* vs a *semantic parser*. Its intuitively similar to WYSIWYG. What you ***perceive*** as the syntax from the user-side before the compiler gets a hold of it, is what you get.
User exposed interface:
@ -63,7 +63,7 @@ The preprocessor lines are stored as members of their associated scope they are
Any preprocessor definition abuse that changes the syntax of the core language is unsupported and will fail to parse if not kept within an execution scope (function body, or expression assignment).
Exceptions:
* varaible definitions are allowed for a preprocessed macro `extern MACRO();`
* variable definitions are allowed for a preprocessed macro `extern MACRO();`
* function definitions are allowed for a preprocessed macro: `neverinline MACRO() { ... }`
* Disable with: `#define GEN_PARSER_DISABLE_MACRO_FUNCTION_SIGNATURES`
* typedefs allow for a preprocessed macro: `typedef MACRO();`

@ -260,7 +260,7 @@ def_global_body( args( ht_entry, array_ht_entry, hashtable ));
def_global_body( 3, ht_entry, array_ht_entry, hashtable );
```
If a more incremental approach is desired for the body ASTs, `Code def_body( CodeT type )` can be used to create an empty body.
If a more incremental approach is desired for the body ASTs, `Code def_body( CodeT type )` can be used to create an empty bodyss
When the members have been populated use: `code_validate_body` to verify that the members are valid entires for that type.
### Parse construction
@ -432,7 +432,7 @@ and have the desired specifiers assigned to them beforehand.
## Code generation and modification
There are two provided auxillary interfaces:
There are two provided auxiliary interfaces:
* Builder
* Scanner
@ -444,7 +444,7 @@ There are two provided auxillary interfaces:
* The code is provided via print( code ) function will be serialized to its buffer.
* When all serialization is finished, use the write() command to write the buffer to the file.
### Scanner Auxillary Interface
### Scanner
* The purpose is to scan or parse files
* Some with two basic functions to convert a fil to code: `scan_file` and `parse_file`