libtest: print the type of test being run

[lolbinarycat]

supplemental to #144308

unfortunately because stage1 rustdoc is checked in CI, we need to use cfg(bootstrap) for the transitional period.

cc @GuillaumeGomez

[rustbot]

r? @notriddle

rustbot has assigned @notriddle.
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

[lolbinarycat]

it is very annoying to have to manually bless all the the tests that don't run on x86 linux.

[rustbot]

This PR modifies run-make tests.

cc @jieyouxu

[lolbinarycat]

@GuillaumeGomez ok, got all the tests passing, should be ready for code review now

[jieyouxu]

This changes libtest output, so cc @rust-lang/testing-devex

[GuillaumeGomez]

Changes look good to me, thanks! Gonna wait for devex to confirm it's good for them as well before r+.

[epage]

The bar is pretty low since this is human output and there are no compatibility guarantees

As part of our work to stabilize the json output, we'll be wanting cargo test to do its own rendering, rather than using --format pretty, so the output will likely be dramatically re-imagined at that point (whether or when this affects doctest is dependent on if we are able to get rustdoc out of cargos way). Unsure how or if this will be preserved.

I suspect even libtest's output may change in the shuffle related to json output which would put this at risk.

If you feel this is important enough, I'd recommend engaging on assert-rs/libtest2#42. Note that this feels very coupled to the specific situations and would likely not be good to include in the json as-is.

If people are ok with the risk this gets reverted, I'm not seeing a reason within testing-devex to block this. Considering the lack of guarantees, we don't need an FCP.

[bors]

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