• Type checking (#108)
• Code generation (#112)

We have several todos related to catching failures during type checking but have not yet implemented reporting the failure and halting compilation.

• Record location (line & column) of AST nodes (#129)
• Report error messages

Currently, our code generation tests are restricted to verifying the return values of programs, which provides limited coverage. This limitation stems from the inability to utilize print functions like printf.

For comprehensive testing of operations, it's beneficial to test them collectively, considering their similar language constructs and often intertwined implementations with higher coupling.

Therefore, we propose the implementation of an intrinsic __builtin_print function—a special function recognized by the compiler. This addition would enable us to print out the values of expressions, enhancing the testing capabilities of our code generation process.

• global variable parsing and type check #167
• code generation #170
• struct and union code generation

• parse pointer
• code gen pointer
• code gen pointer arguments (#135)
• support pointer to pointer (#138)
• support function pointer (#147)

Mixing labels with instructions can make the IR harder to read. We propose indenting the instructions so that they are grouped like paragraphs, which should improve readability. 😄

What's the Problem?

It seems that sigils are used in two different scenarios:

1. Compiler-generated sigils, like labels employed for controlling loop flow.
2. User-defined sigils, such as labels used by the goto statement or function names.

Although these scenarios are unlikely to conflict due to their unique local numbers, I propose a differentiation strategy: all compiler-generated sigils have a . before the name, while user-defined sigils do not.

@.compiler-generated
@user-defined

Currently, compiler-generated scenarios are hard-coded, which is less than optimal:

https://github.com/fruits-lab/VitaminC/blob/be04a5ab65c823afbce8203d17d98c91c2c0864f/src/qbe_ir_generator.cpp#L517-L522

Possible Implementation

Add another layer of inheritance to Sigil.

• parse struct and union #148
• struct and union type in scope #155
• struct and union initialization #158
• struct and union access (postfix expression) #163
• struct and union code generation
  • simple initialization #165
  • initialization with designators
  • pointer to struct or union
  • pass struct and union as parameters
• record type and variable declaration together as variable
• nested struct and union
  • parsing and type check
  • code generation

• Type checking (#121)
• Code generation (#122)

Currently, binary and unary operations of different operators are designed as concrete types. BinaryExprNode and UnaryExprNode act as abstract classes. However, since these operations usually share common behaviors, heavy use of polymorphism doesn't seem useful, and in fact, it can lead to boilerplate code.
We propose removing these classes, denoting different operations with an enum, and making BinaryExprNode and UnaryExprNode concrete classes that hold such an enum. Although we'll have to use switch-case statements to dispatch with them, we believe this change will provide better readability and maintainability.

What's the Problem?

The manual formatting of the QBE IR with the output stream operator (<<) is currently unclear and poses readability challenges. Take the store instruction as an example
https://github.com/fruits-lab/VitaminC/blob/1163ef97c98cc062aaec7883477dd22c38304408/src/qbe_ir_generator.cpp#L92-L93
The interleaved strings with the stream operator make it difficult to identify corresponding arguments, and inconspicuous white spaces are hidden after storew and the comma. This formatting style makes it easy to miss important details.

Possible Solutions

Upon further consideration, it seems that the core issue lies in the interleaving and verbose formatting scattered throughout the function body. Instead of focusing on how to format specific instructions correctly, we should address the broader concern of which instruction to choose. I propose introducing a new abstraction using the following syntax:

output << Store(qbe::kWord, PrefixSigil(init_num), PrefixSigil(id_num)) << std::endl;

The output stream operator itself is not problematic; rather, it's the interleaving that causes issues.
Additionally, the intention of PrefixSigil(init_num) is unclear. To enhance clarity, we can use a wrapper that provides a description and handles the formatting, including adding the corresponding sigil:

output << Store(Type::kWord, FuncScopeTemp{init_num}, FuncScopeTemp{id_num}) << std::endl;

Now, it's clear that we are outputting a store instruction, which stores a word of a function scope temporary to another function scope temporary. This design can be extended to other QBE instructions. Here are some examples:

• Jnz(FuncScopeTemp{predicate_num}, BlockLabel{body}, BlockLabel{end})
• Alloc(Type::kWord, FuncScopeTemp{id_num}, /* count */ 1)
• Add(Type::kWord, FuncScopeTemp{dest}, FuncScopeTemp{src1}, FuncScopeTemp{src2})

For instructions that accept various identifier types, such as function scope temporary and constant value, function overloading or distinct names (e.g., AddI) can be used.

Feel free to discuss and provide feedback on this proposed approach 🤟

• Function calls (postfix-expressions)
• Function definition
• Parameters lists
• Parameter lists code generation
• Function definition code generation
• Function call code generation
• Function call with arguments code generation
• Function arguments
• Type check for arguments and parameters

"clang-tidy is a clang-based C++ “linter” tool. Its purpose is to provide an extensible framework for diagnosing and fixing typical programming errors, like style violations, interface misuse, or bugs that can be deduced via static analysis." -- Extra Clang Tools 19.0.0git documentation

• Parse array
• Code generation array
• array initializer

What's the problem?

The issue arises due to how object files are defined in the Makefile:

SRC := $(shell find -name "*.cpp")

OBJS := $(SRC) lex.yy.o y.tab.o
OBJS := $(OBJS:.cpp=.o)

During a clean build, the Flex and Bison generated files (lex.yy.cpp and y.tab.cpp) are not present, hence they are not detected by the find operation as part of SRC. However, if a previous build has already generated these files, they will be included in SRC. Subsequently, when lex.yy.o and y.tab.o are manually added, they get linked twice, resulting in the multiple definition error.

Since all of our code is in C++, the use of C-strings is discouraged.