Allow specifying multiple valid error outputs

[meithecatte]

joining spans together is nightly-only. Because of this, one of my crate's errors looks differently on a stable compiler - the span is slightly less accurate. I would like to test the error output on both the stable and nightly compilers.

I believe the best way to do this is to allow specifying multiple valid error outputs. One way to do this is to look for an .stderr[0-9]+ file. What do you think of this design?

[meithecatte]

I am realizing that the workflow of creating the additional files would be quite involved with the current interface. You would either

• move the existing stderr files out of the way, run tests to create the wip file, move both the previous files and the newly generated file again.
• renumber the existing files to make digit-less .stderr non-existent again. This has the disadvantage of being more cumbersome when the number of variants becomes larger than 2, and also creates unnecessary noise in version control diffs.

This could be improved by adding a TRYBUILD=wip option. In such a case, the stderr files would be written to the wip directory even if the corresponding file output already exists.

[sharksforarms]

Also experiencing this, nightly output is different then stable output which fails some CI steps

[meithecatte]

I ended up working around this by maintaining a separate set of valid outputs for nightly compilers, and overwriting the files in CI. Not perfect, as the tests still fail if they're ran on nightly locally.

[dtolnay]

I think I would prefer not to make a change here. Targeting a single compiler tends to be sufficient for ui tests in my experience (see https://github.com/serde-rs/json/blob/v1.0.62/tests/compiletest.rs for the canonical setup).

If ui testing multiple compilers is really warranted for some reason, then it's easy enough for the #[test] function to arrange the filesystem appropriately prior to calling into trybuild.