Audit `//@ run-pass` directives in UI tests

[cyrgani]

Many older UI tests still use the //@ run-pass directive, even though they could just use //@ build-pass or //@ check-pass. We should make sure that //@ run-pass is only used when needed. (For example, a test about macro expansions might be fine with just //@ check-pass, a codegen test might need //@ build-pass and a test with runtime assert_eq!s should stay on //@ run-pass.)

[Embers-of-the-Fire]

I might have time to audit some of the existing use cases, so @rustbot claim

[petrochenkov]

I'm about 80% sure there's an old issue about this.

A good heuristic for a suspicious run-pass test is having an empty fn main.
Unless such tests uses something exotic like life-before-main, they can be demoted to build-pass at least.

[Ayuse]

Hello @Embers-of-the-Fire I can see you have started some good work on the audit, its quite a lot and would like to help out, kindly let me know how i can come in, thank you

[Embers-of-the-Fire]

A good heuristic for a suspicious run-pass test is having an empty fn main.

I tend to be more cautious about these changes, since some tests might rely on things like static. Anyway, thank you for your help.

its quite a lot and would like to help out, kindly let me know how i can come in

@Ayuse Just open a pr against my fork :) so that I could know what you're working on. I would do the squash work once finished.

[Ayuse]

Okay @Embers-of-the-Fire I have started some work on it, you can track it here