Recompile macro on error

[numfin]

Lately I get a lot of "macro expansion" errors. Is it possible to restart/recompile those macros on next "save" event if error happens?

[ChayimFriedman2]

I don't understand what you want. Are you talking about proc macros or macro_rules? Do the errors come from rustc or rust-analyzer?

[numfin]

@ChayimFriedman2 hi, thanks for asking:

Right now when i'm saving file with sqlx macro i get error communicating with database: Connection refused macro error.

When i'm starting database and saving file again - error persist.

To make error disappear i have to restart rust-analyzer completely

[ChayimFriedman2]

If it appears only on save, it's probably a rustc error. Can you share the full error (when you hover over it)?

[lnicola]

When i'm starting database and saving file again - error persist.

I think we cache the proc macro expansions (we couldn't know when we have to re-run them), and IIRC rustc is also experimenting with this. You should probably try the "offline mode" of sqlx instead.

[numfin]

yeah i know about offline mode.
The problem is that sqlx is only one of the macros that quits with error. Other macros panic too.

Next time when i get panic from proc macro (not from sqlx) i will try to save as much info as possible (solution is to restart rust-analyzer too). Because errors are random and not 100% reproducible

Until that happens please don't close this issue ❤

Idea is to invalidate cache when any error happens (yeah its hard, but i believe DX can be improved here)

[ChayimFriedman2]

Let's be clear: we don't and never will properly support macros that use side channels like reading from a db. We will cache macros, and not rerun them on every change, otherwise IDE experience will be catastrophic.

[lnicola]

Idea is to invalidate cache when any error happens

That's not going to help if you change your db schema and the macro doesn't know about it. And if the compiler moves towards caching proc macro expansions, these crates will have bigger problems on their hands.

[numfin]

Again it's not only about sqlx. Other macros are panicking too (or rust analyzer panicking. I don't understand from logs).

No need to rebuild every macro on every save. Only when error occurs - rebuild failed macro

[ChayimFriedman2]

What other macros are failing?

Rerunning even failed macros on every type is not an option.

[numfin]

I will provide more info when i get to my pc.
Why is it not an option? Is it because everything should be build together?

[ChayimFriedman2]

Why is it not an option? Is it because everything should be build together?

No. It is not an option because it will degrade performance to the borderline of being usable.

Also note that it's very hard to detect when a proc macro is failing. Detecting panics is easy, but what happens when a macro emits a compile_error!() (which is the recommended way for proc macros to fail, not panicking)? Or what if there is no compile_error!(), but the code doesn't pass type checking?

[numfin]

I see how it is difficult right now to implement. But i don't really understand how it will affect performance in any way (was it done before?).
I don't understand how RA works, but in my head implementation would be smth like having a map of macro usages and each time it executes - we record failure that needs to be reexecuted.

it's probably much more complicated, but i believe some mechanisms need to be implemented in order to achieve better dx.

[ChayimFriedman2]

It will affect performance because it will mean we will have to re-execute failed macros on every keystroke. It is also hard to implement as we can't have side maps in r-a. Furthermore, it barely helps. If you change the db schema but type nothing in the editor, we have no way to know something has changed. And you can change the db schema when the macro succeeds to, and make it fail; so rerunning only failed macros does not solve the problem.

But above it all, macros that use side channels like reading a db are a hack, fundamentally opposed to how r-a is operating, and also unsupported by the letter of the law. And, like @lnicola said, if rustc will also start following the letter of the law, they will be in bigger problems.

[numfin]

What if we don't have to re-execute it on every keystroke? For example i have cargo-check only on save. Also this can be an opt-in feature: "do you want to recompile failed macros on each check?". This way people who want this feature - can turn it on.
Stateful compilation is valid concern! I haven't thought about that.

Btw i'm sorry i confused you recompilation of sqlx is not required since it currenly working correctly: when i save after connection error - it re-executes properly. The only problem i'm talking about right now are panics that requires me to restart rust-analyzer when error occurs. What exact errors i will write here when i get them again.

[ChayimFriedman2]

Does panics still persist after you edit the macro's input? If it does it's a bug, unless sqlx caches the db connection in a static or something, and then it's something we completely don't support (and IMHO should be filled against sqlx, not rust-analyzer, at least to not cache if there was an error connecting).

Check on save already causes major troubles for us due to code complexity. I definitely don't want to even imagine how it will look like if we add this. The cost is just not worth the benefit. For the same reason a setting does not help.

[numfin]

@ChayimFriedman2 yeah error persist, i have to restart RA to make it disappear. Same error with other macros too, not just sqlx.

[ChayimFriedman2]

What other macros?