Support incremental in compiletest for non-incremental modes.

[ehuss]

This adds first-class support for using incremental builds in non-incremental-mode tests. These tests previously manually passed -C incremental=tmp/foo which resulted in reusing the same tmp folder between runs. This means that these tests could fail whenever the on-disk incremental format changed (such as when updating one's local source tree). This changes it so that these tests can pass a // incremental-build header which instructs compiletest to create a set aside a dedicated incremental directory which will be cleared before the test starts to ensure it has a clean slate.

[rust-highfive]

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

[ehuss]

There was prior discussion about this at https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Incremental.20ICE.20running.20rustc.20tests.20on.20origin.2Fmaster/near/251211217

It was suggested that these tests could be moved to the incremental directory, but I don't think that is possible because these are codegen tests which are tested differently. I'm not familiar with these tests, so maybe they can be moved, so let me know if an alternate solution would be preferred.

cc @michaelwoerister

[Mark-Simulacrum]

I think we should also consider renaming the flag to "incremental" or "incremental-mode" -- I want to avoid accidentally reading it as similar to 'build-pass' or otherwise tying it specifically to build in that sense.

r=me with the docs and a possible rename, happy to leave it up to you which to choose -- or if you feel strongly about -build, that's also OK.

[ehuss]

Yea, I can see how that can be confusing with -build. I originally used just incremental, but then I noticed that a single English word can be accidentally picked up by a comment like this.

I went ahead and renamed it back to just incremental, since I think incremental-mode would be confusing with true incremental mode tests that support passes. I think the risk of accidentally making a test incremental is low (the existing examples all use -C incremental), and the consequences are low (making a test incremental usually shouldn't interfere with it).

I kinda wish the header parsing was a little more strict so that risk of accidental matches wasn't there.

Feel free to r- if that doesn't sound good, or if the comment I added isn't correct or clear.

[ehuss]

@bors r=Mark-Simulacrum

[bors]

📌 Commit 2da6e66 has been approved by Mark-Simulacrum

[Mark-Simulacrum]

Sounds great, thanks! Yeah, our header parsing story is not great :)

[bors]

⌛ Testing commit 2da6e66 with merge ac8dd1b...

[bors]

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing ac8dd1b to master...

[rust-timer]

Finished benchmarking commit (ac8dd1b): comparison url.

Summary: This benchmark run did not return any relevant changes.

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression