Stabilize flags for doctest cross compilation

[ehuss]

This makes the following changes in preparation for supporting doctest cross-compiling in cargo:

• Renames --runtool and --runtool-arg to --test-runtool and --test-runtool-arg to maintain consistency with other --test-* arguments.
• Stabilizes the --test-runtool and --test-runtool-arg. These are needed in order to support cargo's target.runner option which specifies a runner to execute a cross-compiled doctest (for example, qemu).
• Stabilizes the --enable-per-target-ignores flag by removing it and making it unconditionally enabled. This makes it possible to disable a doctest on a per-target basis, which I think will be helpful for rolling out this feature.

These changes were suggested in https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/stabilizing.20doctest.20xcompile/near/409281127

The intent is to stabilize the doctest-xcompile feature in cargo. This will help ensure that for projects that do cross-compile testing that their doctests are also covered. Currently there is a somewhat surprising behavior that they are ignored.

Closes #64245

try-job: x86_64-msvc-1

[rustbot]

r? @fmease

rustbot has assigned @fmease.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

This PR modifies tests/run-make/. If this PR is trying to port a Makefile
run-make test to use rmake.rs, please update the
run-make port tracking issue
so we can track our progress. You can either modify the tracking issue
directly, or you can comment on the tracking issue and link this PR.

cc @jieyouxu

The Miri subtree was changed

cc @rust-lang/miri

[bors]

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

[ehuss]

@fmease @GuillaumeGomez Just checking if this can be put on the team's radar?

[GuillaumeGomez]

On my review list now. :)

[GuillaumeGomez]

I think they've been around for enough time. Let's start an FCP then.

@rfcbot fcp merge

[rfcbot]

Team member @GuillaumeGomez has proposed to merge this. The next step is review by the rest of the tagged team members:

• @GuillaumeGomez
• @Manishearth
• @Nemo157
• @aDotInTheVoid
• @camelid
• @fmease
• @jsha
• @notriddle

Concerns:

• forwarding-multi-args-mechanism (Stabilize flags for doctest cross compilation #137096 (comment))

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[ehuss]

In playing around with this, I noticed a slight annoyance when using --edition=2024 and mergeable tests. It always prints:

WARNING: No rustdoc doctest environment variable provided so doctests will be run in the same process

I'm wondering if it would make sense to somehow silence that warning when using --test-runtool?

I'm also wondering if it is the right choice to run in the same process. I could see arguments either way. Let me know if you have any opinion on that.

[fmease]

@rfcbot concern forwarding-multi-args-mechanism

I'd like to block this FCP on a concern I have. Together with the unstable --doctest-compilation-args flag, rustdoc now has (at least) three flags used for forwarding program arguments each of which uses a different mechanism:

1. --test-args (stable): Splits its argument by Unicode whitespace
2. --test-runtool-arg (still unstable): Forwards its argument as is
3. --doctest-compilation-args (unstable): Splits its argument "shell-style"

(All of them can be passed multiple times)

---

I'd like to see this rectified.

[ehuss]

@fmease Can you say more about what you would like to see rectified?

--test-runtool-arg has exactly the behavior we want. We need to be able to pass arguments in without needing to do any processing. I would argue that it is unfortunate that --test-args splits on spaces, since it prevents passing args with spaces, but unfortunately that is stable. I don't know why --doctest-compilation-args is using shell quoting, but that won't work for us (and is generally awkward to use, since you may need to double-encode when using a shell).

[fmease]

Right, it's not something I expect you personally to need to answer, it's more directed toward the team, something I wanted to bring attention to because I only realized this yesterday while reviewing and I don't know if the others were aware of that already of not.

To make this more actionable, I think I simply want confirmation from the other T-rustdoc members that we should do something here, namely either

1. What I initially leaned towards but like less now come to think about it:
   1. Use shell-like lexing for --test-args instead of Unicode whitespace splitting (breaking change)
   2. Change --test-runtool-arg to --test-runtool-args and use shell-like lexing for it, too
2. What I now think is the 'best' option:
   1. Keep --test-runtool-arg as is — unblocking this FCP
   2. (Separately) deprecate the stable --test-args in favor of a new --test-arg that doesn't perform any processing
   3. (Separately) replace the unstable --doctest-compilation-args with a new --doctest-build-arg that doesn't perform any processing either