Force nightly for cargo expand

[rminderhoud]

Problem

The "cargo expand" functionality requires a nightly compiler (see #38). However, if running cbindgen against a crate on a stable toolchain then cbindgen will fail with the following error:

error: the option `Z` is only accepted on the nightly compiler

Solution

The solution is to force "cargo expand" to run using an installed nightly toolchain by adding an additional argument to the command line: +nightly. This allows one to run cbindgen's expand macros logic using an installed nightly toolchain while keeping the actual crate on a stable toolchain.

[rminderhoud]

Build failing due to timeout

No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself.
Check the details on how to adjust your build configuration on: https://docs.travis-ci.com/user/common-build-problems/#build-times-out-because-no-output-was-received

The build has been terminated

[emilio]

You need to remove an .swp file that snuck in. The build issue should be resolved now.

There's technically other ways to make this work (though obviously not recommended) like RUSTC_BOOTSTRAP=1 or such, so I'm a bit reluctant to do this.

Also this inadverently can make users of cbindgen depend on nightly features which is not great... :/

[rminderhoud]

Whoops, sorry about the .swp file. I've removed it and rebased.

I agree it's not ideal but current users of cbindgen don't need nightly unless they use the "expand" functionality which is already required due to the use of the unstable compiler flags. Changing the expand logic to not need nightly was out of scope of what I was trying to do here. I was just fixing an issue that arose in my usage of cbindgen.

This pull request doesn't actually change the requirements of the user, it just fixes the "expand" functionality so that it works on a code base using stable. Before this pull request users needed to use nightly to use "expand" and after this pull request they will still need nightly, except it just won't error out if the target crate is not a nightly crate.

Worth noting that cargo-expand has the same limitation on nightly for the same compiler flag: https://github.com/dtolnay/cargo-expand.

EDIT
I don't know why CI is failing with Compile("error: no such subcommand: '+nightly'\n"). For some reason the toolchain override specifier is not available in the CI environment.

[emilio]

This pull request doesn't actually change the requirements of the user, it just fixes the "expand" functionality so that it works on a code base using stable.

Right, my point is that I'm not convinced that it should work on a codebase using stable :)

[cwfitzgerald]

My codebase is a perfect example of this. I rely heavily on macros to generate a lot of the FFI crap needed for my codebase's C api. I have no actual need for nightly, but these macros must be expanded in order to properly map out the interface to my code. Now, for the time being, I can move my codebase to nightly, but it would be much easier if this allowed you to override nightly, or call cargo expand directly.

[eliaslevy]

Having the same issue here. Part of the FFI is derived using macros (e.g. deriving FFI friendly structs from Rust native ones and implementing From for the native types). Currently getting around it by using RUSTC_BOOTSTRAP in build.rs.

[petrochenkov]

There's technically other ways to make this work (though obviously not recommended) like RUSTC_BOOTSTRAP=1 or such, so I'm a bit reluctant to do this.

I also don't think this should be done, not without an option at least.
I use cbindgen with stable and RUSTC_BOOTSTRAP at work, and I can't install (and regularly update) nightly toolchains because the Rust installation is not controlled by me, all CI works with stable etc.

[emilio]

Yeah, I think we should close this without change for now.

[fzyzcjy]

Hi, is there any possibilities something like this gets implemented? Thanks!