Disabling of -Zunstable-options --pretty=expanded breaks cbindgen

[jrmuizel]

cbindgen needs to parse macro expanded rust code in order to generate C/C++ bindings. The removal of --pretty=expanded breaks this. What's the suggested path forward here? Not having this forces binding generation to be done with a nightly tool chain and the results checked in to the tree instead of being done at build time.

[nagisa]

The approach for you would be to ask for a stable flag for this of some sort. We’ve already stabilised a few on request, e.g. --emit=mir.

[staktrace]

See also #43364.

[nrc]

We really should not stabilise --pretty it is a bit of a mess. The least bad CLI option seems to be --emit=expanded to emit the macro-expanded code. However, I also don't like this - the generated code is not guaranteed to compile (because hygienic names are not reflected in the generated source text), it means a big chunk of compiler code (pretty printing) is now exposed to stable users, and I worry about bugs, etc. in that code.

I think an ideal solution is that cbindgen should not be looking at expanded code, but at the AST post-expansion (or the TokenStream, though that is not easy right now) - I assume cbindgen has to do some parsing of its own? However, that is also unstable (and actually likely to change, c.f., the output of --pretty expanded), so not very practical.

Another solution might be using a shim compiler driver - this is what the RLS will do - see https://github.com/nrc/rls-rustc. That would mean that building cbindgen would need a nightly compiler, but running it (i.e., compiling webrender or whatever) would work with a stable toolchain (unless the output of --pretty expanded changes between versions).

How does the shim solution sound?

[nrc]

@jrmuizel do either of the above solutions sound reasonable to you?

[jrmuizel]

I think we should be able to work something out.

[steveklabnik]

Triage: this is a very old issue. was something worked out? Can we close it?