Remove serde_derive dependency, inlining expanded impls into source code

[eqrion]

This commit removes the dependency on serde_derive so that
cbindgen doesn't depend on a stale package for OS's like debian.

A new file, README.serde_derive is added with instructions on
how to regenerate the impls with changes.

[eqrion]

r? @emilio

You obviously don't have to review the copy and pasted impl's, I'm more interested in a sanity check.

This will unblock the uploading of cbindgen to Debian and shift the burden of this issue from users to the maintainers.

There might be a CI failure, I didn't run this through rustfmt yet. Hopefully the autogenerated stuff is fine.

[eqrion]

... and there are rustfmt errors. I'll sprinkle #[cfg_attr(rustfmt, rustfmt_skip)] over the commit and repush.

[dtolnay]

Be aware that the generated code uses serde private APIs so is not guaranteed to compile or do the right thing against newer serde versions. That's fine within cbindgen as long as the impls are regenerated every time serde is bumped in Cargo.lock, but means that if you want other crates to use cbindgen as a library then you will need to pin a specific serde version in cbindgen's Cargo.toml. Otherwise things will break (frequently).

[eqrion]

Be aware that the generated code uses serde private APIs so is not guaranteed to compile or do the right thing against newer serde versions. That's fine within cbindgen as long as the impls are regenerated every time serde is bumped in Cargo.lock, but means that if you want other crates to use cbindgen as a library then you will need to pin a specific serde version in cbindgen's Cargo.toml. Otherwise things will break (frequently).

That's an understandable policy, I hadn't thought of that.

Thinking about it further, I'm not sure we can even rely on Cargo.lock for binaries as cargo install cbindgen doesn't use the lock file in my experience.

[eqrion]

I suppose this change amounts to pinning serde instead of pinning serde_derive.

There is one benefit I could see to this, we can update the pinned version of serde when needed but currently can't with serde_derive. Still not a great solution.

[emilio]

I don't think doing this is worth it. It's going to be a major pain for us and contributors alike...

If we really have to do it (which I think it's debatable if the main issue is 'old serde_derive version can't be backported to beta in Debian'), I'd rather put all the autogenerated stuff in a separate file and include! it or something, so at least it doesn't make searching a file a pain.

I think this is missing a bunch of #[cfg_attr(serde_derive, derive(Serialize)] annotations so that the updating instructions actually work isn't it?

[emilio]

I think I disagree with this FWIW.

[emilio]

These are all missing #[cfg_feature] bits right?

[emilio]

Actually bindgen has the same issue (see rust-lang/rust-bindgen#1409)... Sigh. I'd rather go fix rust-lang/cargo#2589 instead fwiw.

[dtolnay]

If the reason that this serde_derive dependency is a problem is that it enables proc-macro2's "proc-macro" feature and that ends up trying to dynamically link the compiler into cbindgen, then dtolnay/proc-macro2#139 (comment) may be a shorter path to fix that. We'd like for libproc_macro's build story to be no different from libcore or liballoc, meaning no more dynamic dependency on the compiler.

rust-lang/rust#49219 is much of the work to get there.

[eqrion]

I'm going to close this PR and put this on hold as it doesn't really sound like an attractive option. The work around libproc-macro sounds like a promising path.