Since the architecture being tested should be injectable via environment variables from outside, expanding this support to all architectures currently supported by wild should be achievable when running these tests via GitHub Actions.

Thanks for working on this PR! Don't worry about those two test failures on ubuntu:25.10, they're not related to your change and have been happening all day. We might need to disable 25.10 if they continue.

My first question is how does this use wild as the linker when running the tests?

@davidlattimore Sorry, I simply forgot to add the PATH modification 😅 and have now corrected it (I've also updated the list of passed tests and the output of cargo test).

Have a couple of general comments:

1. I would really like direct integration of the individual tests from the Mold's test suite using the following compile-time glob listing: https://docs.rs/rstest/0.25.0/rstest/attr.rstest.html#files-path-as-input-arguments.
2. Having that, the test harness will run the tests in parallel, as we won't have to implement our own parallelism.
3. It would also be great to list all the known failing Mold tests and have XFAIL (fail the test if the test is actually passing).
4. As a follow-up, I know Mold's test suite supports running cross-arch tests using QEMU; it would be nice to support it.
5. Filtering of tests/arch-* should depend on the host system.
6. To prevent the Mold test-suite output, I would consider suppressing set -x, which is set by common.inc.

One potential integration opportunity would be adding Mold as a submodule of the project.
@davidlattimore: What do you think about it?

One potential integration opportunity would be adding Mold as a submodule of the project.
@davidlattimore: What do you think about it?

I guess that should be OK. Perhaps in a subdirectory. e.g. external_test_suites/mold

One potential integration opportunity would be adding Mold as a submodule of the project.
@davidlattimore: What do you think about it?

I guess that should be OK. Perhaps in a subdirectory. e.g. external_test_suites/mold

I'm generally reluctant to use external test suites as submodules:

1. Submodules require the entire repository. Since we only need the test suite itself, this is excessively redundant.
2. If there are updates to the external test suite and we want to incorporate those changes, we'd need to explicitly update the submodule (this is just one example - we could maintain the mold test suite itself as a GitHub Actions cache and periodically update the cache at fixed intervals like weekly via cron jobs, allowing CI to automatically obtain the latest results without manual intervention).

• Submodules require the entire repository. Since we only need the test suite itself, this is excessively redundant.

Well, yes, but we're speaking about a rather small git repository.

• If there are updates to the external test suite and we want to incorporate those changes, we'd need to explicitly update the submodule (this is just one example - we could maintain the mold test suite itself as a GitHub Actions cache and periodically update the cache at fixed intervals like weekly via cron jobs, allowing CI to automatically obtain the latest results without manual intervention).

That's, from my perspective, a desired feature. Every time we pull Mold's changes, one needs to triage new tests and mark them as passing or failing. Otherwise, everyone from Wild's developers will stick to a different revision of Mold, and then we'll see test suite pass rate inconsistency.

Plus, having the test suite at a fixed location will simplify any current code that deals with the proper finding of the tests.

You also do not always have to initialize the submodules. This is how the Rust compiler repository works. It has some necessary submodules, like docs, but you can skip others depending on your build configuration.

That's, from my perspective, a desired feature. Every time we pull Mold's changes, one needs to triage new tests and mark them as passing or failing. Otherwise, everyone from Wild's developers will stick to a different revision of Mold, and then we'll see test suite pass rate inconsistency.

I think this argument is a pretty compelling reason to want either a submodule, or some other mechanism that involves having the commit hash of mold to use checked into our repo.

1. I would really like direct integration of the individual tests from the Mold's test suite using the following compile-time glob listing: https://docs.rs/rstest/0.25.0/rstest/attr.rstest.html#files-path-as-input-arguments.

This would definitely be very nice and from the look of things, I think shouldn't be too hard.

It's also fine to leave changes until later PRs if you prefer - just let us know which things you'd like to leave for later.

Submodules and nix flakes interact extremely poorly for very silly reasons. I have no clue how to get them to work together after messing with it for a few minutes and googling around. If it is holding you up, you can comment out these lines and it should work
https://github.com/davidlattimore/wild/blob/c2e0af40fd040a556d9ebf27e93d7f1ed4893f8e/flake.nix#L49-L57

It looks as though rstest is giving an error at build time if the file pattern doesn't exist. That's unfortunate. The only solution I can think of at the moment would be to put that test behind a cfg. e.g. #[cfg(feature = "mold-tests")]

Or, if we wanted it to be driven by test-config.toml then we could have a build.rs that parses test-config.toml and if the mold tests are enabled (which could be a boolean in the config) prints cargo::rustc-cfg=mold_tests. It'd also need to print cargo::rustc-check-cfg=mold-tests regardless of whether they're enabled. It should also print cargo::rerun-if-changed=test-confiig.toml. Then in the code, you can use #[cfg(mold-tests)].

I'm curious if we could simply remove the build.rs file (and the integration into config.toml) and manually drive the testing of Mold's test suite using a cfg feature? Doing that, we'll end up with a much smaller change?

I'm curious if we could simply remove the build.rs file (and the integration into config.toml) and manually drive the testing of Mold's test suite using a cfg feature? Doing that, we'll end up with a much smaller change?

I was exactly struggling with the best way to centrally manage ExternalTestSuites when your suggestion about using feature flags seemed particularly promising. Thanks!

I'm curious if we could simply remove the build.rs file (and the integration into config.toml) and manually drive the testing of Mold's test suite using a cfg feature? Doing that, we'll end up with a much smaller change?

I was exactly struggling with the best way to centrally manage ExternalTestSuites when your suggestion about using feature flags seemed particularly promising. Thanks!

I guess that means that we don't need anything in test-config.toml - whether we look for and run mold's test suite is controlled entire by --features mold-tests or something like that. That is nice and simple :) It also has the advantage that we can choose from run to run whether we want to run those tests.