Proc macro `task` not expanded: no proc macro dylib present

Editors and IDEs
1

Hello,
I'm trying to develop using embassy on a Fedora 37, unfortunately I constantly get the following error on every proc macro in the code:

proc macro `task` not expanded: no proc macro dylib present

I suspect I am missing some library in my system, but unfortunately the error is not helpful enough for me to solve the issue myself. Is there some way that I can get more information on what dylib is missing and how I can solve it?

2

Try setting the rust-analyzer.cargo.target env var to whichever target you are building your project for. I think embassy will fail to compile for the host and thus not get the proc macro compiled.

1 Like
3

I tried doing that. This problem occurs even on the example projects (including the std one).

The std example should compile on the normal "x86_64-unknown-linux-gnu" target. I tried to set that up with no luck - still the same error.

4

Which rustc and rust-analyzer versions are you using? And are you using a rustup version of rustc or the one included in Fedora? Does $(rustc --print sysroot)/libexec/rust-analyzer-proc-macro-srv or $(rustc --print sysroot)/lib/rust-analyzer-proc-macro-srv exist and if so which one exists?

5

I have the following rustc version:

$ rustc --version
rustc 1.68.0-nightly (4c83bd03a 2023-01-19)

installed via rustup.

(rustc --print sysroot)/libexec/rust-analyzer-proc-macro-srv exists, the other one does not.

I had a strong suspicion that rust-analyzer doesn't like what Fedora Kionite/Silverblue 37 is doing with the home directory - the /home directory is a symlink to /var/home. To verify if that may be a problem I performed the following tests:

  1. Prepared the same setup on a normal Fedora 37 and it seems to work there.
  2. Prepared the same setup in a different (not-symlinked) directory (/tmp to be precise). Seems to work as well.
  3. Did a cd /var/home/.../embassy/example && code ./std (so used the real path, not the symlinked one) and it seems to resolve the proc-macros too.

There's clearly some bug somewhere, either in how Fedora Kionite/Silverblue 37 handles the symlink or setup of some environmental variables, or how rust-analyzer handles cases where the parent directory has a symlink.
Bjorn, do you have any idea how can I help debug this issue so it can be fixed in the right place?

6

There is issue for rust-analyzer misbehaving with symlinked paths: Spurious rebuilds when VSCode opened through symlink · Issue #13593 · rust-lang/rust-analyzer · GitHub This is an issue about cargo rebuilding things unnecessarily though and not about proc macros not working. Would you mind opening an issue? As for debugging, could you set the RA_LOG env var to warn;project_model=info before starting VSCode and then show what the "Rust Analyzer Language Server" output tab shows for the broken configuration?

7

@bjorn3 seems that after running a project at least once with the non-symlinked path the problem disappeared completely.

To try to force-reproduce it I uninstalled rust via rustup toolchain uninstall ... and removed the ~/.cargo/registry directory but no luck - the problem seemed to disappear.

Is there some other cache directory which should be cleared?

8

Did you try removing the target dir in the project source dir?

9

I did just now - still can't reproduce. I feel like I'm loosing my mind :D. I'll try to recreate the issue on a clean Fedora Kionite 37 installation later today and share my findings.

11

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.