aboutsummaryrefslogtreecommitdiff
path: root/crates/syntax/test_data/parser/inline/ok/0113_nocontentexpr.rast
diff options
context:
space:
mode:
authorbors[bot] <26634292+bors[bot]@users.noreply.github.com>2020-08-16 21:03:06 +0100
committerGitHub <[email protected]>2020-08-16 21:03:06 +0100
commit0b2b9a5508186c16a2e782f47ce7e0e1c5fb8d33 (patch)
tree67baa61adac64374fc70cf22947212abb83be29f /crates/syntax/test_data/parser/inline/ok/0113_nocontentexpr.rast
parent6deb9087bb95352c345470a3e23a9c9f1549bab0 (diff)
parentbee56e68a3e6b8d70bd8320f6372b95959e377df (diff)
Merge #5766
5766: Hacky support for fn-like proc macros r=matklad a=jonas-schievink It turns out that this is all that's needed to get something like this working: ```rust #[proc_macro] pub fn function_like_macro(_args: TokenStream) -> TokenStream { TokenStream::from_str("fn fn_success() {}").unwrap() } ``` ```rust function_like_macro!(); fn f() { fn_success(); } ``` The drawback is that it also makes this work, because there is no distinction between different proc macro kinds in the rest of r-a: ```rust #[derive(function_like_macro)] struct S {} fn f() { fn_success(); } ``` Another issue is that it seems to panic, and then panic, when using this on the rustc code base, due to some issue in the inscrutable proc macro bridge code. Co-authored-by: Jonas Schievink <[email protected]>
Diffstat (limited to 'crates/syntax/test_data/parser/inline/ok/0113_nocontentexpr.rast')
0 files changed, 0 insertions, 0 deletions