How does upstream syncing work?

[RalfJung]

Currently, there is quite a notable diff between the runtest.rs file in this repo and upstream. Say I wanted to help syncing, what is the usual process? Is there some amount of "expected diff", or should it be verbatim the same thing? Which other files should be synced how?

This process should be documented or else only @laumann will ever be able to do it -- and given the size of the diff and some of the issues, it looks like they could use some help with that.

[Manishearth]

We're hoping to move rustc's compiletest out of tree into this repo so the sync process should become obsolete.

It's more or less a straightforward sync down, with edits to some of the imports IIRC.

[Manishearth]

Those issues exist because we mostly only sync when we really need something new.

[RalfJung]

It's more or less a straightforward sync down, with edits to some of the imports IIRC.

It would be nice to have that diff in the docs somewhere.
Or maybe the move you mention happens soon enough that this is kind-of obsolete?

Those issues exist because we mostly only sync when we really need something new.

Well some other people seem to need some stuff that's not important enough for you to sync. ;) They could help with the syncing (I'd be happy to), but currently it is fairly unclear how.

So what about the status code checking for UI tests? That seems like a critical bug fix (it would have caught the ICEs). Should I open an issue?

[Manishearth]

Yes , once the rust beta stuff settles the next thing people plan to work on on the libtest side is making compiletest-rs the single source of truth.

I'd rather not do a sync while these things are flux. You're free to try: literally copy over the files, go through the diff, and reintroduce any of the compiletest-stable things.

[Manishearth]

I also don't think we've ever done a sync since compiletest on stable was introduced

[RalfJung]

Yes , once the rust beta stuff settles the next thing people plan to work on on the libtest side is making compiletest-rs the single source of truth.

Awesome. :)
Seems fine to wait then, except maybe for #172 to detect ICEs.

[RalfJung]

@Manishearth

We're hoping to move rustc's compiletest out of tree into this repo so the sync process should become obsolete.

What is the status of this?

[Manishearth]

rust-lang/rust#63929

I'm not working on this, but others are, on and off

[RalfJung]

@Manishearth thanks for the update!

[fpoli]

From the discussion at rust-lang/rust#63929 it seems that rustc is not going to depend on a compiletest out of tree. So, what is the future of compiletest-rs? To me, it seems that many tools would benefit from this crate, and that being out of tree would allow to keep handy features like the //~ ERROR syntax. In Prusti we use it a lot and it's fabulous.

[RalfJung]

I forgot where, but I saw some discussions about shipping compilletest with the rustc-dev package (or so). Maybe that is another viable option.

[Munksgaard]

Perhaps an alternative would be to extend trybuild? It already has the basic features of compiletest, but is more self-contained.

[Manishearth]

@fpoli more like the attempt there failed, moving completest and libtest out of tree is still on the cards if someone wants to try.

But we're hoping to ship compiletest in rustc-dev, anyway.