Add more granular --exclude in x.py

[emilyalbini]

x.py has support for excluding some steps from the current invocation, but unfortunately that's not granular enough: some steps have the same name in different modules, and that prevents excluding only some of them.

As a practical example, let's say you need to run everything in ./x.py test except for the standard library tests, as those tests require IPv6 and need to be executed on a separate machine. Before this commit, if you were to just run this:

./x.py test --exclude library/std

...the invocation would eventually fail, as that would not only exclude running the tests for the standard library (library/std in the test module), it would also exclude generating its documentation (library/std in the doc module), breaking linkchecker.

This commit adds support to the --exclude flag for prefixing paths with the name of the module their step is defined in, allowing the user to choose which module to exclude from:

./x.py test --exclude test::library/std

This maintains backward compatibility with existing invocations, while allowing more ganular exclusion. Examples of the behavior:

--exclude	Docs	Tests
library/std	Skipped	Skipped
doc::library/std	Skipped	Run
test::library/std	Run	Skipped

Note that this PR only changes the --exclude flag, and not in other x.py arguments or flags yet.

In the implementation I tried to limit the impact this would have with rustbuild as a whole as much as possible. The module name is extracted from the step by parsing the result of std::any::type_name(): unfortunately that output can change at any point in time, but IMO it's better than having to annotate all the existing and future Step implementations with the module name. I added a test to ensure the parsing works as expected, so hopefully if anyone makes changes to the output of std::any::type_name() they'll also notice they have to update rustbuild.

r? @Mark-Simulacrum

[the8472]

Isn't the problem one of dependency management rather than path includes/excludes?

Either linkchecker has to force library/std docs to be generated even when they're excluded or excluding them must also cause linkchecker to skip checking the std docs because a dependency is not met.

[emilyalbini]

To clarify, in theory linkchecker could pass even if the standard library docs were skipped: the problem is that other documentation links to the standard library docs, so if the standard library docs are not there linkchecker will identify those links as broken.

Changing the linkchecker step to always build all docs would indeed solve the specific problem I'm facing when excluding the standard library tests, but would also prevent other use cases: at least I have occasionally done ./x.py test src/tools/linkchecker --exclude $foo to get a list of all links pointing to the $foo documentation, and such change would prevent that. I can imagine there are also other use cases I'm not thinking about.

[petrochenkov]

cc #91794

[Mark-Simulacrum]

I'm not actually sure this is the right implementation strategy. The module is not really a user-visible thing; and eventually some Steps may work for multiple different modules (Kind, in bootstrap terminology).

You should be able to adjust the match arms here to pass in the kind to StepDescription::from in some way, I think? Not sure if that'll work too easily, may need some refactoring. Ideally the strategy pursued should take into account the possibility for one struct implementing Step to have multiple different "kinds", though that might be painful -- let's try to avoid doing something that prevents it from happening in the future, at least, if possible.

[the8472]

To clarify, in theory linkchecker could pass even if the standard library docs were skipped: the problem is that other documentation links to the standard library docs, so if the standard library docs are not there linkchecker will identify those links as broken.

Changing the linkchecker step to always build all docs would indeed solve the specific problem I'm facing when excluding the standard library tests, but would also prevent other use cases: at least I have occasionally done ./x.py test src/tools/linkchecker --exclude $foo to get a list of all links pointing to the $foo documentation, and such change would prevent that. I can imagine there are also other use cases I'm not thinking about.

I still think --exclude is the wrong thing to modify here. Maybe linkchecker itself needs an option to inform it what should be excluded from checking? Via --test-args for example.

[Mark-Simulacrum]

The motivation (in my eyes) is not necessarily to fix/prevent the link check problem - I agree that has a different solution, likely with an error on excluding "too much/too little" for required dependencies like this. But the desired error there may want to suggest either excluding link check or limiting the standard library exclude, I think - though not sure.

[emilyalbini]

Changed the PR to use Kind and rebased to fix the merge conflict.

[Mark-Simulacrum]

r=me with commits squashed (particularly the last two); I was going to do this myself but it looks like the push permissions aren't setup such that I can do that.

[emilyalbini]

Squashed.

@bors r=Mark-Simulacrum

[bors]

📌 Commit b3ad405 has been approved by Mark-Simulacrum