[olang/patches/.build.yml] build success

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 49s

[create initial syntax analysis logic][0] from [Johnny Richard][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/49873
[1]: mailto:johnny@johnnyrichard.com

✓ #1159030 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1159030

[PATCH olang v1 0/4] create initial syntax analysis logic

[Johnny Richard]

This patchset implements the initial syntax analysis logic for a small
portion of the language.

Since the type system contains only a u32 type, the semantic analysis
can be postponed.

In terms of Abstract Syntax Tree, this patchset also introduces a very
basic AST data structure.

Johnny Richard (4):
  string_view: add string view formatter for printf fmt
  string_view: add string view conversion to uint32_t
  lexer: add token lookahead capability
  parser: create simplified parser for tiny AST

 src/ast.c                     |  79 ++++++++++++++
 src/ast.h                     | 101 ++++++++++++++++++
 src/lexer.c                   |  38 +++++++
 src/lexer.h                   |  10 ++
 src/parser.c                  | 193 ++++++++++++++++++++++++++++++++++
 src/parser.h                  |  38 +++++++
 src/string_view.c             |  11 ++
 src/string_view.h             |   8 +-
 tests/unit/parser_test.c      |  88 ++++++++++++++++
 tests/unit/string_view_test.c |  61 +++++++++++
 10 files changed, 626 insertions(+), 1 deletion(-)
 create mode 100644 src/ast.c
 create mode 100644 src/ast.h
 create mode 100644 src/parser.c
 create mode 100644 src/parser.h
 create mode 100644 tests/unit/parser_test.c
 create mode 100644 tests/unit/string_view_test.c

-- 
2.43.2

[PATCH olang v1 1/4] string_view: add string view formatter for printf fmt

[Johnny Richard]

Signed-off-by: Johnny Richard <johnny@johnnyrichard.com>
---
 src/string_view.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/src/string_view.h b/src/string_view.h
index 367ef6b..a212ab9 100644
--- a/src/string_view.h
+++ b/src/string_view.h
@@ -19,6 +19,10 @@
 
 #include <stdbool.h>
 #include <stddef.h>
+#include <stdint.h>
+
+#define SV_FMT "%.*s"
+#define SV_ARG(sv) (int)(sv).size, (sv).chars
 
 typedef struct string_view
 {
-- 
2.43.2

[PATCH olang v1 2/4] string_view: add string view conversion to uint32_t

[Johnny Richard]

Signed-off-by: Johnny Richard <johnny@johnnyrichard.com>
---
 src/string_view.c             | 11 +++++++
 src/string_view.h             |  4 ++-
 tests/unit/string_view_test.c | 61 +++++++++++++++++++++++++++++++++++
 3 files changed, 75 insertions(+), 1 deletion(-)
 create mode 100644 tests/unit/string_view_test.c

diff --git a/src/string_view.c b/src/string_view.c
index 122eaa2..58bf197 100644
--- a/src/string_view.c
+++ b/src/string_view.c
@@ -17,6 +17,8 @@
 #include "string_view.h"
 
 #include <stdbool.h>
+#include <stdint.h>
+#include <stdlib.h>
 #include <string.h>
 
 bool
@@ -33,3 +35,12 @@ string_view_eq_to_cstr(string_view_t str, char *cstr)
     }
     return i == cstr_len;
 }
+
+uint32_t
+string_view_to_u32(string_view_t str)
+{
+    char ret[str.size + 1];
+    memset(ret, 0, str.size + 1);
+    memcpy(ret, str.chars, str.size);
+    return atoi(ret);
+}
diff --git a/src/string_view.h b/src/string_view.h
index a212ab9..d5d2e6c 100644
--- a/src/string_view.h
+++ b/src/string_view.h
@@ -31,8 +31,10 @@ typedef struct string_view
 
 } string_view_t;
 
-// TODO: missing unit test
 bool
 string_view_eq_to_cstr(string_view_t str, char *cstr);
 
+uint32_t
+string_view_to_u32(string_view_t str);
+
 #endif /* STRING_VIEW_T */
diff --git a/tests/unit/string_view_test.c b/tests/unit/string_view_test.c
new file mode 100644
index 0000000..b5d1fcf
--- /dev/null
+++ b/tests/unit/string_view_test.c
@@ -0,0 +1,61 @@
+/*
+ * Copyright (C) 2024 olang maintainers
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <https://www.gnu.org/licenses/>.
+ */
+#define MUNIT_ENABLE_ASSERT_ALIASES
+#include "munit.h"
+#include "string_view.h"
+
+#include <string.h>
+
+static MunitResult
+string_view_eq_to_cstr_test(const MunitParameter params[], void *user_data_or_fixture)
+{
+    char *name = "John Doe";
+
+    string_view_t str = { .chars = name, .size = strlen(name) };
+
+    assert_true(string_view_eq_to_cstr(str, "John Doe"));
+    assert_false(string_view_eq_to_cstr(str, "Doe"));
+
+    return MUNIT_OK;
+}
+
+static MunitResult
+string_view_to_u32_test(const MunitParameter params[], void *user_data_or_fixture)
+{
+    char *number = "69";
+
+    string_view_t str = { .chars = number, .size = strlen(number) };
+
+    assert_uint32(string_view_to_u32(str), ==, 69);
+
+    return MUNIT_OK;
+}
+
+static MunitTest tests[] = {
+    { "/eq_to_cstr_test", string_view_eq_to_cstr_test, NULL, NULL, MUNIT_TEST_OPTION_NONE, NULL },
+    { "/to_u32_test", string_view_to_u32_test, NULL, NULL, MUNIT_TEST_OPTION_NONE, NULL },
+    { NULL, NULL, NULL, NULL, MUNIT_TEST_OPTION_NONE, NULL }
+};
+
+static const MunitSuite suite = { "/string_view", tests, NULL, 1, MUNIT_SUITE_OPTION_NONE };
+
+int
+main(int argc, char *argv[])
+{
+    return munit_suite_main(&suite, NULL, argc, argv);
+    return EXIT_SUCCESS;
+}
-- 
2.43.2

[PATCH olang v1 3/4] lexer: add token lookahead capability

[Johnny Richard]

In order to skip line breaks (LF) we have to be able to spy the next
token without consume it.

This patch also adds a function to **lexer_peek_next** token, which is
equivalent to **lexer_look_ahead(n = 1)**.

Signed-off-by: Johnny Richard <johnny@johnnyrichard.com>
---
 src/lexer.c | 22 ++++++++++++++++++++++
 src/lexer.h |  6 ++++++
 2 files changed, 28 insertions(+)

diff --git a/src/lexer.c b/src/lexer.c
index b107762..c7756a6 100644
--- a/src/lexer.c
+++ b/src/lexer.c
@@ -233,3 +233,25 @@ lexer_str_to_token_kind(string_view_t text)
 
     return TOKEN_IDENTIFIER;
 }
+
+void
+lexer_peek_next(lexer_t *lexer, token_t *token)
+{
+    lexer_lookahead(lexer, token, 1);
+}
+
+void
+lexer_lookahead(lexer_t *lexer, token_t *token, size_t n)
+{
+    size_t previous_offset = lexer->offset;
+    size_t previous_row = lexer->row;
+    size_t previous_bol = lexer->bol;
+
+    for (size_t i = 0; i < n; ++i) {
+        lexer_next_token(lexer, token);
+    }
+
+    lexer->offset = previous_offset;
+    lexer->row = previous_row;
+    lexer->bol = previous_bol;
+}
diff --git a/src/lexer.h b/src/lexer.h
index 8c09e02..729c957 100644
--- a/src/lexer.h
+++ b/src/lexer.h
@@ -68,6 +68,12 @@ lexer_init(lexer_t *lexer, string_view_t source);
 void
 lexer_next_token(lexer_t *lexer, token_t *token);
 
+void
+lexer_peek_next(lexer_t *lexer, token_t *token);
+
+void
+lexer_lookahead(lexer_t *lexer, token_t *token, size_t n);
+
 char *
 token_kind_to_cstr(token_kind_t kind);
 
-- 
2.43.2

[PATCH olang v1 4/4] parser: create simplified parser for tiny AST

[Johnny Richard]

This commit introduces a simple and restricted parser designed to handle
a small program structure. Its purpose is to lay the foundation for
future optimizations.

Error handling during syntax analysis is rudimentary. If an error
occurs, it will be printed, and the program will abort without further
parsing to detect additional syntax errors.

Additionally, it's important to note that semantic analysis will be
conducted at a later stage in the compiler pipeline. As only u32 type is
currently implemented, a separate type checker will not be developed.
Consequently, the AST generated during syntax analysis can be directly
passed to the backend.

Signed-off-by: Johnny Richard <johnny@johnnyrichard.com>
---
 src/ast.c                |  79 ++++++++++++++++
 src/ast.h                | 101 ++++++++++++++++++++
 src/lexer.c              |  16 ++++
 src/lexer.h              |   4 +
 src/parser.c             | 193 +++++++++++++++++++++++++++++++++++++++
 src/parser.h             |  38 ++++++++
 tests/unit/parser_test.c |  88 ++++++++++++++++++
 7 files changed, 519 insertions(+)
 create mode 100644 src/ast.c
 create mode 100644 src/ast.h
 create mode 100644 src/parser.c
 create mode 100644 src/parser.h
 create mode 100644 tests/unit/parser_test.c

diff --git a/src/ast.c b/src/ast.c
new file mode 100644
index 0000000..ad3124d
--- /dev/null
+++ b/src/ast.c
@@ -0,0 +1,79 @@
+/*
+ * Copyright (C) 2024 olang maintainers
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <https://www.gnu.org/licenses/>.
+ */
+
+#include <assert.h>
+#include <stdint.h>
+
+#include "arena.h"
+#include "ast.h"
+#include "string_view.h"
+
+ast_node_t *
+ast_make_node_fn_def(arena_t *arena, string_view_t identifier, type_t return_type, ast_node_t *block)
+{
+    ast_node_t *node_fn_def = (ast_node_t *)arena_alloc(arena, sizeof(ast_node_t));
+    assert(node_fn_def);
+
+    node_fn_def->kind = AST_NODE_FN_DEF;
+    ast_fn_definition_t *fn_def = &node_fn_def->data.as_fn_def;
+
+    fn_def->identifier = identifier;
+    fn_def->return_type = return_type;
+    fn_def->block = block;
+
+    return node_fn_def;
+}
+
+ast_node_t *
+ast_make_node_literal_u32(arena_t *arena, uint32_t value)
+{
+    ast_node_t *node_literal = (ast_node_t *)arena_alloc(arena, sizeof(ast_node_t));
+    assert(node_literal);
+
+    node_literal->kind = AST_NODE_LITERAL;
+    node_literal->data.as_literal.kind = AST_LITERAL_U32;
+    node_literal->data.as_literal.value.as_u32 = value;
+
+    return node_literal;
+}
+
+ast_node_t *
+ast_make_node_return_stmt(arena_t *arena)
+{
+    ast_node_t *node_return_stmt = (ast_node_t *)arena_alloc(arena, sizeof(ast_node_t));
+    assert(node_return_stmt);
+
+    node_return_stmt->kind = AST_NODE_RETURN_STMT;
+
+    return node_return_stmt;
+}
+
+ast_node_t *
+ast_make_node_block(arena_t *arena)
+{
+    ast_node_t *node_block = (ast_node_t *)arena_alloc(arena, sizeof(ast_node_t));
+    assert(node_block);
+
+    node_block->kind = AST_NODE_BLOCK;
+
+    node_block->data.as_block.nodes = (list_t *)arena_alloc(arena, sizeof(list_t));
+    assert(node_block->data.as_block.nodes);
+
+    list_init(node_block->data.as_block.nodes, arena);
+
+    return node_block;
+}
diff --git a/src/ast.h b/src/ast.h
new file mode 100644
index 0000000..b80c067
--- /dev/null
+++ b/src/ast.h
@@ -0,0 +1,101 @@
+/*
+ * Copyright (C) 2024 olang maintainers
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <https://www.gnu.org/licenses/>.
+ */
+#ifndef AST_H
+#define AST_H
+
+#include <stdint.h>
+
+#include "arena.h"
+#include "list.h"
+#include "string_view.h"
+
+typedef struct ast_node ast_node_t;
+
+typedef enum
+{
+    AST_NODE_BLOCK,
+    AST_NODE_FN_DEF,
+    AST_NODE_RETURN_STMT,
+    AST_NODE_LITERAL,
+    AST_NODE_UNKNOWN
+} ast_node_kind_t;
+
+typedef enum
+{
+    TYPE_U32
+} type_t;
+
+typedef struct ast_block
+{
+    list_t *nodes;
+} ast_block_t;
+
+typedef struct ast_fn_definition
+{
+    string_view_t identifier;
+    type_t return_type;
+    ast_node_t *block;
+} ast_fn_definition_t;
+
+typedef enum
+{
+    AST_LITERAL_U32
+} ast_literal_kind_t;
+
+typedef union
+{
+    uint32_t as_u32;
+} ast_literal_value_t;
+
+typedef struct ast_literal
+{
+    ast_literal_kind_t kind;
+    ast_literal_value_t value;
+} ast_literal_t;
+
+typedef struct ast_return_stmt
+{
+    ast_node_t *data;
+} ast_return_stmt_t;
+
+typedef union
+{
+    ast_fn_definition_t as_fn_def;
+    ast_literal_t as_literal;
+    ast_block_t as_block;
+    ast_return_stmt_t as_return_stmt;
+} ast_node_data_t;
+
+typedef struct ast_node
+{
+    ast_node_kind_t kind;
+    ast_node_data_t data;
+} ast_node_t;
+
+ast_node_t *
+ast_make_node_fn_def(arena_t *arena, string_view_t identifier, type_t return_type, ast_node_t *block);
+
+ast_node_t *
+ast_make_node_literal_u32(arena_t *arena, uint32_t value);
+
+ast_node_t *
+ast_make_node_return_stmt(arena_t *arena);
+
+ast_node_t *
+ast_make_node_block(arena_t *arena);
+
+#endif /* AST_H */
diff --git a/src/lexer.c b/src/lexer.c
index c7756a6..e9e97d4 100644
--- a/src/lexer.c
+++ b/src/lexer.c
@@ -19,6 +19,7 @@
 #include <assert.h>
 #include <ctype.h>
 #include <stdbool.h>
+#include <stdio.h>
 
 void
 lexer_init(lexer_t *lexer, string_view_t source)
@@ -255,3 +256,18 @@ lexer_lookahead(lexer_t *lexer, token_t *token, size_t n)
     lexer->row = previous_row;
     lexer->bol = previous_bol;
 }
+
+void
+lexer_print_token_highlight(lexer_t *lexer, token_t *token, FILE *stream)
+{
+    size_t offset = token->location.bol;
+    char *str = lexer->source.chars + offset;
+
+    size_t i = 0;
+    while ((i + offset) < lexer->source.size && str[i] != '\n' && str[i] != 0) {
+        ++i;
+    }
+    string_view_t line = { .chars = str, .size = i };
+    fprintf(stream, "" SV_FMT "\n", SV_ARG(line));
+    fprintf(stream, "%*s\n", (int)(token->location.offset - token->location.bol + 1), "^");
+}
diff --git a/src/lexer.h b/src/lexer.h
index 729c957..d836b91 100644
--- a/src/lexer.h
+++ b/src/lexer.h
@@ -19,6 +19,7 @@
 
 #include "string_view.h"
 #include <stdint.h>
+#include <stdio.h>
 
 typedef struct lexer
 {
@@ -77,4 +78,7 @@ lexer_lookahead(lexer_t *lexer, token_t *token, size_t n);
 char *
 token_kind_to_cstr(token_kind_t kind);
 
+void
+lexer_print_token_highlight(lexer_t *lexer, token_t *token, FILE *stream);
+
 #endif /* LEXER_H */
diff --git a/src/parser.c b/src/parser.c
new file mode 100644
index 0000000..f50b61a
--- /dev/null
+++ b/src/parser.c
@@ -0,0 +1,193 @@
+/*
+ * Copyright (C) 2024 olang maintainers
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <https://www.gnu.org/licenses/>.
+ */
+
+#include <assert.h>
+#include <stdbool.h>
+#include <stdio.h>
+#include <string.h>
+
+#include "lexer.h"
+#include "parser.h"
+
+static bool
+skip_expected_token(parser_t *parser, token_kind_t expected_kind);
+
+static bool
+expected_token(parser_t *parser, token_t *token, token_kind_t kind);
+
+static bool
+parser_parse_type(parser_t *parser, type_t *type);
+
+static ast_node_t *
+parser_parse_block(parser_t *parser);
+
+static void
+skip_line_feeds(lexer_t *lexer);
+
+void
+parser_init(parser_t *parser, lexer_t *lexer, arena_t *arena, char *file_path)
+{
+    assert(parser && "parser is required");
+    assert(lexer && "lexer is required");
+    assert(file_path && "file_path is required");
+    parser->lexer = lexer;
+    parser->arena = arena;
+    parser->file_path = file_path;
+}
+
+ast_node_t *
+parser_parse_fn_definition(parser_t *parser)
+{
+    if (!skip_expected_token(parser, TOKEN_FN))
+        return NULL;
+
+    skip_line_feeds(parser->lexer);
+
+    token_t fn_name_token;
+
+    if (!expected_token(parser, &fn_name_token, TOKEN_IDENTIFIER))
+        return NULL;
+
+    skip_line_feeds(parser->lexer);
+
+    if (!skip_expected_token(parser, TOKEN_OPAREN))
+        return NULL;
+
+    skip_line_feeds(parser->lexer);
+
+    if (!skip_expected_token(parser, TOKEN_CPAREN))
+        return NULL;
+
+    skip_line_feeds(parser->lexer);
+
+    if (!skip_expected_token(parser, TOKEN_COLON))
+        return NULL;
+
+    skip_line_feeds(parser->lexer);
+
+    type_t fn_return_type;
+    if (!parser_parse_type(parser, &fn_return_type)) {
+        return NULL;
+    }
+
+    skip_line_feeds(parser->lexer);
+
+    ast_node_t *block = parser_parse_block(parser);
+    if (block == NULL) {
+        return NULL;
+    }
+
+    return ast_make_node_fn_def(parser->arena, fn_name_token.value, fn_return_type, block);
+}
+
+static bool
+parser_parse_type(parser_t *parser, type_t *type)
+{
+    token_t token;
+
+    if (!expected_token(parser, &token, TOKEN_IDENTIFIER)) {
+        return false;
+    }
+
+    if (string_view_eq_to_cstr(token.value, "u32")) {
+        *type = TYPE_U32;
+        return true;
+    }
+
+    return false;
+}
+
+static ast_node_t *
+parser_parse_block(parser_t *parser)
+{
+    token_t number_token;
+    if (!skip_expected_token(parser, TOKEN_OCURLY)) {
+        return false;
+    }
+
+    skip_line_feeds(parser->lexer);
+
+    ast_node_t *node_block = ast_make_node_block(parser->arena);
+
+    if (!skip_expected_token(parser, TOKEN_RETURN)) {
+        return false;
+    }
+
+    ast_node_t *node_return_stmt = ast_make_node_return_stmt(parser->arena);
+    assert(node_return_stmt);
+
+    if (!expected_token(parser, &number_token, TOKEN_NUMBER)) {
+        return false;
+    }
+
+    ast_node_t *literal_node = ast_make_node_literal_u32(parser->arena, string_view_to_u32(number_token.value));
+    assert(literal_node);
+
+    node_return_stmt->data.as_return_stmt.data = literal_node;
+
+    list_append(node_block->data.as_block.nodes, node_return_stmt);
+
+    if (!skip_expected_token(parser, TOKEN_LF)) {
+        return false;
+    }
+
+    skip_line_feeds(parser->lexer);
+
+    if (!skip_expected_token(parser, TOKEN_CCURLY)) {
+        return false;
+    }
+
+    return node_block;
+}
+
+static bool
+skip_expected_token(parser_t *parser, token_kind_t expected_kind)
+{
+    token_t token;
+    return expected_token(parser, &token, expected_kind);
+}
+
+static bool
+expected_token(parser_t *parser, token_t *token, token_kind_t expected_kind)
+{
+    lexer_next_token(parser->lexer, token);
+
+    if (token->kind != expected_kind) {
+        fprintf(stderr,
+                "%s:%lu:%lu: error: got <%s> token but expect <%s>\n",
+                parser->file_path,
+                token->location.row + 1,
+                (token->location.offset - token->location.bol) + 1,
+                token_kind_to_cstr(token->kind),
+                token_kind_to_cstr(expected_kind));
+        lexer_print_token_highlight(parser->lexer, token, stderr);
+        return false;
+    }
+    return true;
+}
+
+static void
+skip_line_feeds(lexer_t *lexer)
+{
+    token_t token;
+    lexer_peek_next(lexer, &token);
+
+    while (token.kind == TOKEN_LF) {
+        lexer_next_token(lexer, &token);
+        lexer_peek_next(lexer, &token);
+    }
+}
diff --git a/src/parser.h b/src/parser.h
new file mode 100644
index 0000000..3f1a00b
--- /dev/null
+++ b/src/parser.h
@@ -0,0 +1,38 @@
+/*
+ * Copyright (C) 2024 olang maintainers
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <https://www.gnu.org/licenses/>.
+ */
+#ifndef PARSER_H
+#define PARSER_H
+
+#include "arena.h"
+#include "ast.h"
+#include "lexer.h"
+
+typedef struct parser
+{
+    lexer_t *lexer;
+    arena_t *arena;
+    // TODO: we should define a better place to file_path string
+    char *file_path;
+} parser_t;
+
+void
+parser_init(parser_t *parser, lexer_t *lexer, arena_t *arena, char *file_path);
+
+ast_node_t *
+parser_parse_fn_definition(parser_t *parser);
+
+#endif /* PARSER_H */
diff --git a/tests/unit/parser_test.c b/tests/unit/parser_test.c
new file mode 100644
index 0000000..32ebc8e
--- /dev/null
+++ b/tests/unit/parser_test.c
@@ -0,0 +1,88 @@
+/*
+ * Copyright (C) 2024 olang maintainers
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <https://www.gnu.org/licenses/>.
+ */
+#define MUNIT_ENABLE_ASSERT_ALIASES
+
+#include "arena.h"
+#include "ast.h"
+#include "lexer.h"
+#include "list.h"
+#include "munit.h"
+#include "parser.h"
+#include "string_view.h"
+
+#define ARENA_CAPACITY (1024 * 1024)
+
+static MunitResult
+parse_fn_definition_test(const MunitParameter params[], void *user_data_or_fixture)
+{
+    arena_t arena = arena_new(ARENA_CAPACITY);
+
+    char *file_path = "main.0";
+    char *source_value = "fn main(): u32 {\n\treturn 69\n}";
+
+    lexer_t lexer;
+    string_view_t source = { .chars = source_value, .size = strlen(source_value) };
+    lexer_init(&lexer, source);
+
+    parser_t parser;
+    parser_init(&parser, &lexer, &arena, file_path);
+
+    ast_node_t *node_fn_def = parser_parse_fn_definition(&parser);
+    assert_not_null(node_fn_def);
+    assert_uint(node_fn_def->kind, ==, AST_NODE_FN_DEF);
+
+    ast_fn_definition_t *fn = &node_fn_def->data.as_fn_def;
+    assert_memory_equal(fn->identifier.size, fn->identifier.chars, "main");
+    assert_uint(fn->return_type, ==, TYPE_U32);
+
+    ast_node_t *block = fn->block;
+    assert_not_null(block);
+
+    assert_uint(block->kind, ==, AST_NODE_BLOCK);
+    assert_uint(list_size(block->data.as_block.nodes), ==, 1);
+    list_item_t *block_item = list_get(block->data.as_block.nodes, 0);
+    assert_not_null(block_item);
+    assert_not_null(block_item->value);
+
+    ast_node_t *node = (ast_node_t *)block_item->value;
+    assert_not_null(node);
+    assert_uint(node->kind, ==, AST_NODE_RETURN_STMT);
+
+    ast_node_t *number_node = node->data.as_return_stmt.data;
+    assert_not_null(number_node);
+    assert_uint(number_node->kind, ==, AST_NODE_LITERAL);
+    assert_uint(number_node->data.as_literal.kind, ==, AST_LITERAL_U32);
+    assert_uint(number_node->data.as_literal.value.as_u32, ==, 69);
+
+    arena_free(&arena);
+
+    return MUNIT_OK;
+}
+
+static MunitTest tests[] = {
+    { "/parse_fn_definition", parse_fn_definition_test, NULL, NULL, MUNIT_TEST_OPTION_NONE, NULL },
+    { NULL, NULL, NULL, NULL, MUNIT_TEST_OPTION_NONE, NULL }
+};
+
+static const MunitSuite suite = { "/parser", tests, NULL, 1, MUNIT_SUITE_OPTION_NONE };
+
+int
+main(int argc, char *argv[])
+{
+    return munit_suite_main(&suite, NULL, argc, argv);
+    return EXIT_SUCCESS;
+}
-- 
2.43.2

Re: [PATCH olang v1 2/4] string_view: add string view conversion to uint32_t

[Carlos Maniero]

First of all, thank you for adding tests to *string_view*. I've just
a few small adjustments to ask:

> +    memset(ret, 0, str.size + 1);
> +    memcpy(ret, str.chars, str.size);
This will iterate *str.size* times twice. Instead of using *memset* you
could only set the *NULL terminator* as the last char of *ret*.

> +static MunitResult
> +string_view_eq_to_cstr_test(const MunitParameter params[], void *user_data_or_fixture)
> +{
> +    char *name = "John Doe";
> +
> +    string_view_t str = { .chars = name, .size = strlen(name) };
> +
> +    assert_true(string_view_eq_to_cstr(str, "John Doe"));
> +    assert_false(string_view_eq_to_cstr(str, "Doe"));
> +
> +    return MUNIT_OK;
> +}
It would be great if you add also a test taking just a portion of the
string to make sure the *.size* is working.

> +static MunitResult
> +string_view_to_u32_test(const MunitParameter params[], void *user_data_or_fixture)
> +{
> +    char *number = "69";
> +
> +    string_view_t str = { .chars = number, .size = strlen(number) };
> +
> +    assert_uint32(string_view_to_u32(str), ==, 69);
> +
> +    return MUNIT_OK;
> +}
Same here. Instead of taking the entire number you can get just a digit.

Re: [PATCH olang v1 2/4] string_view: add string view conversion to uint32_t

[Johnny Richard]

On Thu, Feb 29, 2024 at 12:16:07PM -0300, Carlos Maniero wrote:
> > +    memset(ret, 0, str.size + 1);
> > +    memcpy(ret, str.chars, str.size);
> This will iterate *str.size* times twice. Instead of using *memset* you
> could only set the *NULL terminator* as the last char of *ret*.

Sure, I will fix it in an other revision.

> > +static MunitResult
> > +string_view_eq_to_cstr_test(const MunitParameter params[], void *user_data_or_fixture)
> > +{
> > +    char *name = "John Doe";
> > +
> > +    string_view_t str = { .chars = name, .size = strlen(name) };
> > +
> > +    assert_true(string_view_eq_to_cstr(str, "John Doe"));
> > +    assert_false(string_view_eq_to_cstr(str, "Doe"));
> > +
> > +    return MUNIT_OK;
> > +}
> It would be great if you add also a test taking just a portion of the
> string to make sure the *.size* is working.

Hmm... I think it's better to create a separated test for this.

> > +static MunitResult
> > +string_view_to_u32_test(const MunitParameter params[], void *user_data_or_fixture)
> > +{
> > +    char *number = "69";
> > +
> > +    string_view_t str = { .chars = number, .size = strlen(number) };
> > +
> > +    assert_uint32(string_view_to_u32(str), ==, 69);
> > +
> > +    return MUNIT_OK;
> > +}
> Same here. Instead of taking the entire number you can get just a digit.

I will create another test for this.  Something like test create slice over cstr.

Re: [PATCH olang v1 4/4] parser: create simplified parser for tiny AST

[Carlos Maniero]

> +ast_node_t *
> +ast_make_node_fn_def(arena_t *arena, string_view_t identifier, type_t return_type, ast_node_t *block);
> +
> +ast_node_t *
> +ast_make_node_literal_u32(arena_t *arena, uint32_t value);
> +
> +ast_node_t *
> +ast_make_node_return_stmt(arena_t *arena);
> +
> +ast_node_t *
> +ast_make_node_block(arena_t *arena);

s/ast_make/ast_new just to keep consistency with other functions that
allocate memory.

> +void
> +lexer_print_token_highlight(lexer_t *lexer, token_t *token, FILE *stream)
> +{
> +    size_t offset = token->location.bol;
> +    char *str = lexer->source.chars + offset;
> +
> +    size_t i = 0;
> +    while ((i + offset) < lexer->source.size && str[i] != '\n' && str[i] != 0) {
> +        ++i;
> +    }
> +    string_view_t line = { .chars = str, .size = i };
> +    fprintf(stream, "" SV_FMT "\n", SV_ARG(line));
> +    fprintf(stream, "%*s\n", (int)(token->location.offset - token->location.bol + 1), "^");
> +}

1. It bothers me a little that the lexer is performing IO operations.
   IMO, the parser should be responsible for error handling. But I can live
   with this if you think this is the right place for this function.

2. An alternative is making the lexer returning the line *string_view*
   and make the parser do the rest.

3. nitpick: Isn't *(i + offset) < lexer->source.size* and *str[i] != 0*
   redundant? The last char will (or at least should) always be a NULL
   terminator.

4. I spent some time trying to understand what this function was
   supposed to do. I believe that having a function that just returns
   the token's line could help (2). But an alternative here is using the
   *string_view* struct instead of having *str* and *i*. Something like
   this:

     void
     lexer_print_token_highlight(lexer_t *lexer, token_t *token, FILE *stream)
     {
         size_t offset = token->location.bol;
         string_view_t line = { .chars = lexer->source.chars + offset, .size = 0 };
     
         while (line.chars[i] != '\n' && line.chars[i] != 0) {
             ++line.size;
         }

         fprintf(stream, "" SV_FMT "\n", SV_ARG(line));
         fprintf(stream, "%*s\n", (int)(token->location.offset - token->location.bol + 1), "^");
     }

> +    if (!skip_expected_token(parser, TOKEN_COLON))
> +        return NULL;
> +
> +    skip_line_feeds(parser->lexer);
> +
> +    type_t fn_return_type;
> +    if (!parser_parse_type(parser, &fn_return_type)) {
> +        return NULL;
> +    }

nitpick: I’ve spotted some inconsistency with the use of brackets in
if statements. Just throwing it out there, but I believe we should be
using brackets in all if statements. However, I’m totally fine with
removing them in guard clauses, as long as we maintain a consistent
style.

This is great work man! I'm excited of how close we are now from start
the back-end.

Re: [PATCH olang v1 4/4] parser: create simplified parser for tiny AST

[Johnny Richard]

On Fri, Mar 01, 2024 at 12:34:59AM -0300, Carlos Maniero wrote:
> > +ast_node_t *
> > +ast_make_node_fn_def(arena_t *arena, string_view_t identifier, type_t return_type, ast_node_t *block);
> > +
> > +ast_node_t *
> > +ast_make_node_literal_u32(arena_t *arena, uint32_t value);
> > +
> > +ast_node_t *
> > +ast_make_node_return_stmt(arena_t *arena);
> > +
> > +ast_node_t *
> > +ast_make_node_block(arena_t *arena);
> 
> s/ast_make/ast_new just to keep consistency with other functions that
> allocate memory.

Sure!

> > +void
> > +lexer_print_token_highlight(lexer_t *lexer, token_t *token, FILE *stream)
> > +{
> > +    size_t offset = token->location.bol;
> > +    char *str = lexer->source.chars + offset;
> > +
> > +    size_t i = 0;
> > +    while ((i + offset) < lexer->source.size && str[i] != '\n' && str[i] != 0) {
> > +        ++i;
> > +    }
> > +    string_view_t line = { .chars = str, .size = i };
> > +    fprintf(stream, "" SV_FMT "\n", SV_ARG(line));
> > +    fprintf(stream, "%*s\n", (int)(token->location.offset - token->location.bol + 1), "^");
> > +}
> 
> 1. It bothers me a little that the lexer is performing IO operations.
>    IMO, the parser should be responsible for error handling. But I can live
>    with this if you think this is the right place for this function.

After analise the code and think about the future typechecker
implementation I kind agree with you, I will change in the next patch.

> 2. An alternative is making the lexer returning the line *string_view*
>    and make the parser do the rest.

Great, I will do that.

> 3. nitpick: Isn't *(i + offset) < lexer->source.size* and *str[i] != 0*
>    redundant? The last char will (or at least should) always be a NULL
>    terminator.

I will keep the check, I don't see a problem on keeping it.  This will
make the code more resilient in case of bugs.

> 4. I spent some time trying to understand what this function was
>    supposed to do. I believe that having a function that just returns
>    the token's line could help (2). But an alternative here is using the
>    *string_view* struct instead of having *str* and *i*. Something like
>    this:
> 
>      void
>      lexer_print_token_highlight(lexer_t *lexer, token_t *token, FILE *stream)
>      {
>          size_t offset = token->location.bol;
>          string_view_t line = { .chars = lexer->source.chars + offset, .size = 0 };
>      
>          while (line.chars[i] != '\n' && line.chars[i] != 0) {

Ops, you forgot to remove the **i** here. :x

>              ++line.size;
>          }
> 
>          fprintf(stream, "" SV_FMT "\n", SV_ARG(line));
>          fprintf(stream, "%*s\n", (int)(token->location.offset - token->location.bol + 1), "^");
>      }

Yeah, I will do this change as well, thanks.

> > +    if (!skip_expected_token(parser, TOKEN_COLON))
> > +        return NULL;
> > +
> > +    skip_line_feeds(parser->lexer);
> > +
> > +    type_t fn_return_type;
> > +    if (!parser_parse_type(parser, &fn_return_type)) {
> > +        return NULL;
> > +    }
>
> nitpick: I’ve spotted some inconsistency with the use of brackets in
> if statements. Just throwing it out there, but I believe we should be
> using brackets in all if statements. However, I’m totally fine with
> removing them in guard clauses, as long as we maintain a consistent
> style.

Let's be consistent and keep **{** and **}** on every flow control
statements. Changed.

> This is great work man! I'm excited of how close we are now from start
> the back-end.

Thanks for reviewing it. I will make almost every change you requested
on a new patch revision.

Re: [PATCH olang v1 0/4] create initial syntax analysis logic

[Johnny Richard]

A new revision (v2) of this patchset has been sent.

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 19s

[frontend: Add function calls parsing][0] v2 from [Johnny Richard][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/55225
[1]: mailto:johnny@johnnyrichard.com

✓ #1338817 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1338817

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 20s

[frontend: Add function calls parsing][0] from [Johnny Richard][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/55199
[1]: mailto:johnny@johnnyrichard.com

✓ #1337043 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1337043

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 19s

[tests: fix diff error output][0] from [Carlos Maniero][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/55198
[1]: mailto:carlos@maniero.me

✓ #1336951 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1336951

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 19s

[parser: parse multiple function into a single translation unit][0] from [Carlos Maniero][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/55197
[1]: mailto:carlos@maniero.me

✓ #1336943 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1336943

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 19s

[parse function definition params][0] from [Johnny Richard][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/55183
[1]: mailto:johnny@johnnyrichard.com

✓ #1335469 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1335469

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 20s

[Rename program to translation unit][0] from [Carlos Maniero][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/55177
[1]: mailto:carlos@maniero.me

✓ #1335028 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1335028

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 19s

[Housekeeping: resolve a few FIXMEs related to code style][0] from [Carlos Maniero][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/55176
[1]: mailto:carlos@maniero.me

✓ #1334988 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1334988

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 20s

[extend unsined integers types (u8, u16, u64)][0] v2 from [Carlos Maniero][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/55161
[1]: mailto:carlos@maniero.me

✓ #1334228 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1334228

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 20s

[tests: build: improve makefile for tests][0] from [Johnny Richard][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/55158
[1]: mailto:johnny@johnnyrichard.com

✓ #1334090 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1334090

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 21s

[extend unsined integers types (u8, u16, u64)][0] from [Carlos Maniero][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/55142
[1]: mailto:carlos@maniero.me

✓ #1333732 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1333732

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 20s

[fix multiple variables][0] from [Carlos Maniero][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/55133
[1]: mailto:carlos@maniero.me

✓ #1333568 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1333568

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 21s

[compiler: enable full compilation for vars][0] from [Johnny Richard][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/55131
[1]: mailto:johnny@johnnyrichard.com

✓ #1333519 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1333519

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 20s

[cli: add libc error handling][0] from [Carlos Maniero][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/55079
[1]: mailto:carlos@maniero.me

✓ #1330161 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1330161

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 20s

[remove unused examples programs][0] from [Johnny Richard][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/55077
[1]: mailto:johnny@johnnyrichard.com

✓ #1329949 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1329949

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 20s

[build: add install and uninstall targets][0] from [Johnny Richard][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/55076
[1]: mailto:johnny@johnnyrichard.com

✓ #1329923 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1329923

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 50s

[docs: remove pandoc dependency ][0] from [Johnny Richard][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/55062
[1]: mailto:johnny@johnnyrichard.com

✓ #1329317 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1329317

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 35s

[parser: implement variable definition][0] from [Johnny Richard][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/54983
[1]: mailto:johnny@johnnyrichard.com

✓ #1324659 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1324659

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 37s

[codegen: x86_64: implement binary operations][0] v2 from [Johnny Richard][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/54696
[1]: mailto:johnny@johnnyrichard.com

✓ #1311572 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1311572

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 36s

[tests: create a text-based integrations test][0] from [Carlos Maniero][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/54588
[1]: mailto:carlos@maniero.me

✓ #1308300 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1308300

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 32s

[ast: refactor: inline union typedefs][0] v2 from [Johnny Richard][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/54447
[1]: mailto:johnny@johnnyrichard.com

✓ #1302393 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1302393

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 51s

[comment based integration tests][0] from [Carlos Maniero][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/51804
[1]: mailto:carlos@maniero.me

✓ #1219016 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1219016

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 43s

[codegen: x86_64: implement binary operations][0] from [Johnny Richard][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/51409
[1]: mailto:johnny@johnnyrichard.com

✓ #1206119 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1206119

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 47s

[parser: fix parse expression with binop chain][0] from [Johnny Richard][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/51128
[1]: mailto:johnny@johnnyrichard.com

✓ #1199392 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1199392

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 43s

[parser: add missing <= and >= binary operators][0] from [Johnny Richard][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/51123
[1]: mailto:johnny@johnnyrichard.com

✓ #1199375 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1199375

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 44s

[docs: spec: add %, <= and >= binary operators][0] from [Johnny Richard][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/51122
[1]: mailto:johnny@johnnyrichard.com

✓ #1199362 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1199362

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 43s

[Revert "docs: spec: postpone assignment operators"][0] from [Johnny Richard][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/51078
[1]: mailto:johnny@johnnyrichard.com

✓ #1197726 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1197726

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 44s

[docs: spec: add binary expressions][0] v2 from [Johnny Richard][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/51076
[1]: mailto:johnny@johnnyrichard.com

✓ #1197709 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1197709

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 44s

[spec: ebnf: add binary expressions][0] from [Johnny Richard][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/51036
[1]: mailto:johnny@johnnyrichard.com

✓ #1196562 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1196562

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 39s

[docs: variables specification][0] v2 from [Carlos Maniero][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/50820
[1]: mailto:carlos@maniero.me

✓ #1189894 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1189894

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 37s

[linter: turn off clang-format to keep retro compatibility with v16][0] from [Johnny Richard][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/50521
[1]: mailto:johnny@johnnyrichard.com

✓ #1181503 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1181503

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 38s

[site: change look and feel and rewrite home introduction section][0] from [Johnny Richard][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/50517
[1]: mailto:johnny@johnnyrichard.com

✓ #1181439 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1181439

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 40s

[docs: create o programming language spec][0] v3 from [Johnny Richard][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/50408
[1]: mailto:johnny@johnnyrichard.com

✓ #1177304 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1177304

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 39s

[docs: create o programming language spec][0] v2 from [Johnny Richard][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/50320
[1]: mailto:johnny@johnnyrichard.com

✓ #1173074 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1173074

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 38s

[fe: add compiler support to linux aarch64][0] from [Johnny Richard][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/50318
[1]: mailto:johnny@johnnyrichard.com

✓ #1173054 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1173054

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 40s

[fe: add binary operation expr support][0] v3 from [Johnny Richard][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/50288
[1]: mailto:johnny@johnnyrichard.com

✓ #1171874 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1171874

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 38s

[frontend: add binary operation expr support][0] v2 from [Johnny Richard][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/50275
[1]: mailto:johnny@johnnyrichard.com

✓ #1171442 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1171442

Re: [olang/patches/.build.yml] build success

[Johnny Richard]

Thank you very much for you contribution, I love it <3.

nitpick for next replies:

    1) You've replied to the CI build reply.  Next time try to reply to
       the right thread.

    2) Your message has few weird line breaks.  I don't know why it's
       happening (noticed you are using Thunderbird).  However, you can
       make sure your setup is correctly configured to send plain text
       emails by visiting this website https://useplaintext.email/

On Thu, Mar 14, 2024 at 01:29:09AM -0300, Ricardo Kagawa wrote:
> >> This grammar adds the token SEMICOLON (';') for every statement.  I know
> we
> >> agreed make it optional, but the SEMICOLON makes the parser much more
> >> convenient to implement.
> >>
> >> And this is the first topic I would like to discuss. Let me know if you
> >> agree otherwise I can adapt the grammar to make SEMICOLON optional.
> >
> > (...) Therefore, I'm curious about your statement that using a
> > semicolon makes the parser much more convenient to implement. Could you
> > elaborate on this? Have you encountered any new considerations that might
> > complicate the implementation?
> 
> My limited understanding is that the semicolon would indeed be more
> convenient, as it would be a definitive end-of-statement symbol,
> requiring no lookahead to resolve as such. The LF token could be
> ambiguous on its own (between end-of-statement and white space), so
> some lookahead would be required to resolve it.

You are right about it.  I had to implement the lookahead capability in
order to skip LF tokens.

> But it should be alright, as long as the language remains context-free.
> Even if it becomes ambiguous, non-deterministic, or requires a long
> lookahead. Ideally it should be determinitstic for linear time
> performance, but it seems there are parsers that can run close to it in
> the average case, as long as the language remains close to
> deterministic.
> 
> And I don't have a strong opinion on the semicolon issue, except that
> it must be an option. But whatever we do, we must avoid the following
> pitfall from JavaScript:
> 
> ```javascript
> example
> ;(x)
> ```
> 
> The semicolon is mandatory here, because otherwise `(x)` is handled as
> an argument list, and `example` would be called as a function. That is,
> it would be a multi-line statement, instead of two separate statements.
> 
> And why anyone would do this?
> 
> ```javascript
> const x = y.example
> ;(() => {
>   console.log(x)
> })()
> ```

I strong agree on avoid those odd JavaScript design.  I think we can
continue with optional SEMICOLON.  I also think it makes a better
programmer experience.

> >> The grammar was made by using a EBNF evaluator tool[1].
> >>
> >> [1]: https://mdkrajnak.github.io/ebnftest/
> >
> > I would add this link at the markdown, so then people can play with it.
> 
> I would make an even stronger argument for including the link in the
> docs. A good language specification also specifies which language
> specification grammar is used for the specification itself. And the
> EBNF in particular is not properly standardized, so you really need to
> specify which EBNF variant you are using.
> 
> The link should thus be good enough to refer to the EBNF implementation
> used in this specification, although a permanent (version locked) link
> would be better.

Sure, I can add it to the document.  I'm not sure how you want to
version lock this variant.  Should I add a specific github/git tag
version to the document?

> As for my revision of the grammar:

I liked all comments and definitely it seems to be better version.  In
my option we can start with you changes and keep this document alive for
future discussion.  Not sure about Carlos.  Let see his thoughts on that
as well.

> Further discussion:
> 
> - Is the language going to support Unicode? If so, `<alpha>` could use
>   the _L:Letter_ Unicode category instead of being limited to
>   `[a-zA-Z]`. But the EBNF tool does not support Unicode categories in
>   its regular expressions (it does not support flags). Also don't
>   forget to rename it to `<letter>` in that case.
> 
>     - It would help developers in non-English speaking countries, but it
>       could be difficult to work with multi-byte characters and Unicode
>       normalization.

I lack knowledge to answer this question right know.  I would say to
keep it simple as much as we can on this earlier stage (ASCII only)
unless you have a big concern.

> - There are more linear space and line break characters than the ones
>   included here, even within ASCII, although they are not all that
>   important. Even more in Unicode (some under _Cc:Other/control_,
>   others under _Z:Separator_). Should we support them?

Let's add the remaining ASCII ones meanwhile.

> - The function definition could accept a single expression as an
>   alternative to its `<block>`, similar to Kotlin.

Scala also has this capability.  But I think it doesn't fit well in our
current function declaration:

    fn f(): u32 <statement>
               ^
               If we don't add a token in here like **=** it will be very
               weird.

No strong options here to be honest.

> - The integer literal could include optional underline separators for
>   readability. Just need to be careful not to start with underline, to
>   avoid ambiguity with identifiers.

I like that.  We can have it as well.

> - I guess we don't have to support the full set of Unicode digits, since
>   we don't know if these digits would even be decimal in the first
>   place. The numbering system could be very different from our own, so
>   it is likely not feasible to support them.

Perhaps we could postpone the Unicode support?

> - I have not checked if this syntax would avoid that edge case with
>   JavaScript I mentioned in the beginning. I might check that next
>   time (I'm still not sure of how).

Maybe we are going to discovery it on the implementation process.

> - It might seem strange that I included semantic non-terminals here,
>   despite having removed non-terminals for symbols and keywords. I can't
>   say for sure, since this is my first time trying this style, but I
>   suspect that besides making the language specification easier to
>   understand, the important bits to hook into in the parser will be
>   around these symbols. That is, it could simplify some work on the
>   parser.

ACK

Re: [olang/patches/.build.yml] build success

[Ricardo Kagawa]

 >> This grammar adds the token SEMICOLON (';') for every statement.  I 
know we

 >> agreed make it optional, but the SEMICOLON makes the parser much more

 >> convenient to implement.

 >>

 >> And this is the first topic I would like to discuss. Let me know if you

 >> agree otherwise I can adapt the grammar to make SEMICOLON optional.

 >

 > (...) Therefore, I'm curious about your statement that using a

 > semicolon makes the parser much more convenient to implement. Could you

 > elaborate on this? Have you encountered any new considerations that might

 > complicate the implementation?



My limited understanding is that the semicolon would indeed be more

convenient, as it would be a definitive end-of-statement symbol,

requiring no lookahead to resolve as such. The LF token could be

ambiguous on its own (between end-of-statement and white space), so

some lookahead would be required to resolve it.



But it should be alright, as long as the language remains context-free.

Even if it becomes ambiguous, non-deterministic, or requires a long

lookahead. Ideally it should be determinitstic for linear time

performance, but it seems there are parsers that can run close to it in

the average case, as long as the language remains close to

deterministic.



And I don't have a strong opinion on the semicolon issue, except that

it must be an option. But whatever we do, we must avoid the following

pitfall from JavaScript:



```javascript

example

;(x)

```



The semicolon is mandatory here, because otherwise `(x)` is handled as

an argument list, and `example` would be called as a function. That is,

it would be a multi-line statement, instead of two separate statements.



And why anyone would do this?



```javascript

const x = y.example

;(() => {

   console.log(x)

})()

```



Immediately invoked function expressions are a thing in JavaScript, and

it would not be uncommon to have some expression ending with an

identifier right before them.



 >> The grammar was made by using a EBNF evaluator tool[1].

 >>

 >> [1]: https://mdkrajnak.github.io/ebnftest/

 >

 > I would add this link at the markdown, so then people can play with it.



I would make an even stronger argument for including the link in the

docs. A good language specification also specifies which language

specification grammar is used for the specification itself. And the

EBNF in particular is not properly standardized, so you really need to

specify which EBNF variant you are using.



The link should thus be good enough to refer to the EBNF implementation

used in this specification, although a permanent (version locked) link

would be better.



----

As for my revision of the grammar:



- Separated rules into sections.

- Added optional white space around the program.

- You don't actually need non-terminal symbols for keywords. Especially

   if you are including the keyword in the symbol name.

- You don't need non-terminal symbols for symbols either, unless you

   have a more "semantic" name for it. There should not be another

   "semicolon" besides `;`, for example.

- In Johnny's version the function name is a single identifier. I don't

   know why Carlos's version made it multiple. I have made it single

   again.

- In Johnny's version the space before the return type is optional. I

   don't know why Carlos's version made it mandatory. I have made it

   optional again.

- Replaced `<identifier>` in `<function-definition>` with

   `<function-name>` to express that this identifier is the name of the

   declared function. Then, `<function-name>` is just `<identifier>`.

- Renamed `<fn-args>` to `<function-parameters>`, since parameters are

   the variables in a function declaration, while arguments are the

   values bound to those variables during function calls.

- Replaced `<type>` for `<return-type>` in `<function-declaration>` to

   express that this type identifier is the return type of the function.

   Then, `<return-type>` is just `<type>`.

- Replaced `<block>` in `<function-definition>` for `<function-body>` to

   express that this block is the body of the declared function.

- Reworked `<block>`, `<statement>` and `<end-of-statement>` to allow

   for:

     - Single statement followd by optional end-of-statement;

     - Statement list with mandatory end-of-statement between statements;

     - But the statements could be made optional, yet I did not in this

       version, as there is no `void` return type, currently.

- Replaced `<number>` in `<return-statement>` with `<expression>` to

   prepare for them in the future. The only allowed expression is still

   an integer literal, though.

- Renamed `<number>` to `<integer>`, and reworked it to actually

   represent decimal integer literals. Sequences of zero digits are now

   forbidden at the left side, but a lone zero digit is still allowed.

- Reworked `<identifier>` to better express that it starts with

   `<alpha>` or underline, followed by zero or more `<alpha>`, `<digit>`

   or underline.

- Removed `_` from `<alpha>` to better reflect the name (as underline is

   not an alphabetic character).

- Renamed `<space>` for `<ws>` to avoid ambiguity with the character

   U+0020 Space, and made it a one-or-more list. Also introduced `<ows>`

   for "optional white space". Shorter names were preferred here due to

   these symbols in particular being used very frequently.

- Also introduced `<line-break>` as either LF, CR or CRLF. Otherwise the

   CRLF sequence would be parsed as two separate line breaks. Not that it

   would matter that much, except maybe for mapping line numbers.



```

(* Entry Point *)

<program>             ::= <ows> <function-definition> <ows>



(* Functions *)

<function-definition> ::= 'fn' <ws> <function-name> <ows> 
<function-parameters> <ows> ':' <ows> <return-type> <ows> <function-body>

<function-name>       ::= <identifier>

<function-parameters> ::= '(' <ows> ')'

<return-type>         ::= <type>

<function-body>       ::= <block>



(* Statements *)

<block>               ::= '{' <ows> <statement> <ows> 
(<end-of-statement> <ows> <statement> <ows>)* <end-of-statement>? <ows> '}'

<end-of-statement>    ::= ';' | <line-break>

<statement>           ::= <return-statement>

<return-statement>    ::= 'return' <ws> <expression>



(* Expressions *)

<expression>          ::= <integer>



(* Identifiers *)

<type>                ::= 'u32'

<identifier>          ::= (<alpha> | '_') (<alpha> | <digit> | '_')*



(* Literals *)

<integer>             ::= <integer-base10>

<integer-base10>      ::= #'[1-9]' <digit>* | '0'



(* Utilities *)

<ws>                  ::= <white-space>+

<ows>                 ::= <white-space>*

<white-space>         ::= <linear-space> | <line-break>

<line-break>          ::= '\n' | '\r' | '\r\n'

<linear-space>        ::= #'[ \t]'

<alpha>               ::= #'[a-zA-Z]'

<digit>               ::= #'[0-9]'

```



Further discussion:



- Is the language going to support Unicode? If so, `<alpha>` could use

   the _L:Letter_ Unicode category instead of being limited to

   `[a-zA-Z]`. But the EBNF tool does not support Unicode categories in

   its regular expressions (it does not support flags). Also don't

   forget to rename it to `<letter>` in that case.

     - It would help developers in non-English speaking countries, but it

       could be difficult to work with multi-byte characters and Unicode

       normalization.

- There are more linear space and line break characters than the ones

   included here, even within ASCII, although they are not all that

   important. Even more in Unicode (some under _Cc:Other/control_,

   others under _Z:Separator_). Should we support them?

- The function definition could accept a single expression as an

   alternative to its `<block>`, similar to Kotlin.

- The integer literal could include optional underline separators for

   readability. Just need to be careful not to start with underline, to

   avoid ambiguity with identifiers.

- I guess we don't have to support the full set of Unicode digits, since

   we don't know if these digits would even be decimal in the first

   place. The numbering system could be very different from our own, so

   it is likely not feasible to support them.

- I have not checked if this syntax would avoid that edge case with

   JavaScript I mentioned in the beginning. I might check that next

   time (I'm still not sure of how).

- It might seem strange that I included semantic non-terminals here,

   despite having removed non-terminals for symbols and keywords. I can't

   say for sure, since this is my first time trying this style, but I

   suspect that besides making the language specification easier to

   understand, the important bits to hook into in the parser will be

   around these symbols. That is, it could simplify some work on the

   parser.

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 34s

[frontend: add basic arithmetic expr support][0] from [Johnny Richard][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/50195
[1]: mailto:johnny@johnnyrichard.com

✓ #1168244 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1168244

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 35s

[refactor: rename zero programming language to olang][0] v3 from [Fabio Maciel][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/50188
[1]: mailto:fabio@fabiomaciel.com

✓ #1167864 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1167864

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 36s

[refactor: rename zero programming language to olang][0] from [Johnny Richard][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/50167
[1]: mailto:johnny@johnnyrichard.com

✓ #1167072 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1167072

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 34s

[site: change dns to o-lang.org][0] from [Johnny Richard][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/50131
[1]: mailto:johnny@johnnyrichard.com

✓ #1166160 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1166160

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 33s

[docs: create zero programming language specification][0] from [Johnny Richard][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/50092
[1]: mailto:johnny@johnnyrichard.com

✓ #1164786 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1164786

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 33s

[test: cli: cover compilation pipeline][0] v2 from [Carlos Maniero][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/50091
[1]: mailto:carlos@maniero.me

✓ #1164772 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1164772

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 33s

[ast: add ast_node root for the entire program][0] from [Johnny Richard][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/50090
[1]: mailto:johnny@johnnyrichard.com

✓ #1164762 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1164762

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 34s

[tests: cli: cover compilation pipeline][0] from [Carlos Maniero][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/50070
[1]: mailto:carlos@maniero.me

✓ #1164273 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1164273

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 42s

[create initial syntax analysis logic][0] v2 from [Johnny Richard][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/49932
[1]: mailto:johnny@johnnyrichard.com

✓ #1160326 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1160326

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 44s

[arena: optimization: ensure alignment memory access][0] v3 from [Carlos Maniero][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/49869
[1]: mailto:carlos@maniero.me

✓ #1158813 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1158813

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 45s

[cli: replace memory allocation malloc -> arena][0] v2 from [Johnny Richard][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/49866
[1]: mailto:johnny@johnnyrichard.com

✓ #1158692 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1158692

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 37s

[introduce hash map data structure][0] v2 from [Johnny Richard][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/49853
[1]: mailto:johnny@johnnyrichard.com

✓ #1158194 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1158194

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 32s

[test: fix suite name for list_test and arena_test][0] from [Johnny Richard][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/49779
[1]: mailto:johnny@johnnyrichard.com

✓ #1156769 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1156769

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 37s

[cli: replace memory allocation malloc -> arena][0] from [Johnny Richard][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/49749
[1]: mailto:johnny@johnnyrichard.com

✓ #1155615 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1155615

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 37s

[docs: add DCO information on hacking page][0] from [Johnny Richard][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/49746
[1]: mailto:johnny@johnnyrichard.com

✓ #1155599 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1155599

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 37s

[build: rename 0c.c file to main.c][0] from [Johnny Richard][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/49745
[1]: mailto:johnny@johnnyrichard.com

✓ #1155591 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1155591

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 44s

[introduce hash map data structure][0] from [Johnny Richard][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/49732
[1]: mailto:johnny@johnnyrichard.com

✓ #1155192 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1155192

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 33s

[arena: optimization: make arena 8 bits aligned][0] v2 from [Carlos Maniero][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/49723
[1]: mailto:carlos@maniero.me

✓ #1154947 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1154947

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 35s

[arena: optimization: make arena 8 bits aligned][0] from [Carlos Maniero][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/49718
[1]: mailto:carlos@maniero.me

✓ #1154549 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1154549

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 35s

[utils: add linked-list][0] from [Carlos Maniero][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/49714
[1]: mailto:carlos@maniero.me

✓ #1154366 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1154366

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 33s

[utils: add arena][0] v3 from [Carlos Maniero][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/49711
[1]: mailto:carlos@maniero.me

✓ #1154191 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1154191

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 34s

[Create --dump-tokens on compiler cli][0] v5 from [Carlos Maniero][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/49685
[1]: mailto:carlos@maniero.me

✓ #1153651 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1153651

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 34s

[Create --dump-tokens on compiler cli][0] v3 from [Johnny Richard][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/49645
[1]: mailto:johnny@johnnyrichard.com

✓ #1153060 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1153060

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 33s

[add unit tests config][0] from [Carlos Maniero][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/49618
[1]: mailto:carlos@maniero.me

✓ #1152377 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1152377

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 31s

[docs: add mobile version][0] from [Carlos Maniero][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/49612
[1]: mailto:carlos@maniero.me

✓ #1152244 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1152244

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 31s

[docs: deploy: replace shrt.site domain by olang.johnnyrichard.com][0] from [Johnny Richard][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/49611
[1]: mailto:johnny@johnnyrichard.com

✓ #1152239 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1152239

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 31s

[docs: build: fix docs publishing task][0] from [Johnny Richard][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/49609
[1]: mailto:johnny@johnnyrichard.com

✓ #1152215 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1152215

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 16s

[docs: add HACKING documentation][0] v2 from [Carlos Maniero][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/49605
[1]: mailto:carlos@maniero.me

✓ #1152165 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1152165

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 17s

[docs: add white mode support][0] v2 from [Carlos Maniero][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/49604
[1]: mailto:carlos@maniero.me

✓ #1152150 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1152150

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 17s

[docs: add white-mode support][0] from [Carlos Maniero][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/49603
[1]: mailto:carlos@maniero.me

✓ #1152135 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1152135

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 17s

[docs: add pandoc][0] from [Carlos Maniero][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/49600
[1]: mailto:carlos@maniero.me

✓ #1152071 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1152071

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 16s

[docs: build: add deployment script][0] from [Carlos Maniero][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/49578
[1]: mailto:carlos@maniero.me

✓ #1151433 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1151433

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 17s

[docs: add sphinx documentation support][0] v2 from [Johnny Richard][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/49575
[1]: mailto:johnny@johnnyrichard.com

✓ #1151403 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1151403

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 16s

[docs: add sphinx documentation support][0] from [Johnny Richard][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/49563
[1]: mailto:johnny@johnnyrichard.com

✓ #1151185 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1151185

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 15s

[add integration test][0] v3 from [Carlos Maniero][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/49557
[1]: mailto:carlos@maniero.me

✓ #1151093 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1151093

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 17s

[Add integration tests][0] from [Carlos Maniero][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/49542
[1]: mailto:carlos@maniero.me

✓ #1150776 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1150776

[olang/patches/.build.yml] build success

[builds.sr.ht]

olang/patches/.build.yml: SUCCESS in 16s

[docs: fix git send-email config instruction][0] from [Carlos Maniero][1]

[0]: https://lists.sr.ht/~johnnyrichard/olang-devel/patches/49460
[1]: mailto:carlos@maniero.me

✓ #1149191 SUCCESS olang/patches/.build.yml https://builds.sr.ht/~johnnyrichard/job/1149191