Use trybuild to do compile-fail/pass tests (and fix some minor bugs)

[LukasKalbertodt]

Thanks again @CreepySkeleton for mentioning trybuild.

I'm not 100% happy with the crate:

• It doesn't use an own test harness and it's not possible to filter for specific tests (I think)
• One has to add a main function to every single test

But, it works easily and it compares the stderr which is something I wanted for a long time. And it's not super old as compiletest-rs. So I think it's a good idea to make this change, even if the crate is not perfect.

Fixes #55

---

Due to using proper compile-fail testing now, I noticed two bugs actually.

• Our hack in diag.rs uses a thread local variable containing a Vec<_>. If our macro exits when the vector still contains elements, the Rust compiler panics. Not just that, it tries to panic but cannot, leading to a "fatal runtime error" and an abort. Uhg. I should probably create an official issue, though I think using thread locals was never officially allowed in proc macros. Workaround: just clear the vector before we are done.
• We didn't check for #[auto_impl(...)] attributes on trait items other than methods. That's fixed now.

[CreepySkeleton]

Our hack in diag.rs uses a thread local variable containing a Vec<_>. If our macro exits when the vector still contains elements, the Rust compiler panics. Not just that, it tries to panic but cannot, leading to a "fatal runtime error" and an abort. Uhg. I should probably create an official issue, though I think using thread locals was never officially allowed in proc macros. Workaround: just clear the vector before we are done.

Yep, I had to yank one version of my crate due to it 😆

[CreepySkeleton]

Guess what will happen if this panic occurs after you emitted an error?

[LukasKalbertodt]

Nice catch! However, it is clear that the error handling has to change in some way. Either by using your crate or in another way. But that's not something this PR will fix -- I just applied fixes so that nothing immediately breaks. In short: your comment will be addressed in some future PR.

[CreepySkeleton]

And also there's a downside in trybuild - it officially supports only rustc +1.36, but there's a workaround

[KodrAus]

And also there's a downside in trybuild - it officially supports only rustc +1.36, but there's a workaround

Bumping our MSRV is something I’m comfortable with 👍

[LukasKalbertodt]

Regarding MSRV: this is a dev-dependency, right? So users of this crate do not need to worry about it at all. The newer Rust version is just required for testing.

[LukasKalbertodt]

Oh, meh. So now we run into problems where stable/beta/nightly might have different error messages. So our stderr files need to target one of those three?

[CreepySkeleton]

Regarding MSRV: this is a dev-dependency, right? So users of this crate do not need to worry about it at all. The newer Rust version is just required for testing.

Yes. But you won't even be able to run cargo test on pre-1.36 rustc because dev-dependencies cannot be optional.

Oh, meh. So now we run into problems where stable/beta/nightly might have different error messages. So our stderr files need to target one of those three?

The recommended approach here is to run tests only on one channel, presumably on stable to reduce maintenance burden (nightly messages tend to change for no good reason). Personally, I recommend rustversion for this:

#[rustversion::attr(not(stable), ignore)]
#[test]
fn ui() {
    let t = trybuild::TestCases::new();
    t.compile_fail("tests/ui/*.rs");
}

[CreepySkeleton]

@LukasKalbertodt should I base my PR on top of this one?

[LukasKalbertodt]

@CreepySkeleton Yeah, I guess that's a good idea.