serde_derive mod try; is seen as a syntax error by rust-analyzer 0.2.320 (2020-09-21).

[staninprague]

Thank for the excellent tool for the rust development!

After updating to rust-analyzer version 0.2.320 today, I'm seeing rust-analyzer complaining about unresolved import:

use serde_derive::{Deserialize, Serialize};

With error in serde_derive being at line:

mod try;

try part is highlighted. Please see the screenshot attached.

Updating to 0.2.320 (2020-09-21) was the only change. Cargo build runs with no errors.

[bjorn3]

Rust-analyzer doesn't have much support for the 2015 edition. In the 2018 edition try is indeed a keyword.

[staninprague]

This is in serde_derive 1.0.104, it is using rust 2018? When I look at the serde_derive master here:

https://github.com/serde-rs/serde/blob/b539cb45d7e1460c42aea8201e29e711f37cd198/serde_derive/src/lib.rs#L76

mod try;

Is still there.

Rolling back to rust-analyzer 0.2.313 solves the issue.

I see try is really a keyword in rust 2018:

https://doc.rust-lang.org/reference/keywords.html

Question is that here rust-analyzer contradicts the cargo. Cargo builds on 1.46.0 rust with no problem. Rust-analyzer sees the issue.

This is not my mod try; line, this is serde_derive. It's going to affect a lot of devs, I think? Or this is something I can fix on my machine?

[staninprague]

One more note on this. From the rust keywords page here: https://doc.rust-lang.org/reference/keywords.html#strict-keywords

**Strict keywords**

These keywords can only be used in their correct contexts. They cannot be used as the names of:

Items
Variables and function parameters
Fields and variants
Type parameters
Lifetime parameters or loop labels
Macros or attributes
Macro placeholders
Crates

Does it mean that serde_derive is ok with using mod try; for the module (not crate) name? I'm not an expert in any way. Sorry if I'm digging in the wrong direction.

[bjorn3]

Rustc in the 2018 edition gives:

error: expected identifier, found reserved keyword `try`
 --> src/lib.rs:1:5
  |
1 | mod try;
  |     ^^^ expected identifier, found reserved keyword
  |
help: you can escape reserved keywords to use them as identifiers
  |
1 | mod r#try;
  |     ^^^^^

[bjorn3]

serde_derive is still using the 2015 edition. There is no edition = "2018" in https://github.com/serde-rs/serde/blob/b539cb45d7e1460c42aea8201e29e711f37cd198/serde_derive/Cargo.toml.

[staninprague]

True. There is also a discussion about moving serde to 2018 edition. But looks like there is no milestone or plan for that, also based on serde compatibility back to Rust 1.13:

serde-rs/serde#1867

Question is then if rust-analyzer will be enforcing rust 2018 keywords on non-2018 code. Serde_derive is an important library for many devs, I think. The change with mod try; interpretation came in 0.2.320 today and now somehow rust-analyzer and serde are conflicting.

Is here any way we can continue to use serde while using rust-analyzer? What would be the best possible solution? Anyway I can help?

[staninprague]

I guess I triggered that rust-analyzer journey into serde before (I thought with some cmd-hover over) and that caused an issue. But now after re-installing 0.2.320 again I can't reproduce the issue. Same file, same cmd-hover over and jumping into serde is not triggering the issue. All works as expected. Let me close this issue then.

[staninprague]

Actually the issue reappeared after a while, but as solution of enabling procmacro support works: #6054, keeping this as closed.

[lnicola]

Serde_derive is an important library for many devs, I think.

rust-analyzer will report those keyword-related errors in serde only if you open its source code. If you're only a serde user (and not a developer), and don't want to see those errors, close any open windows containing files from ~/.cargo/registry/src.

Enabling proc macro support will make it support the two traits, but has no effect on any occurrences of try in serde.

[staninprague]

Serde_derive is an important library for many devs, I think.

rust-analyzer will report those keyword-related errors in serde only if you open its source code. If you're only a serde user (and not a developer), and don't want to see those errors, close any open windows containing files from ~/.cargo/registry/src.

I believe that I was not opening the serde code explicitly, but I certainly managed to reproduce the same action of mine unwillingly twice, so that rust-analyzer started to show that mod try; as an error. Only after tapping on a row with the error I was navigated to the error line and serde code. I'll keep an eye on that.

[ecton]

@lnicola It is reproducible with a blank project, adding the serde_derive line to Cargo.toml, and then adding use serde_derive::Serialize; in main.rs: https://gfycat.com/MajorBitterLangur

As in the other issue, procMacro enabling fixes the issue in my usage, but I wanted to confirm that it does indeed cause an error without opening the serde source if procMacro is disabled.

[lnicola]

@ecton the "unresolved import" error is expected (and can be disabled by setting rust-analyzer.diagnostics.disabled to ["unresolved-import"]). But I don't think you should be getting parse errors for the try module in serde's source code.

[staninprague]

Is setting rust-analyzer.diagnostics.disabled to ["unresolved-import"] something that will affect a whole class of errors, beyond serde special case?
Let me re-open this issue for better visibility.

[lnicola]

Is setting rust-analyzer.diagnostics.disabled to ["unresolved-import"] something that will affect a whole class of errors, beyond serde special case?

Yes, see #6054. It will turn off the "unresolved import" warnings, which can show up unexpectedly for types generated by a proc macro or build script, or when working on the compiler etc. It will also turn off the true positives (use std::fd), but you'll still get errors from cargo check when you save, if you didn't disable it.

[ecton]

I'm sorry @inicola for conflating the two issues. @staninprague I got here from a notification on #6054 and misunderstood the last few updates on this, leading me to demonstrate reproducing the issue from #6054, not the actual error mentioned in this thread. I'm not sure that my misunderstanding should be interpreted as more people running into this error.

Apologies again for the confusion everyone.

[staninprague]

It will also turn off the true positives (use std::fd), but you'll still get errors from cargo check when you save, if you didn't disable it.

Thank you for the clarification! Looks like a fair deal to me.