Filter out refactoring suggestions that produce non-compiling code

[Copilot]

• Add tests for source-can-expand? in a submodule
  • Tests valid Racket code that should expand successfully
  • Tests invalid Racket code that should fail to expand
  • Tests both string-source and modified-source cases
  • All 1030 tests pass

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Refactoring rules that produce broken code shouldn't be applied</issue_title>
<issue_description>Currently if a replacement generated by a rule produces code that fails to compile, it's applied anyway. The tool doesn't even check for compilation success afterwards, so this silently produces broken code. Instead, any replacements that don't compile should be ignored.</issue_description>

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

@jackfirth Yeah, good catch. Can you open a new issue for just that specific case?

I think it should be fixable by looking at the identifiers and scopes in the replacement syntax object. I might also need to change resyntax to add a scope to the input syntax object before handing it to a rule and then remove that scope from the output of the rule, so we can figure out which identifiers the rule introduced.</comment_new>
<comment_new>@jackfirth
This is now actually feasible to implement. Multipass analysis gives Resyntax the ability to inspect all of the changes it wants to make before applying any of them. In theory, Resyntax should be able to drop any results that don't compile. This will take longer, but it will make the Autofixer far more useful.

The simplest approach is probably to check each of the refactoring-result-set? objects produced for each source file in each analysis pass. If the modified source after applying those results fails to compile, drop those results and any future result sets for that source file. This means a change that breaks a file prevents any other changes from being made to that file, but at least it doesn't get in the way of other files. Some post-mortem analysis to narrow down which change in the result set broke things should also be feasible.</comment_new>
<comment_new>@jackfirth
As a concrete example, consider this refactoring rule:

(define-refactoring-rule break-define-foo
  #:description "Breaking foo definition"
  #:datum-literals (foo)
  #:literals (define)
  (define foo 42)
  (if))

When resyntax analyze is run on this file:

#lang racket/base

(define foo 42)

It makes this suggestion:

resyntax: /Users/jackfirth/Documents/GitHub/resyntax/foo.rkt:3:0 [break-define-foo]


  Breaking foo definition


  3 (define foo 42)


  3 (if)

But that suggestion causes the file to fail to compile. It should be excluded from resyntax analyze and resyntax fix.</comment_new>

• Fixes Refactoring rules that produce broken code shouldn't be applied #10

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[github-actions]

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

[coveralls]

Pull Request Test Coverage Report for Build #306

Details

• 21 of 32 (65.63%) changed or added relevant lines in 3 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.2%) to 93.683%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
main.rkt	12	23	52.17%

Totals
Change from base Build #304:	0.2%
Covered Lines:	15098
Relevant Lines:	16116

---

💛 - Coveralls

[jackfirth]

@copilot