@fasterthanlime yep I'm just writing my first non-trivial derive macro and it's grueling. Not that the trivial derive macros were fun to write either. This really shouldn't be needed.
I really dislike that derive macros have to essentially ship their own parser to access some form of AST: introspection would solve that and yeah, we missed out on that rustconf talk + work, didn't we.
And yeah I understand some proc macros essentially need to be parsers because they extend the syntax or whatever, sure. And I understand API compatibility for an AST is really hard (I studied the proc macro bridge) but that's... such a waste of CPU cycles.
@fasterthanlime if only the compiler itself exposed this kind of API... but that would require shared libraries or some sort of shared memory to get the info, which i don't think the rustc team would like
@fasterthanlime cranelift with optimizations is still much slower than debug mode, iirc. perhaps you could find a better balance than -O0 though, specifically for build scripts. even with LLVM.
@fasterthanlime have to wonder how many other amazing ideas (and implementations) have been buried in Rust and elsewhere because of someone's "can't have nice things unless they're my nice things" but no one spoke up about it :(
@fasterthanlime Not just ship their own parser, but also a greedy parser at that. Want to look at a function signature? Better parse its body down to the last tiny statement!
Venial (https://github.com/PoignardAzur/venial) at least got that particular part right, but it's a hard sell basically because nobody's using it and is still lacking features.
The whole thing is just a bit sad IMO. There's not even that many people who understand proc macros or learning materials to teach them.