feat: Add config to replace specific proc-macros with dummy expanders #11193
Conversation
Veykril
force-pushed
the
proc-config
branch
2 times, most recently
from
e4cfb01 to
a6d4bc3
Compare
|
r? @matklad Since you have a better view on the |
|
Make sense! I wonder if, as a follow up, we should allow to specify this in metadata section of cargo-toml? |
| pub(crate) fn load_proc_macro( | ||
| client: Option<&ProcMacroServer>, | ||
| path: &AbsPath, | ||
| dummy_replace: &[Box<str>], |
There was a problem hiding this comment.
I wonder if perhaps we should implement this on the higher level and treat such macros as inert attributes?
ah, I see you’ve considered that. I wonder if we can treat this as a custom tool attribute (#[rustfmt and such)
There was a problem hiding this comment.
tool attribute would be nice in theory, but since those are unstable and therefor require a feature flag I am doubtful that people would even bother using it
There was a problem hiding this comment.
I mean, we presumably have some infrastruture internally to track tool/intert attributes and say things like "inline does nothing". We can use that same infrastructure to implement this feature. Ie, this is about impl detail rather thatn about API.
Basically, make #[tokio::main] behave like #[inline] rather than #[identity].
As in proc-macro crates can tell r-a to not have their macros expand(be dummy expanded)? |
|
bors r+ |
With this one can specify proc-macros from crates to expand into their input as a (temporary) workaround for the current completion problems with some of the bigger attribute proc-macros like
async_trait.This could've been done by just not expanding these macros, but that would require fiddling with nameres. I felt like this approach was simpler to pull off while also keeping the behaviour of the attributes/proc-macro in that they still expand instead of being dead syntax to us.
Fixes #11052