Update dependencies: Use serde_json instead of rustc-serialize, update winapi, log

[messense]

rustc-serialize is deprecated.

[messense]

It seems that Travis CI is disabled?

[messense]

rendered field is unused, should I remove it?

[laumann]

I never answered your question here. I'm about to release 0.3.8 and wondering if this warning should be removed?

[laumann]

I guess it occurs in rustc/compiletest as well?

[messense]

https://github.com/rust-lang/rust/blob/c7cbe142640b2cea1eeb385249faffcf49f0990d/src/tools/compiletest/src/json.rs#L21-L27

It's gone in rustc compiletest, should be removed.

[laumann]

Hmmm, ok thanks for checking that, I'll remove it and release 0.3.9 with that if the need arises

[laumann]

Hi @messense Thanks for your PR!

Any chance you could make this PR against rustc/compiletest? This project tries to maintain (some level of) parity with that project, at least to the point of always building on nigthly. New changes in this project should preferably also be pushed back to rustc/compiletest, otherwise it's going to be harder to maintain this project when changes from rustc/compiletest have to be integrated.

It seems that Travis CI is disabled?

Yes, right now it's just AppVeyor, I haven't really seen the need for both.

[messense]

I don't think it's easy to upstream this, according to rust-lang/rust#40527 (comment)

I think enable Travis CI is needed to make sure things like#[cfg(unix)](for example here) annotations actually work and don't break in the future. cc #97

[messense]

For the maintainability issue, I think this patch is quite small thus should not get in the way of syncing upstream changes to here.

[laumann]

I don't think it's easy to upstream this, according to rust-lang/rust#40527 (comment)

Then I'm reluctant to merge this here, as I'd like to keep the differences between the two projects as minimal as possible. If you look through the history, the most deviation is in lib.rs and other changes are predominantly adding things, not changing existing things.

And for the maintainability, every single change looks small, but this kind of thing snowballs quite easily and then becomes a bigger problem than it should be.

@SergioBenitez has mentioned a few times that this project ideally should be rewritten from scratch to address some of the usability issues that arise when compiletest is used outside of rustc. See #81 for an example. This kind of change belongs there in my opinion. But I'd @SergioBenitez's opinion as well - should we merge this?

[laumann]

I think enable Travis CI is needed to make sure things like#[cfg(unix)](for example here) annotations actually work and don't break in the future. cc #97

Again, couldn't this be addressed by adding another target in AppVeyor to have it built on a un*x platform?

[messense]

Again, couldn't this be addressed by adding another target in AppVeyor to have it built on a un*x platform?

Adding another un*x target on AppVeyor would be fine. Although I am not sure how to do that since AppVeyor is a Windows CI service and it will slow down build time since it only has 1 concurrent build.

[messense]

rust-lang/rust#48798

It's happening!

[laumann]

Yay! Awesome :-) I'll be much happier to merge this then.

[laumann]

Oh, rust-lang/rust#48798 was merged, I'll merge this here then.

[laumann]

0.3.8 is out!