Refactor source-analyze to filter by syntax paths instead of line ranges

[Copilot]

Resyntax currently filters syntax objects during analysis by checking if their source locations fall within requested line ranges. As more of the codebase has moved to work with syntax paths, this line-based filtering has become a bottleneck.

Changes

• Added source-syntax-paths function (private/source.rkt): Accepts a source? and optional range-set? of line numbers, returns a sorted-set? of syntax-path? values for all syntax objects that overlap with the specified lines.

• Updated source-analyze signature (private/analysis.rkt): Changed from #:lines range-set? parameter to #:paths sorted-set?. The function now filters visited syntax objects by checking path membership instead of computing line overlaps during expansion observation.

• Updated call sites (main.rkt): Convert line ranges to syntax paths via source-syntax-paths before passing to source-analyze.

Example

;; Before: source-analyze accepted line ranges
(source-analyze src 
  #:lines (range-set (closed-range 10 20 #:comparator natural<=>))
  #:analyzers analyzers
  #:timeout-ms 10000)

;; After: source-analyze accepts syntax paths
(define paths (source-syntax-paths src 
                 (range-set (closed-range 10 20 #:comparator natural<=>))))
(source-analyze src
  #:paths paths
  #:analyzers analyzers
  #:timeout-ms 10000)

This enables expansion analyzers to work directly with syntax paths, making it straightforward to limit analysis to specific subtrees of the expanded syntax.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Filtering by syntax paths</issue_title>
<issue_description>Resyntax can be asked to only make suggestions on specific lines and line ranges, as opposed to whole files. There are various places in Resyntax's core engine where this is used to filter out syntax objects based on whether their source location lies within the requested lines.

However, as more and more of Resyntax has changed to work in terms of syntax paths instead of source locations, this implementation is getting in the way. There should be a utility that takes a syntax object and a set of line ranges and returns a sorted set of the syntax paths within that syntax object that overlap with the line ranges. This would make it possible to ask expansion analyzers to only concern themselves with certain parts of the expanded syntax, instead of the entire expansion.</issue_description>

Comments on the Issue (you are @copilot in this section)

@jackfirth Proposed API: add a `source-syntax-paths` function that accepts a `source?` and an optional `range-set?` of line numbers, and returns an immutable `sorted-set?` of `syntax-path?` values. Any syntax objects which partially overlap with the line range should have their paths included. The `source-analyze` function should be changed to accept a sorted set of `syntax-path?` values instead of a range set of line numbers.

• Fixes Filtering by syntax paths #752

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[github-actions]

Resyntax analyzed 3 files in this pull request and found no issues.

[coveralls]

coverage: 93.669% (+0.008%) from 93.661%
when pulling 599b9ef on copilot/add-syntax-path-filter-utility
into 43f5fc6 on master.