Migrate issue-83112-incr-test-moved-file, type-mismatch-same-crate-name and issue-109934-lto-debuginfo run-make tests to rmake or ui

[Oneirical]

Part of #121876 and the associated Google Summer of Code project.

I have noticed that the new UI test debuginfo-lto-alloc is outputting artifacts that aren't getting cleaned up because of its -C incremental. That might be the justification needed to keep it as a run-make test?

Try it on:

// try-job: test-various // previously passed
try-job: armhf-gnu
try-job: aarch64-apple
try-job: x86_64-msvc

[rustbot]

r? @jieyouxu

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

[Kobzol]

@bors try

[bors]

⌛ Trying commit 2adfa14 with merge 1af7933...

[bors]

☀️ Try build successful - checks-actions
Build commit: 1af7933 (1af79339ef354004955a8edce7e1a949418d3cca)

[jieyouxu]

Thanks! The tests look reasonable, maybe add a remark in the lto test or not, at your discretion, then r=me if another battery of try-jobs come back green ^^

[jieyouxu]

I have noticed that the new UI test debuginfo-lto-alloc is outputting artifacts that aren't getting cleaned up because of its -C incremental. That might be the justification needed to keep it as a run-make test?

If that's the case, let's keep it as a rmake.rs test for now, can you please leave a remark about your finding in case someone tries to port it to ui tests? (We could try to fix ui tests not cleaning this up in another PR, but I'm also fine with leaving it as a rmake.rs test if it does something that's "more special" than ui tests, i.e. I don't want to shoehorn it into ui tests if rmake.rs is less friction).

[jieyouxu]

@bors delegate+ (r=me if try jobs come back green)

[bors]

✌️ @Oneirical, you can now approve this pull request!

If @jieyouxu told you to "r=me" after making some further change, please make that change, then do @bors r=@jieyouxu

[jieyouxu]

@bors try

[bors]

⌛ Trying commit 2adfa14 with merge db5e3a2...

[bors]

☀️ Try build successful - checks-actions
Build commit: db5e3a2 (db5e3a253c0d26497155d86fb733da457e073dd7)

[Oneirical]

@bors r=@jieyouxu

[bors]

📌 Commit 2adfa14 has been approved by jieyouxu

It is now in the queue for this repository.

[jieyouxu]

@bors r-

[jieyouxu]

@Oneirical sorry just to clarify, you said that the lto test has residual artifacts as a UI test, do you think we should keep it as a rmake.rs instead? I would be fine not converting it to a UI test and keeping it as a rmake.rs test if it has special handling that ordinary UI tests do not handle.

[Oneirical]

@Oneirical sorry just to clarify, you said that the lto test has residual artifacts as a UI test, do you think we should keep it as a rmake.rs instead? I would be fine not converting it to a UI test and keeping it as a rmake.rs test if it has special handling that ordinary UI tests do not handle.

Sorry, I missed your upper review comment! I read it now.

When running the UI test locally, some files appear in my file tracker that aren't getting ignored by .gitignore. This would be inconsequential if compiletest resets the UI directory to its original state after the end of testing.

[jieyouxu]

Oh okay cool ty
@bors r+

[bors]

📌 Commit 2adfa14 has been approved by jieyouxu

It is now in the queue for this repository.

[bors]

⌛ Testing commit 2adfa14 with merge e1f45a1...

[bors]

☀️ Test successful - checks-actions
Approved by: jieyouxu
Pushing e1f45a1 to master...

[rust-timer]

Finished benchmarking commit (e1f45a1): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

This benchmark run did not return any relevant results for this metric.

Cycles

Results (secondary -0.6%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.9%	[0.9%, 0.9%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.0%	[-2.0%, -2.0%]	1
All ❌✅ (primary)	-	-	0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 703.792s -> 705.402s (0.23%)
Artifact size: 328.53 MiB -> 328.86 MiB (0.10%)