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
I realize that it doesn't promise to compile, but when using --translate-fn-macros to maintain function macros, no line is included for the actual definition of the macro, leading to "cannot find macro `...` in this scope" errors instead of errors about the actual macro code.
Since the original impetus for the addition of this functionality was to possibly improve the rewrite effort (f1c1c38), it would be good to give the developer a pointer to where and how the macro should be defined.
Luckily, the tests already have a file that can demonstrate the issue:
I've been looking into this some, and it occurs to me that converting function-like C macros to Rust macros may not be the right thing to do.
Object-like C macros are turned into Rust constants. Shouldn't function-like C macros be turned into functions? The macro-ness of each has more to do with the C code than the Rust code; if macro behavior is still needed in Rust, can't that be handled inside the Rust function?
Or is the limitation specifically around the lack of a function signature?
Is there a reason this:
#defineTEST_FN_MACRO(x) ((x) * (x))
can't be converted to this:
pubfnTEST_FN_MACRO(x: libc::c_int) -> libc::c_int{ x * x }
In the general case, we can't always convert C macros to Rust functions because they can do very weird things. Even in this example, the C macro is generic over any type that can be multiplied to itself, so the correct Rust function should be generic with a Mul bound. Deducing that from the body of the macro or its use sites is difficult, though.
I realize that it doesn't promise to compile, but when using
--translate-fn-macros
to maintain function macros, no line is included for the actual definition of the macro, leading to "cannot find macro `...` in this scope" errors instead of errors about the actual macro code.Since the original impetus for the addition of this functionality was to possibly improve the rewrite effort (f1c1c38), it would be good to give the developer a pointer to where and how the macro should be defined.
Luckily, the tests already have a file that can demonstrate the issue:
In the corresponding output,
TEST_FN_MACRO!
andinc!
are not defined anywhere.For reference, the original definitions and their relative placement:
c2rust/tests/macros/src/define.c
Lines 3 to 7 in 9eaf8a1
c2rust/tests/macros/src/define.c
Lines 56 to 71 in 9eaf8a1
The text was updated successfully, but these errors were encountered: