You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a user of cpp!() library, for whatever reason, I may want to write this:
cpp!(unsafe[n as"int"]{
rust!(#[allow(unused)]Rust_myCallback[n :i32as"int"]{// do something with or without `n`})})
Description
Currently, cpp!() macro generates code with two C++ functions: extern "C" wrapper, and actual native C++ function with your code verbatim. It is done so that user's code control flow would not interfere with wrapping glue, e.g. explicit early return statements.
On contrary, rust! pseudo-macro's is to wrap user's code verbatim in a closure. It is purely an implementation details, but if we change it to a function and make that fact public and engraved in stone, then we'd be able to support new syntax with function attributes.
Why?
I wanted to silence clippy's needless_return warning in #93, but I just couldn't narrow it down to just single invocation, since expression/item attributes are not stable yet (and probably would never be). So, using #![allow(...)] attribute inside the block would give me compile error. Using outer #[allow(...)] block in C++ code is obviously not an option. And adding it to the whole top-level cpp!{{ ... }} macro silently did nothing good.
I just showed my particular example. There might be more use cases for attributes. It just feels like an artificial limitation that gets in the way.
The text was updated successfully, but these errors were encountered:
Summary
As a user of
cpp!()
library, for whatever reason, I may want to write this:Description
Currently,
cpp!()
macro generates code with two C++ functions: extern "C" wrapper, and actual native C++ function with your code verbatim. It is done so that user's code control flow would not interfere with wrapping glue, e.g. explicit early return statements.On contrary,
rust!
pseudo-macro's is to wrap user's code verbatim in a closure. It is purely an implementation details, but if we change it to a function and make that fact public and engraved in stone, then we'd be able to support new syntax with function attributes.Why?
I wanted to silence clippy's
needless_return
warning in #93, but I just couldn't narrow it down to just single invocation, since expression/item attributes are not stable yet (and probably would never be). So, using#![allow(...)]
attribute inside the block would give me compile error. Using outer#[allow(...)]
block in C++ code is obviously not an option. And adding it to the whole top-levelcpp!{{ ... }}
macro silently did nothing good.I just showed my particular example. There might be more use cases for attributes. It just feels like an artificial limitation that gets in the way.
The text was updated successfully, but these errors were encountered: