mirror of
https://github.com/Ed94/gencpp.git
synced 2025-07-30 00:46:59 -07:00
WIP : Various changes to project before small hiatus. (Broken)
I need to manually review these as the changes have various errors that are difficult to diagnose why. I took a break to do handmade hero and now a bit rusty.
This commit is contained in:
37
docs/AST_Design.md
Normal file
37
docs/AST_Design.md
Normal file
@@ -0,0 +1,37 @@
|
||||
# Forward
|
||||
|
||||
Was never satisfied with how I did the wrap of the management of the AST.
|
||||
For C++, the current design may be as good as it gets for the limitations of the langauge.
|
||||
|
||||
I'll at least try in this issue to brainstorm something simpiler without losing ergonomics.
|
||||
This will also be a good place to document the current design.
|
||||
|
||||
## Current Design
|
||||
|
||||
`AST` is the actual managed node object for the library.
|
||||
Its raw and really not meant to be used directly.
|
||||
|
||||
All user interaction must be with its pointer so the type they deal with is `AST*`.
|
||||
For user-facing code, they should never be giveen a nullptr. Instead, they should be given a designated `Invalid` AST node.
|
||||
|
||||
In order to abstract away constant use of `AST*`, I wanted to provide a wrapper for it.
|
||||
|
||||
The simpliest being just a type alias.
|
||||
|
||||
```cpp
|
||||
using Code = AST*;
|
||||
```
|
||||
|
||||
This is what the genc library would have to use due to its constraints of a langauge.
|
||||
Anything else and it would either be an unergonomic mess of struct wrapping with a mess of macros & procedures to interface with it.
|
||||
|
||||
Further, to provide intuitive filters on the AST, there are AST types (covered in [AST_Types.md](AST_Types.md)).
|
||||
|
||||
These are pure PODS that just have the lay members relevant to the type of AST node they represent.
|
||||
Each of them has a Code type alias specific to it.
|
||||
|
||||
Again, the simpliest case for these would be a type alias.
|
||||
|
||||
```cpp
|
||||
using struct AST_Typedef CodeTypedef;
|
||||
```
|
@@ -1,4 +1,4 @@
|
||||
# ASTs Documentation
|
||||
# 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.
|
||||
|
||||
@@ -95,12 +95,12 @@ The upfront constructor: `def_comment` expects to recieve a comment without the
|
||||
Fields:
|
||||
|
||||
```cpp
|
||||
CodeComment InlineCmt; // Only supported by forward declarations
|
||||
CodeComment InlineCmt; // Only supported by forward declarations
|
||||
CodeAttributes Attributes;
|
||||
CodeType ParentType;
|
||||
CodeBody Body;
|
||||
CodeType Last; // Used to store references to interfaces
|
||||
CodeType Next; // Used to store references to interfaces
|
||||
CodeType Prev; // Used to store references to interfaces
|
||||
CodeType Next; // Used to store references to interfaces
|
||||
Code Parent;
|
||||
StringCached Name;
|
||||
CodeT Type;
|
||||
@@ -115,7 +115,7 @@ Serialization:
|
||||
<ModuleFlags> <class/struct> <Name>; <InlineCmt>
|
||||
|
||||
// Class
|
||||
<ModuleFlags> <class/struct> <Attributes> <Name> : <ParentAccess> <ParentType>, public <Next>, ...<Last>
|
||||
<ModuleFlags> <class/struct> <Attributes> <Name> : <ParentAccess> <ParentType>, public <ParentType->Next>, ... <InlineCmt>
|
||||
{
|
||||
<Body>
|
||||
};
|
||||
@@ -145,7 +145,8 @@ Serialization:
|
||||
<Specs> <Parent->Name>( <Params> ); <InlineCmt>
|
||||
|
||||
// Constructor
|
||||
<Specs> <Parent->Name>( <Params> ): <InitializerList>
|
||||
<Specs> <Parent->Name>( <Params> ) <InlineCmt>
|
||||
: <InitializerList>
|
||||
{
|
||||
<Body>
|
||||
}
|
@@ -67,7 +67,6 @@ Adding your own exceptions is possible by simply modifying the parser to allow f
|
||||
|
||||
*Note: You could interpret this strictness as a feature. This would allow the user to see if their codebase or a third-party's codebase some some egregious preprocessor abuse.*
|
||||
|
||||
|
||||
The lexing and parsing takes shortcuts from whats expected in the standard.
|
||||
|
||||
* Numeric literals are not checked for validity.
|
||||
@@ -80,4 +79,3 @@ The lexing and parsing takes shortcuts from whats expected in the standard.
|
||||
* Parsing attributes can be extended to support user defined macros by defining `GEN_DEFINE_ATTRIBUTE_TOKENS` (see `gen.hpp` for the formatting)
|
||||
|
||||
Empty lines used throughout the file are preserved for formatting purposes during ast serialization.
|
||||
|
||||
|
@@ -42,6 +42,7 @@ Otherwise the library is free of any templates.
|
||||
|
||||
**There is no support for validating expressions.**
|
||||
Its difficult to parse without enough benefits (At the metaprogramming level).
|
||||
I plan to add this only at the tail of the project parsing milestone.
|
||||
|
||||
**Only trivial template support is provided.**
|
||||
The intention is for only simple, non-recursive substitution.
|
||||
|
Reference in New Issue
Block a user