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:
2023-09-25 12:12:11 -04:00
parent 4b48b96a79
commit a8708abf8b
18 changed files with 277 additions and 155 deletions

37
docs/AST_Design.md Normal file
View 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;
```

View File

@@ -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>
}

View File

@@ -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.

View File

@@ -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.