Linker error on proc macros that depend on defmt

[p-avital]

First of all, thank you for the immense work you've been doing.

Issue description

Apologies, I haven't been able to make a minimal reproduction of the issue I'm running into while working on proc-macros in zenoh's keformatter branch. I'll try to provide as much information as possible.

Behaviour

Since working on new proc-macros last week, rust-analyzer keeps on showing a failed to run build scripts error, stating in server logs that it "could not compile zenoh-macros" (belongs to the workspace, commons/zenoh-macros).

In VSCode, this causes every usage of zenoh-macros's members to be marked with "proc macro unstable not expanded: no proc macro dylib present" (unstable for instance expands correctly on master).

In Lapce, the error notification appears, but macros appear to be expanded correctly regardless, since type inference and documentation in the examples/examples/z_formats.rs file works.

Note that when building the project, zenoh-macros builds fine, so this issue seems to be RA-specific.

Suspected cause

It appears that rust-analyzer drives the build slightly differently, leading to invalid linkage description files, since linkers on both Windows and Linux complain about syntax errors in lib.def and list (passed through --version-script) respectively.

Server logs on Windows
Server logs on Linux

The directories that contain the incriminated files are deleted by the time I get their path in the logs, so I haven't been able to inspect the files to try and find out more.

Impacted platforms

Linux (Manjaro)

rust-analyzer version: 0.3.1412-standalone
rustc version: rustc 1.67.1 (d5a82bbd2 2023-02-07)
relevant settings: None to my knowledge

Windows

rust-analyzer version: 0.3.1410-standalone (a6603fc 2023-02-16)
rustc version: rustc 1.67.1 (d5a82bbd2 2023-02-07)
relevant settings: None to my knowledge

[lnicola]

Does it work if you disable rust-analyzer.cargo.buildScripts.useRustcWrapper?

[p-avital]

I just gave it a go (restarted all of VSCode for good measure), it doesn't :(

[lnicola]

Maybe try a cargo clean -p zenoh-macros with Code closed.

[lnicola]

If disabling the wrapper helps, you can try setting this as a workaround: https://github.com/lnicola/rust-analyzer/blob/563bd9c24a0620906e4640f57262ea33e48687f0/crates/rust-analyzer/src/bin/rustc_wrapper.rs#L24.

EDIT: no, that won't work.

[p-avital]

Failed again after cargo cleaning. Deleting target also doesn't help either :(

[lnicola]

Strange, for me it works without disabling that setting. Expanding the second macro call in that example, I get formatter.user_id(42).and_then(|x| x.file(file)).

My version.rs says:

rustc 1.67.1 (d5a82bbd2 2023-02-07)
binary: rustc
commit-hash: d5a82bbd26e1ad8b7401f6a718a9c57c96905483
commit-date: 2023-02-07
host: x86_64-unknown-linux-gnu
release: 1.67.1
LLVM version: 15.0.6

[p-avital]

That's the expected expansion (and the one you get through cargo expand), I really don't get why the crate doesn't link exclusively in RA...

It started happening when I first added the zenoh-protocol dependency in zenoh-macros, all the other macros always worked fine before that...

[p-avital]

Ahah, removing ALL of my rust related settings did work, now to find the true culprit. Thanks for letting me know that it could work, I have Settings Sync enabled so whatever setting is messing it up, it was synced between my machines.

[lnicola]

Did you check the contents of version.rs when it failed? I don't know of any settings we have that might cause this except for the wrapper one (in addition to the toolchain version).

Of course, version.rs might be fine. The error is about a linker script, not something we would touch.

[p-avital]

rustc --version --verbose gives me the exact same thing :)

Still looping through settings to find the issue

[p-avital]

AHAH: "rust-analyzer.cargo.allFeatures": true seems to be the thing that breaks zenoh-macros (kinda sad, we use features a lot in zenoh, and all-features is a very good sanity check for that)

[lnicola]

I can confirm, enabling defmt causes this.

[p-avital]

Aight, we were debating whether defmt support was worth it, no I know I'm murdering it, thank you :D

[p-avital]

Again, thank you very much, you've been very helpful and very quick. Feel free to close this issue, unless you want to keep track of that defmt thing.

I am satisfied with my care :)

[lnicola]

It's a bit weird. We seem to load defmt fine, even with --all-features, and same for uhlc. Going out on a limb, maybe @jonas-schievink has an idea about how defmt might interfere with the linker.

[lnicola]

And thanks, by the way!

[lnicola]

Oh, it actually has a linker script: https://github.com/knurling-rs/defmt/blob/main/defmt/defmt.x.in.

[p-avital]

I might have done it wrong, but I tried adding the following

if env::var_os("DEP_DEFMT_LINKS").is_some() {
    println!("cargo:rustc-link-arg-examples=-Tdefmt.x");
}

to zenoh-macros/build.rs, to no avail. We were dropping defmt anyway, but if you see something I'm obviously doing wrong, I'm always happy to learn :)

[p-avital]

We've dropped defmt on zenoh, and I'm going to update the problematic branch.

For future reference, the I'll update the link which pointed to the branch to point to the last problematic commit

[Veykril]

Is this still an issue?

[lnicola]

I can't spot any problems on bd645773e65912428d09fd408009de99352fcd73 with all features enabled, let's close this.