Problem
Currently, all compiler errors are plain strings:
// typechecker/typechecker.hpp
struct TypeError {
std::string message;
int line;
std::string filename;
};
// Usage
error(state, "method '" + mcall.method_name + "' not found on struct '" + obj_type.base_type + "'", mcall.line);
This makes it difficult to:
- Provide structured error codes for tooling (LSP, IDEs)
- Offer specific fix suggestions
- Test for specific error conditions
- Localize error messages
Suggested Solution
Introduce error categories and structured data:
enum class ErrorCode {
E001_UNDEFINED_VARIABLE,
E002_UNDEFINED_FUNCTION,
E003_TYPE_MISMATCH,
E004_ARGUMENT_COUNT_MISMATCH,
E005_UNDEFINED_METHOD,
// ...
};
struct TypeError {
ErrorCode code;
int line;
string filename;
// Structured data for the specific error type
variant<
UndefinedSymbol, // { name: string }
TypeMismatch, // { expected: string, got: string }
ArgCountMismatch, // { expected: int, got: int }
// ...
> details;
string format() const; // Generate human-readable message
};
Benefits
- Tooling integration: Error codes can be used by LSP for quick fixes
- Testing: Can test for specific error types, not just message substrings
- Localization: Error templates can be translated
- Consistency: Structured data ensures all necessary context is captured
Implementation Notes
- Start with type errors, extend to parser errors later
- Keep backward compatibility by implementing `format()` method
- Consider adding source ranges (not just line numbers)
Priority
Medium - Improves developer experience significantly.
Problem
Currently, all compiler errors are plain strings:
This makes it difficult to:
Suggested Solution
Introduce error categories and structured data:
Benefits
Implementation Notes
Priority
Medium - Improves developer experience significantly.