Jonathan Tanner
Jonathan Tanner
I think @shoogle is correct that this is ok for Muse Sounds because of the CLA. And I personally have no problem with Muse Sounds being proprietary. I do, however...
Indeed, I ran into this issue when linking the generated C++ file with a Rust program. At first I thought it was a Rust issue but they pointed out that...
I am not aware of a C++ compiler whose default linker behaves this way, nor is there an easy fix.
> No worries. What version of rustfmt are you using? The latest nightly, I ran rustup update about an hour ago.
> @aDifferentJT Do you also have an input snippet that we could run rustfmt on to reproduce the issue? Not to hand unfortunately, I haven't yet tried to narrow down...
> were you running rustfmt on a public repo? That might be enough to reproduce the issue. Sorry, no, it's private for now, if I get time in the morning...
I've minimised the file, this seems to be the smallest file that causes the issue [rustfmt_ice.rs](https://github.com/rust-lang/rustfmt/files/14332406/rustfmt_ice.rs.txt) ``` macro_rules! test { ($T:ident, $b:lifetime) => { Box }; } ```
@ytmimi Looks like it's working, thanks
When you turn on Swift/C++ interop the bridging header is parsed as a C++ header. This is just the standard way to make a header that works as both C...
I did try adding the `extern "C" { }` guards around my `#include`, however this fails because the `#include ` and `#include ` do not expect to be surrounded by...