From e57d8ed2098ffd33774bc62165eb5b387f11b1ac Mon Sep 17 00:00:00 2001 From: Kayne Ruse Date: Thu, 16 Feb 2023 23:02:33 +1100 Subject: [PATCH] Fixed broken links --- c-api/toy_ast_node_h.md | 2 +- c-api/toy_compiler_h.md | 2 +- c-api/toy_parser_h.md | 4 ++-- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/c-api/toy_ast_node_h.md b/c-api/toy_ast_node_h.md index f2682e2..98a8764 100644 --- a/c-api/toy_ast_node_h.md +++ b/c-api/toy_ast_node_h.md @@ -2,7 +2,7 @@ This header defines the structure of the nodes used in the Abstract Syntax Tree, known as `Toy_ASTNode`. Most of what is defined here is intended for internal use, so is not documented here. -This header doesn't need to be included directly, as it is included in [toy_parser.h](c-api/toy_parser_h.md). +This header doesn't need to be included directly, as it is included in [toy_parser.h](toy_parser_h.md). ## Defined Functions diff --git a/c-api/toy_compiler_h.md b/c-api/toy_compiler_h.md index e96fecc..046e86f 100644 --- a/c-api/toy_compiler_h.md +++ b/c-api/toy_compiler_h.md @@ -6,7 +6,7 @@ There are two steps to generating intermediate bytecode - the writing step, and During the writing step, the core of the program is generated, along with a series of literals representing the values within the program; these values are compressed and flattened into semi-unrecognizable forms. If the same literal is used multiple times in a program, such as a variable name, the name itself is replaced by a reference to the flattened literals within the cache. -During the collation step, everything from the core program's execution instructions, the flattened literals, the functions (which have their own sections and protocols within the bytecode) and version information (such as the macros defined in [toy_common.h](c-api/toy_common_h.md)) are all combined into a single buffer of bytes, known as bytecode. This bytecode can then be safely saved to a file or immediately executed. +During the collation step, everything from the core program's execution instructions, the flattened literals, the functions (which have their own sections and protocols within the bytecode) and version information (such as the macros defined in [toy_common.h](toy_common_h.md)) are all combined into a single buffer of bytes, known as bytecode. This bytecode can then be safely saved to a file or immediately executed. Executing these functions out-of-order causes undefiend behaviour. diff --git a/c-api/toy_parser_h.md b/c-api/toy_parser_h.md index d7179ac..2471914 100644 --- a/c-api/toy_parser_h.md +++ b/c-api/toy_parser_h.md @@ -1,6 +1,6 @@ # toy_parser.h -This header defines the structure `Toy_Parser` which, after being initialized with a `Toy_Lexer` produces a series of abstract syntax trees to be passed to the `Toy_Compiler`. The following is a utility function provided by [repl_tools.h](c-api/repl_tools_h.md), demonstrating how to use the parser. +This header defines the structure `Toy_Parser` which, after being initialized with a `Toy_Lexer` produces a series of abstract syntax trees to be passed to the `Toy_Compiler`. The following is a utility function provided by [repl_tools.h](repl_tools_h.md), demonstrating how to use the parser. ```c //generate bytecode from a given string @@ -48,7 +48,7 @@ const unsigned char* Toy_compileString(const char* source, size_t* size) { } ``` -This header also includes [toy_ast_node.h](c-api/toy_ast_node_h.md), so the `Toy_freeASTNode` function can also be used. +This header also includes [toy_ast_node.h](toy_ast_node_h.md), so the `Toy_freeASTNode` function can also be used. ## Defined Functions