Repository: mozilla/cbindgen (language: rust)

Issue:
--pretty=expanded fails after calling cbindgen in cdylib crate
# Preface

This one is a bit of a doozy and I can't tell if it's a rustc issue or a cbindgen issue or both, so I'm going to cross-report them so both projects can be aware.

I don't have a minimal reproduction, but it is easily reproducible in my repo.

Repo: https://github.com/BVE-Reborn/bve-reborn
Working Commit: [`52b3ec6`](https://github.com/BVE-Reborn/bve-reborn/commit/52b3ec6c232198e7585909f20404b9ee5323bdab)
Failing Commit: [`7799c04`](https://github.com/BVE-Reborn/bve-reborn/commit/7799c04340edefcd52c51023e1271c0bb67d5ad1)

The only difference is the addition of the crate type of `cdylib`. (`rlib` is there, but it reproduces on my next commit which removed it)

# System Info

`Xubuntu 18.04`

Rust and Cargo locked to `nightly-2020-01-16`
rustc: `rustc 1.42.0-nightly (3291ae339 2020-01-15)`
cargo: `cargo 1.42.0-nightly (ad3dbe10e 2020-01-13)`

CBindgen latest, compiled on the same nightly toolchain:
`cbindgen 0.12.2`

# Repro

The rustc command is the exact command cbindgen runs to get macro expanded data.

This all takes place in the root of my repo.

```
cargo build
cargo rustc --lib --manifest-path bve-native/Cargo.toml  -p "bve-native:0.0.0-Placeholder" "--verbose" -- -Z unstable-options --pretty=expanded 
```

Both succeed as expected. However if you call cbindgen it fails, and the rustc no longer outputs anything at all.

```
# Succeeds
cargo build

# Fails citing an issue with compiling
# Occasionally must be run twice
cbindgen bve-native/ -c bve-native/cbindgen.toml -v

# Returns zero, but outputs nothing.
cargo rustc --lib --manifest-path bve-native/Cargo.toml  -p "bve-native:0.0.0-Placeholder" "--verbose" -- -Z unstable-options --pretty=expanded 
# You can call ^ as many times as you want, it will always fail
```

The problem goes away when you `cargo clean` and reappears by running cbindgen again.

# Comments

I have no idea what or who is causing this issue.

I feel like even if cbindgen is ultimately the "cause" of the bug, the expansion shouldn't be able to fail and not output anything without erroring (and returning `!= 0`) in some way.

# Notes:

Possibly relevant cbindgen code: https://github.com/eqrion/cbindgen/blob/master/src/bindgen/cargo/cargo_expand.rs#L129
rustc issue: https://github.com/rust-lang/rust/issues/68333

Thanks!


Discussion / hints:
I've just tested the same commits on Windows 10 1903 and I got the same results. My steps were as follows:

### Setup
- `git clone https://github.com/BVE-Reborn/bve-reborn.git`
- `git checkout test-c-api`

### Known good commit
- `git checkout 52b3ec6`
- `cargo build`
- `cargo rustc --lib --manifest-path bve-native/Cargo.toml  -p "bve-native:0.0.0-Placeholder" "--verbose" -- -Z unstable-options --pretty=expanded `
- `cargo clean`
- `cargo build`
- `cbindgen bve-native/ -c bve-native/cbindgen.toml -v`
- `cargo rustc --lib --manifest-path bve-native/Cargo.toml  -p "bve-native:0.0.0-Placeholder" "--verbose" -- -Z unstable-options --pretty=expanded `

The `cargo rustc` command printed a lot of code both times I ran it

### Known bad commit
- `git checkout 7799c04`
- `cargo clean`
- `cargo build`
- `cargo rustc --lib --manifest-path bve-native/Cargo.toml  -p "bve-native:0.0.0-Placeholder" "--verbose" -- -Z unstable-options --pretty=expanded `
- `cargo clean`
- `cargo build`
- `cbindgen bve-native/ -c bve-native/cbindgen.toml -v`
- `cargo rustc --lib --manifest-path bve-native/Cargo.toml  -p "bve-native:0.0.0-Placeholder" "--verbose" -- -Z unstable-options --pretty=expanded `

This time, the first `cargo rustc` command output a lot of code, but the second one - the one after `cbindgen` - did not
This needs investigation. It's not clear to me that this is a cbindgen bug given the above... It's more likely to be a rustc bug of sorts.
It's just very strange that it only occurs while cbindgen invokes the rustc command, not when done manually. Is there any environment that cbindgen sets that would be different from a normal invocation? Or maybe does cbindgen touch the target folder in some way.

That's why I cross filed, I definitely think the lack of output is a bug, but if cbindgen can do something to mitigate thrle issue that would be good too
I don't think we set anything special, but chances are that cargo has some sort of recursion limit built in or such?
I think you can fix this if cbindgen calls `cargo rustc` with `--profile=check`. That's what `cargo-expand` does and it does not have this problem. It would make sense if the `build` profile were simply extra keen on not running when the build target is up to date.

https://github.com/dtolnay/cargo-expand/blob/b20527c325b0f8fcf4a657a35648dd65ead10ef2/src/main.rs#L280

Confirm. Yep! PR incoming.

Fix patch:
diff --git a/src/bindgen/cargo/cargo_expand.rs b/src/bindgen/cargo/cargo_expand.rs
index 1548fa40b..f960ae5c0 100644
--- a/src/bindgen/cargo/cargo_expand.rs
+++ b/src/bindgen/cargo/cargo_expand.rs
@@ -92,6 +92,7 @@ pub fn expand(
 
     cmd.arg("rustc");
     cmd.arg("--lib");
+    cmd.arg("--profile=check");
     cmd.arg("--manifest-path");
     cmd.arg(manifest_path);
     if let Some(features) = expand_features {


Test patch: