Open rlidwka opened 5 months ago
actually, that's not supported yet in syn
: https://github.com/dtolnay/syn/issues/1502
Seems like sending a PR to syn would be the way to go, then once that's merged we can use it...
Seems like sending a PR to syn would be the way to go, then once that's merged we can use it...
looks like it's already merged: https://github.com/dtolnay/syn/pull/1622
@emilio I am currently blocked from using C string literals in my project due to this issue. Would be great to pull in the latest syn
and publish a new version of cbindgen
.
We presumably also need to use them somehow right? Maybe can be a follow-up tho.
I believe this can be closed since PR #961 was merged
Ah, I just found the Unrecognized literal
panic. It would be cool if a new release was cut so I could use c literals.
Also do note that this does not fix the issue of #324 namely that &CStr
is not FFI compatible. Rust's CStr
is a fat pointer, so you cannot expect that a pub const CStr to be able to be passed to C(++).
It is currently documented that it may become a thin pointer in the future, but it seems less likely as time goes on.
We have C string literals now stabilized in Rust since https://github.com/rust-lang/rust/issues/105723 (since v1.77.0, which'll be released next month).
It seems reasonable to have const string literals like these:
and convert them to
#define
orconstexpr
or whatever cbindgen usually does with constantsCurrent behavior is very much not ideal (probably need to update syn to v2?):