We really need to up our testing game here :-) The fact that the easiest way to test this is to write a #[test] instead of writing a #[test] points at the proc-macro shaped hole in our testing infra.

My current thinking is that running fully-fledged proc macros inside tests is not a good idea. I think it would be long-term beneficial if "every test runs in a single, static binary" were an invariant of our code-base.

In the base_db layer, procedural macros are already abstracted away as an arbitrary TokenStream -> TokenStream transformation. So I think what we want to do is to add a dummy, test impl of this trait with some example macros, and use that to write most of the tests. The actual proc macro loading cound then be delegated to a few heavy tests I think.

Ye we should definitely prioritize testing for now.

Regarding async_trait not working here, I imagine(not 100% sure) that might be due to the syn parser being used in the attribute failing to parse the item input when typing in there... so the expansion fails, this of course works fine for the simple #[test] attribute I used for testing since we just feed back the input item without validating 😬 Now I fear that we probably have to do this some other way as most attributes if not all will fail in this manner as they expect fully correct syntax as input.

It doesn't work even for complete syntax self.pref;, so I think that's not the issue

bors r+

Build succeeded:

• Rust (macos-latest)
• Rust (ubuntu-latest)
• Rust (windows-latest)
• TypeScript (ubuntu-latest)
• TypeScript (windows-latest)