| Age | Commit message (Collapse) | Author |
|---|
|
Co-authored-by: Johnny Richard <johnny@johnnyrichard.com>
Signed-off-by: Carlos Maniero <carlosmaniero@gmail.com>
Link: https://lists.sr.ht/~johnnyrichard/pipalang-devel/%3C20230418165847.3798-1-carlosmaniero%40gmail.com%3E
|
|
We want to tokenizer arithmetic expressions.
We are handling exceptional cases with UNKNOWN token.
Co-authored-by: Carlos Maniero <carlosmaniero@gmail.com>
Signed-off-by: Johnny Richard <johnny@johnnyrichard.com>
|
|
make the next token function small by extracting the
functions that make tokens.
Signed-off-by: Carlos Maniero <carlosmaniero@gmail.com>
Reviewed-by: Johnny Richard <johnny@johnnyrichard.com>
|
|
Extracted logic for skipping empty characters into a
separate function. No change in lexer behavior.
Signed-off-by: Carlos Maniero <carlosmaniero@gmail.com>
Reviewed-by: Johnny Richard <johnny@johnnyrichard.com>
|
|
In the future we want to have the possibility of traverse the tree and
pretty print it or generate binary for other platform like LLVM or
transpile to C.
This solution also implements the gas assembly x86_64 Linux code
generation by using the visitor interface.
Signed-off-by: Johnny Richard <johnny@johnnyrichard.com>
|
|
This is an attempt of reducing code duplication.
Signed-off-by: Johnny Richard <johnny@johnnyrichard.com>
|
|
This change fixes the memory leak when token got created.
Signed-off-by: Johnny Richard <johnny@johnnyrichard.com>
|
|
We are allocating heap memory to create tokens value, we can minimize the
number of allocations if we start using string_view.
We have other problems, right now the tokens value ownership are quite
unclear once the AST nodes also share the memory allocation done by
token_get_next_token function.
It's important to clarify we also have memory leaks on the current
implementation. Hence, we are going to start using string_view to make
the memory management easier. :^)
Signed-off-by: Johnny Richard <johnny@johnnyrichard.com>
|
|
Signed-off-by: Johnny Richard <johnny@johnnyrichard.com>
|
|
Signed-off-by: Johnny Richard <johnny@johnnyrichard.com>
|
|
In order to find out where a parsing error occurred, this patch
introduces the exactly location following the format 'file:row:col'.
Signed-off-by: Johnny Richard <johnny@johnnyrichard.com>
|
|
This is a very limited parser implementation which parses a single
function with return type i32 and body containing a return number statement.
The parser doesn't show the 'filepath:row:col' when it fails, a future
improvement would be display it to easy find where the compilation
problem is located.
The ast_nodes are taking the token.value ownership (which is a really
bad design since not all token.value ownership has been taken causing
memory leaking) but we never free them. For a future fix we could use a
string_view instead since we never change the original source code. The
string_view will also improve the performance a lot avoiding unnecessary
heap memory allocation.
Signed-off-by: Johnny Richard <johnny@johnnyrichard.com>
|
|
After enabling the warning flags, the compiler was firing the following
warnings:
warning: implicit declaration of function ‘strdup’; did you mean ‘strcmp’? [-Wimplicit-function-declaration]
token->value = strdup("(");
^~~~~~
strcmp
warning: assignment to ‘char *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
token->value = strdup("(");
^
In order to fix these warnings above, I have decided to replace *strdup*
and *strndup* by *strcpy* and *strncpy* functions.
Signed-off-by: Johnny Richard <johnny@johnnyrichard.com>
|
|
Signed-off-by: Johnny Richard <johnny@johnnyrichard.com>
|
|
We want to have different folders for src and objs files.
Signed-off-by: Johnny Richard <johnny@johnnyrichard.com>
|
