Fix uses_allocators lexer state nesting

[ouankou]

Summary

Prevent uses_allocators(...) lexing from exiting USES_ALLOCATORS_STATE after the first ) by tracking parenthesis depth. This keeps the lexer in the correct state until the top‑level clause closes, so multiple allocators (and allocator traits) are tokenized correctly.

Problem / Upstream bug

uses_allocators can legally contain multiple allocator entries, each optionally followed by allocator‑traits in parentheses. Example:

#pragma omp target uses_allocators(omp_default_mem_alloc(sum), omp_const_mem_alloc(total))

The lexer previously popped USES_ALLOCATORS_STATE on the first ) it saw, which is inside the first allocator entry. That prematurely exits the clause, causing the remaining tokens to be lexed as generic expressions or otherwise misparsed. This breaks OpenMP 5.x uses_allocators parsing and leads to clause corruption during AST construction/unparse.

Fix

• Add a dedicated uses_allocators_paren_depth counter.
• Reset it when entering USES_ALLOCATORS_STATE.
• Increment on ( and only pop the state when the depth returns to zero.

This matches the grammar structure of uses_allocators(...) and preserves nested parentheses inside allocator trait lists.

Tests

• Not run in this repo (no standalone lexer test harness here).
• Verified downstream in REX by parsing OpenMP uses_allocators and comparing pragma round‑trip output; clause is now preserved without truncation.

[ouankou]

@codex review

[ouankou]

/gemini review

[gemini-code-assist]

Code Review

This pull request correctly addresses a lexer state issue with uses_allocators clauses that contain nested parentheses. By introducing a parenthesis depth counter, uses_allocators_paren_depth, the lexer now correctly tracks nested structures and only exits the USES_ALLOCATORS_STATE when the top-level parentheses are closed. The changes are well-contained within src/omplexer.ll and include initializing, resetting, and updating the counter at the appropriate lexer rules. The logic correctly handles nested parentheses within allocator expressions and multiple allocators in a single clause. The implementation appears robust and solves the described problem effectively. I have not found any issues of high or critical severity.