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 #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.