#[cleanup(_1st_token=dbg!("--->");,end_token=dbg!("--->");)]
fn tst () -> String {
let tst = 411u32;
let (x, y) = (47u64, 357u32);
let more: i32 = 0;
let mut more: i32 = 1;
dbg!("--->");
println!("tst here");
dbg! ("tst");
dbg!("--->");
more = -35;
while more < 47 { more += 1;}
for h in 0..10 {
let f: u32 = 157;
for k in 1..3 {
let g: usize = 3;
dbg! (&g);
}
}
println!("end here" );
return "tst".to_string()
}
But rustc runs default rules before build.rs & proc_macro. i been eyeing some tricks, however, it dirty ones & they easily can be broken w/ updates of rustc.
I think you are asking that attribute macros (such as your #[cleanup]) should be able to accept inputs which do not parse as their normal item syntax (such as ---> not being a valid statement).
This would be possible (for the parts which are inside {} brackets and thus form a token tree), but I think it is unlikely to happen. One of the advantages of attribute macros over function-like macros is that they do have this rule, which means that tools like rust-analyzer can parse the contents and provide assistance mostly as if they are normal code.
Actually, IT needs to get strong solutions for metaprogramming, otherwise source management becomes too slow & boring. in many cases, i avoid realtime rust-analyzer, because it’s not rare when that tool falls in glitches o/& endless loop w/ dead-frozen ide.
Many people agree that Rust needs better tools for metaprogamming than the macros it has now. In order to help make that happen, you need to present a more concrete proposal, or a problem statement that helps inform the design of a solution, more precisely than just “there is a problem here”. Tell us what you have in mind, more specifically than “strong solutions for metaprogramming”.
build.rs & proc_macro must run before default rules of rustc. In fact, it’s very root of metaprogramming == capability to extend semantics/syntax/api. additional bonus is compiler’s speedup: for now, it runs in order..
