Reconsider if we can use extern "Qt" blocks and if they would have any advantage

[ahayzen-kdab]

With new knowledge about how syn works with parsing we might be able to get it to work.

Would there be any benefit to having an extern "Qt" block as we originally wanted?

#[cxx_qt::bridge]
mod ffi {
    unsafe extern "C++" {
        include!("cxx-qt-lib/qstring.h");
        type QString = cxx_qt_lib::QString;
    }

    extern "Qt" {
        #[cxx_qt::qobject]
        struct MyObject;

        impl qobject::MyObject {
            #[qinvokable] 
            pub fn my_invokable(&self, string: &QString) {
                    println!("String: {}", string);
            }
        }
    }
}

[ahayzen-kdab]

Even with syn changes, this fails due to error: struct is not supported in extern blocks even though our macro removes the invalid code.

An example of this can be seen in https://github.com/ahayzen-kdab/cxx-qt/tree/394-extern-qt

The rustc_parse phase of the compiler is failing here
https://github.com/rust-lang/rust/blob/03770f0e2b60c02db8fcf52fed5fb36aac70cedc/compiler/rustc_parse/src/parser/item.rs#L1175

So then the issue appears to come from the Rust procedural macro attribute, where it appears an attribute macro requires valid syntax whereas a function like one wouldn't.

https://github.com/rust-lang/rfcs/blob/873890e3523a952be84c53d551181ea25a2748c1/text/1566-proc-macros.md?plain=1#L99

The second argument is the tokens for the AST node the attribute is placed on.
Note that in order to compute the tokens to pass here, the compiler must be able
to parse the code the attribute is applied to.