Minor bug fixes

[LowLevelLore]

We never saw that coming

Summary by Sourcery

Standardize token kind references and relocate negative numeric literal handling from the lexer to the parser; extend CI workflows with improved caching and branch triggers.

New Features:

• Support parsing of negative integer and float literals in the parser

Enhancements:

• Replace all occurrences of Token::Token::Kind with Token::Kind in the parser for consistency
• Remove negative number handling from the lexer to simplify scanning logic

CI:

• Trigger CI on both main and dev branches
• Use OS-specific cache keys and restore-keys for build directory caching in workflows
• Add pip cache step for Windows runners
• Rename install step to Install System Dependencies

[sourcery-ai]

Reviewer's Guide

This PR standardizes token enum usage in the parser, relocates negative-number parsing from the lexer to the parser, and strengthens CI workflows by widening branch triggers, optimizing caching, and clarifying dependency steps.

Class diagram for Parser and Lexer changes

classDiagram
    class Parser {
        +bool match(Token::Kind kind)
        +void expect(Token::Kind kind, const std::string& errMsg)
        +std::unique_ptr<ASTNode> parse()
        +std::unique_ptr<ASTNode> parsePrimary()
    }
    class Lexer {
        +Token nextToken()
        -Token scanNumber() // negative number logic removed
    }
    Parser --> Lexer : uses
    class Token {
        <<enum>>
        Kind
    }

Loading

Flow diagram for negative number parsing responsibility shift

flowchart TD
    Lexer-->|Before: handled negative numbers|NumberToken
    Parser-->|Now: handles negative numbers|PrimaryExpr
    NumberToken-->|Passed to Parser|PrimaryExpr
    PrimaryExpr-->|Creates negative literal AST node|ASTNode

Loading

File-Level Changes

Change	Details	Files
Standardize token-kind enum references	Replace all Token::Token::Kind with Token::Kind in parser methods Update match(), expect(), loop conditions, and statement parsing checks to use simplified enum Align literal, identifier, and keyword parsing invocations to new enum scope	src/parser/Parser.cpp
Shift negative-number handling into parser	Remove '-' prefix logic from lexer's scanNumber routine Add symbol-based negative literal branch in Parser::parsePrimary for floats and integers Ensure negative values produce proper AST literal nodes	src/lexer/Lexer.cpp src/parser/Parser.cpp
Enhance CI workflow triggers and caching	Include 'dev' branch in push event triggers Use OS-specific cache keys with restore-keys for build directory and pip cache Rename install step to 'Install System Dependencies' for clarity	.github/workflows/test.yml

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey @LowLevelLore - I've reviewed your changes and they look great!

Prompt for AI Agents

Please address the comments from this code review:
## Individual Comments

### Comment 1
<location> `src/parser/Parser.cpp:540` </location>
<code_context>
     }

     std::unique_ptr<ASTNode> Parser::parsePrimary() {
+        if (currentToken.kind == Token::Kind::Symbol && currentToken.text == "-") {
+            advance();
</code_context>

<issue_to_address>
Consider moving all unary minus handling from parsePrimary to parseUnary and using a match overload to reduce duplication and centralize logic.

Here’s one way to pull the “–”‐in‐front‐of‐literal logic out of `parsePrimary` and into `parseUnary`, collapse duplication, and keep all existing behavior:

1. Remove your new “if (currentToken == ‘–’) { … }” block from `parsePrimary()`.  
2. Add an overload of `match` so you can match on both kind+text:  
```cpp
bool Parser::match(Token::Kind kind, const std::string &txt) {
    if (currentToken.kind == kind && currentToken.text == txt) {
        advance();
        return true;
    }
    return false;
}
```  
3. Change `parseUnary()` to handle “–” in one place.  If it’s directly in front of a literal you’ll still get a single literal node; if it’s in front of any other expression you get a proper unary‐negate node:

```cpp
std::unique_ptr<ASTNode> Parser::parseUnary() {
    // special‐case negative literal:
    if (match(Token::Kind::Symbol, "-") &&
        (currentToken.kind == Token::Kind::IntegerLiteral ||
         currentToken.kind == Token::Kind::FloatLiteral))
    {
        // capture "-" + literal text, then let primary do the rest
        std::string txt = "-" + currentToken.text;
        auto kind = currentToken.kind;
        advance();
        return (kind == Token::Kind::IntegerLiteral)
            ? ASTNode::makeIntegerLiteralNode(txt, currentScope)
            : ASTNode::makeFloatLiteralNode    (txt, currentScope);
    }
    // generic unary operator (e.g. negate a sub‐expr)
    if (match(Token::Kind::Symbol, "-")) {
        auto operand = parseUnary();
        return ASTNode::makeUnaryOperatorNode(UnaryOp::Negate,
                                              std::move(operand),
                                              currentScope);
    }
    // fall back to primary
    return parsePrimary();
}
```

That eliminates the nested `if(“-”)` in `parsePrimary` and centralizes **all** unary‐minus handling in one place.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[sourcery-ai]

issue (complexity): Consider moving all unary minus handling from parsePrimary to parseUnary and using a match overload to reduce duplication and centralize logic.

Here’s one way to pull the “–”‐in‐front‐of‐literal logic out of parsePrimary and into parseUnary, collapse duplication, and keep all existing behavior:

1. Remove your new “if (currentToken == ‘–’) { … }” block from parsePrimary().
2. Add an overload of match so you can match on both kind+text:

bool Parser::match(Token::Kind kind, const std::string &txt) {
    if (currentToken.kind == kind && currentToken.text == txt) {
        advance();
        return true;
    }
    return false;
}

3. Change parseUnary() to handle “–” in one place. If it’s directly in front of a literal you’ll still get a single literal node; if it’s in front of any other expression you get a proper unary‐negate node:

std::unique_ptr<ASTNode> Parser::parseUnary() {
    // special‐case negative literal:
    if (match(Token::Kind::Symbol, "-") &&
        (currentToken.kind == Token::Kind::IntegerLiteral ||
         currentToken.kind == Token::Kind::FloatLiteral))
    {
        // capture "-" + literal text, then let primary do the rest
        std::string txt = "-" + currentToken.text;
        auto kind = currentToken.kind;
        advance();
        return (kind == Token::Kind::IntegerLiteral)
            ? ASTNode::makeIntegerLiteralNode(txt, currentScope)
            : ASTNode::makeFloatLiteralNode    (txt, currentScope);
    }
    // generic unary operator (e.g. negate a sub‐expr)
    if (match(Token::Kind::Symbol, "-")) {
        auto operand = parseUnary();
        return ASTNode::makeUnaryOperatorNode(UnaryOp::Negate,
                                              std::move(operand),
                                              currentScope);
    }
    // fall back to primary
    return parsePrimary();
}

That eliminates the nested if(“-”) in parsePrimary and centralizes all unary‐minus handling in one place.