"internal error: entered unreachable code" when expanding function-like proc macros

[autumnontape]

• editor: vscode (official build, version 1.52.0, commit 940b5f4bb5fa47)
• operating system: Arch Linux
• rust-analyzer extension: matklad.rust-analyzer v0.2.408
• rustc: 1.50.0-nightly (803c60218 2020-12-13)

I have a workspace with two crates defining various proc macros and one crate using them. I don't use any proc macros from crates outside this workspace. I only use derive macros and function-like macros, and the derive macros don't seem to be affected.

About half of the function-like proc macro invocations result in the error proc macro returned error: Cannot perform expansion for say: error String("internal error: entered unreachable code") (with the name of the relevant macro in place of "say"):

When I close vscode, delete the "target" directory, and reopen vscode, the same invocations produce errors every time. Whether the error occurs seems to have some strange relationship with the tokens passed into the macro. For instance, this is okay:

say!(sink, (), "Could you rephrase? I don't know if you want to ");

But this errors:

say!(sink, (), ":");

The difference in this case seems to be that the source of the string in the latter is exactly one byte long. ":", "C", and " " all error, for instance, but "::", "", "ü", and "\n" don't. But that's just in this case. This, for instance, also errors despite having no one-byte string literals:

say!(sink, &*world, "or <>.", current_verbs.last().unwrap());

Which macro is being called and where and in what file the invocation is haven't made a difference in my experiments. When editing, the feedback on whether or not the error is triggered is instantaneous, even without saving.

The error only seems to occur, at least visibly, with the latest version of the extension, v0.2.408. If I downgrade to v0.2.400, I stop getting the red squiggly lines.

The project isn't public, and I haven't managed to create a minimal reproduction, but it's a personal project, so I could send a copy privately to a trusted rust-analyzer contributor if you need it.

[lnicola]

Which macro is being called and where and in what file the invocation is haven't made a difference in my experiments.

Do you mean that it might still happen with a proc macro that returns its input unchanged? That might be a path to a minimized test case.

If I downgrade to v0.2.400, I stop getting the red squiggly lines.

The expansion still fails, but the errors are not reported.

[autumnontape]

Do you mean that it might still happen with a proc macro that returns its input unchanged? That might be a path to a minimized test case.

It does still happen if I replace the macro implementations with just input as you say. Some other aspect of the codebase seems to make the difference, and I'm not sure what.

[autumnontape]

Ah, I was wrong, actually. If I replace the macro implementations with a passthrough, close vscode, delete target, and reopen vscode, the "entered unreachable code" error goes away. The main two macros I use (say and say_para) do have a lot of commonality between them, so it could be related to their logic. They don't have any unreachable! invocations, though.

[lnicola]

The target directory shouldn't matter for rust-analyzer, a restart should make it give that error again. Can you try to simplify the macros?

[autumnontape]

I think I'm onto something, but I'm getting the diagnostic "proc macro not expanded" and don't know what that means or how to fix it.

[jonas-schievink]

"proc macro not expanded" means that the proc macro could not be found in the library produced by Cargo.

If you set RUST_BACKTRACE you should see a backtrace in the output window in VS Code, that could help narrow this down.

[autumnontape]

cargo build works fine. Is there any known reason why rust-analyzer wouldn't be able to find the macro?

[autumnontape]

Never mind, I just forgot to set the options that let rust-analyzer evaluate proc macros :p

I have a minimal reproduction now: repro.zip

[lnicola]

Hmm, do I need to do anything special? It works for me (when built from source):

[autumnontape]

The error no longer occurs for any of my macros with the new version that was published about an hour ago.

[lnicola]

Okay, maybe we can close it, but I found it really easy to make it crash: #6880.

[lnicola]

Well, let's close this. I still haven't figured why it's crashing on my computer, but if it works for you, that's great.