Nightly regression on x86_64_unknown_linux_gnu

[Aceeri]

Travis is failing for me on the newer nightlies, but not previous ones and not on stable/beta. I'm willing to guess it has something to do with procedural macros, since other PRs build correctly on this nightly.

Travis builds for comparison:
Success: rustc 1.19.0-nightly (10d7cb44c 2017-06-18)
Failure: rustc 1.19.0-nightly (04145943a 2017-06-19)

Related PR: amethyst/specs#201

Exits with code 101 with no error messages, just a failure. Can't reproduce on Windows, so I am kind of limited in trying to debug this.

[sfackler]

Seems to work for me (at least locally) on rustc 1.20.0-nightly (9b85e1cfa 2017-07-07) on Linux.

[TimNN]

Ok, I think there's three things going on:

1. rustup is annoying and turns a segmentation fault produced by rustc into an exit code 1
2. The failing rustc invocation uses serde_derive, that is it runs code previously produced by the compiler.
3. IIRC the 2017-06-20 nightly falls into the range of "duplicate drop" nightlies and thus produces bad code.

[Mark-Simulacrum]

It'd be good to verify if this is fixed by rerunning on a more recent nightly. Marking as a regression for now though...

[Aceeri]

@Mark-Simulacrum I just re-ran the travis build and now it seems both nightly and beta have this issue now:
https://travis-ci.org/slide-rs/specs/builds/255438162?utm_source=github_status&utm_medium=notification

[Mark-Simulacrum]

I can't seem to reproduce locally on macOS either...

[alexcrichton]

@Aceeri would it be possible to make a standalone reproduction of this? Right now I'm not even sure how to get access to the commit on my local machine...

[Aceeri]

@alexcrichton I'll see if I can try a couple of things to reproduce it if I can find some time.

[Marwes]

Might have the same bug in combine https://travis-ci.org/Marwes/combine/jobs/261073809. Compiling on windows with nightly works fine as well.

[Marwes]

Reproduction: gist playground

Seems like for some reason x86_64_unknown_linux_gnu segfaults(?) when trying to compile the trait implementation of an extremely nested type. Each tuple implementation in the gist expands a type as Or<A, Or<B, Or<C, ...>>> so it compiles if I implement it only for tuples of lesser arity or if I break up the implementation to have a be wider instead of so deep.

[Aceeri]

That might actually be the problem, I have a macro in mine that recurses ~128 times (each adding to a type with <T as Split>::Next as Split>::Next ...