Skip to content

Conversation

@DavePearce
Copy link
Collaborator

@DavePearce DavePearce commented Nov 11, 2025

Note

Tracks module-qualified handles to error on duplicates across files/fragments for constraints, lookups, properties, and sorted declarations; adds failing tests.

  • Parser/Compiler:
    • Add module-qualified handle tracking (Parser.handles) shared across files via ParseSourceFilesparseSourceFileNewParser(..., handles).
    • Enforce duplicate-handle errors for defconstraint, deflookup, defclookup, defmlookup, defproperty, defsorted/defstrictsorted using qualified names (module:handle).
    • Update method signatures to pass module and remove per-call handles maps (e.g., parseDefConstraint, parseDefLookup, parseDefConditionalLookup, parseDefMultiLookup, parseDefProperty, parseDefSorted, parseLookupHandle).
  • Tests:
    • Add invalid cases basic_invalid_20.lisp and lookup_invalid_19.lisp asserting "duplicate handle" across repeated module m1 fragments.
    • Register new tests in pkg/test/corset_invalid_test.go.

Written by Cursor Bugbot for commit eaa5f22. This will update automatically on new commits. Configure here.

This adds two (failing) tests for this issue.
@DavePearce DavePearce linked an issue Nov 11, 2025 that may be closed by this pull request
}
//
handle := elements[1].AsSymbol().Value
qualifiedHandle := fmt.Sprintf("%s:%s", module.String(), handle)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bug: Nil Pointer Panic in Definition Parsing

Potential nil pointer dereference in parseDefSorted. When isIdentifier(elements[1]) returns false, an error is appended but execution continues to line 1185 where elements[1].AsSymbol().Value is called. Since isIdentifier returns false when AsSymbol() returns nil, this will panic. The handle extraction should be inside an else block like in parseDefProperty, or the function should return early like in parseDefConstraint.

Fix in Cursor Fix in Web

Previously, the algorithm for checking that two constraints do not have
the same handle (in the same module) only worked when the constraints
were defined within the same module block.  However, if they were
defined in different blocks (e.g. in different files) the duplicate
handle was not reported as an error.

To resolve this, a global map of all handles is now maintained which is
shared across all source files and module blocks.
@DavePearce DavePearce force-pushed the 1279-fix-error-for-lookups-with-same-handle branch from 71ead2d to eaa5f22 Compare November 11, 2025 22:06
@DavePearce DavePearce merged commit 22dbb78 into main Nov 12, 2025
22 checks passed
@DavePearce DavePearce deleted the 1279-fix-error-for-lookups-with-same-handle branch November 12, 2025 00:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

fix: error for constraints with same handle

2 participants