Add support for warning-only refactoring rules

[Copilot]

Implementing support for warning-only refactoring rules (rules that can warn without fixing).

Plan:

• [x] Explore codebase structure
• [x] Extend define-refactoring-rule to support warning-only rules
• [x] Update refactoring-rule object type to track fix availability
• [x] Modify refactoring-result to support warning-only results
• [x] Update refactoring-rules-refactor to handle warning-only rules
• [x] Filter out warning-only results in resyntax fix command
• [x] Update CLI output and GitHub integration
• [x] Add tests for warning-only rules
• [x] Update test infrastructure to support comment-only-test
• [x] Address code review feedback (API improvements)
• [x] Return #t instead of (void) for no-suggestion rules
• [x] Run existing tests to ensure no regressions

Summary: Successfully implemented complete support for warning-only refactoring rules with improved API based on code review feedback.

API:

1. refactoring-rule-suggestion-count returns exact-nonnegative-integer? (0 for no suggestions, 1 for one suggestion, extensible to multiple)
2. Use #:no-suggestion keyword as the replacement template position for warning-only rules
3. No-suggestion rules return #t when pattern matches (instead of void)

Example Usage:

(define-refactoring-rule equality-check-against-self
  #:description "Comparing a value to itself always returns true"
  #:literals (equal?)
  (equal? a:id a2:id)
  #:when (free-identifier=? (attribute a) (attribute a2))
  #:no-suggestion)

All tests pass.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Allow rules to warn without fixing</issue_title> <issue_description>Currently, Resyntax will only comment on issues where it can produce a single unambiguous fix that resolves that issue. But some issues, such as the one mentioned in jackfirth/resyntax#483, are easy to detect but have no obvious fix. Resyntax should support writing such rules and including their warnings in resyntax analyze.

Several changes need to be made to support this. First, define-refactoring-rule should be extended with an option for declaring rules without fixes. Here's one possible syntax:

(define-refactoring-rule dont-do-that
  #:description "Don't do that"
  #:suggested-fixes none
  (bad-thing))

That is, there would be a #:suggested-fixes option which can take on the values none or one, and which defaults to one. Making the value a symbol (matched by datum) instead of a boolean makes it easy to extend this in the future to rules which offer a choice among multiple possible fixes.

The representation of refactoring rules and warnings would need to be updated to accommodate warnings that do not include suggested fixes. This would probably amount to resyntax analyze adjusting how it displays results to allow for results without fixes, and resyntax fix filtering out results to only those which have a suggested fix.

The resyntax/test language would need to be updated too. Currently it has no mechanism to test that a refactoring rule produces a result without checking that the result actually changes the input code. One possible approach could be to add a comment-only-test statement which uses options to assert that Resyntax comments on the code without changing it. Here's a possible syntax:

comment-only-test: "duplicate equality comparison"
---
(define a 5)
(equal? a a)
---
@inspect - (equal? a a)
@assertMatch equality-check-against-self

This would work similarly to the analysis-test statement, in that it would use @inspect (and optionally @within) to specify a subexpression to make assertions on. The assertion checks that a rule with a specific name warns about that subexpression without suggesting any fixes to it.</issue_description>

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

• Fixes jackfirth/resyntax#601

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.