Convert all Makefile tests to rmake tests with legacy-makefile-test

[Zalathar]

We can't remove Makefile support from compiletest yet, because #121876 isn't quite complete.

But it occurred to me that we can remove some of the Makefile support with a neat little trick: give every legacy Makefile test a dummy rmake.rs file containing a special directive that tells compiletest to run the Makefile, instead of building and running the rmake recipe.

Thus, while we still can't remove run_rmake_legacy_test, we can at least start removing Makefile support from the “frontend” parts like test discovery and directive parsing.

---

Marking as draft for now because I want to let the idea bake a little more. But so far it does seem like a useful step towards being able to clean up various parts of the compiletest frontend.

r? ghost

[Zalathar]

@rustbot experimental

cc @jieyouxu

[Zalathar]

Originally I was hoping to be able to have real rmake recipes that just called a run_make_support::make() function, but after looking at the implementation of run_rmake_legacy_test I quickly gave up on that. So then I got the idea to just have a dummy rmake.rs with a directive instead.

[jieyouxu]

I'm not super keen on doing this just yet, because I feel like we're better served with waiting a bit and just yeeting the entire legacy infra in one go:

• I would still like to first port over the existing Makefiles. I'll try to see if I can push forward with that in the coming week.
• I would prefer to do some prototyping on how a "sane" version of test discovery and directive handling would look like first. I'm worried that trying to do ad-hoc adjustments at the moment might further obfuscate matters than it already is. I should start a bootstrap zulip thread for this, for brainstorming and discussions.

[Zalathar]

It turns out that line_directive is also called by debugger tests to parse its own “directives” with a // prefix. But I hope to be able to eventually split that off to use its own separate parsing function.

[Zalathar]

In the future I'd like to experiment with making the canonical name of a run-make test be the path of its rmake.rs, rather than the path of the enclosing directory. That should help eliminate a bunch of special cases for dealing with Mode::RunMake.

But when I tried, there were enough little complications that I didn't want to do so immediately in this PR.

[jieyouxu]

I have found working with the Testpaths abstraction to be tricky, among other things.

[jieyouxu]

That sounds reasonable to me. Yeah, there are some quirks with a specific primary test file vs directory, but I haven't done an extensive survey on that yet.

[Zalathar]

I'm not super keen on doing this just yet, because I feel like we're better served with waiting a bit and just yeeting the entire legacy infra in one go:

Fair enough. I'm happy to leave this sitting around as an experimental draft of an interesting idea, and if it turns out to be unnecessary (or unwise) then that's a fine outcome too.

[rust-log-analyzer]

The job mingw-check failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

#16 2.878 Building wheels for collected packages: reuse
#16 2.879   Building wheel for reuse (pyproject.toml): started
#16 3.123   Building wheel for reuse (pyproject.toml): finished with status 'done'
#16 3.125   Created wheel for reuse: filename=reuse-4.0.3-cp310-cp310-manylinux_2_35_x86_64.whl size=132715 sha256=dfa09868353292d98f811d3efdb0d54d07389e808efc71d68e3b93c514bf8bec
#16 3.125   Stored in directory: /tmp/pip-ephem-wheel-cache-3vmfn9ni/wheels/3d/8d/0a/e0fc6aba4494b28a967ab5eaf951c121d9c677958714e34532
#16 3.127 Installing collected packages: boolean-py, binaryornot, tomlkit, reuse, python-debian, markupsafe, license-expression, jinja2, chardet, attrs
#16 3.531 Successfully installed attrs-23.2.0 binaryornot-0.4.4 boolean-py-4.0 chardet-5.2.0 jinja2-3.1.4 license-expression-30.3.0 markupsafe-2.1.5 python-debian-0.1.49 reuse-4.0.3 tomlkit-0.13.0
#16 3.531 WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv
#16 DONE 3.6s
---

---- header::tests::revisions stdout ----
thread 'header::tests::revisions' panicked at src/tools/compiletest/src/header/tests.rs:228:5:
assertion `left == right` failed
  left: []
 right: ["hello", "there"]


failures:
    header::tests::revisions

[bors]

☔ The latest upstream changes (presumably #131895) made this pull request unmergeable. Please resolve the merge conflicts.