Rust-Analyzer compatibility

[nightkr]

Currently, pin-project's macros aren't expanded by Rust-Analyzer, which prevents things like auto-completing into projections. This is due to pin-project using a bunch of features that Rust-Analyzer still doesn't understand. However, it doesn't look like any of these are ultimately fundamental to the way pin-project works.

• Attribute proc macros aren't expanded (Does not work for attribute proc macros rust-lang/rust-analyzer#6029)
  • pin-project is already implemented as a derive macro internally, so it'd just require shifting the public API towards it (the existing #[pin_project] can be kept as a compatibility wrapper, so no breakage is required here)
• Rust-Analyzer doesn't see "macro-private" types (that is, constructs like const _: () = { struct __FooProjection {} };)
  • Workaround: Named projections (#[pin(project = FooProj)]) are already placed in the regular outer scope
• Rust-Analyzer doesn't see "macro-private" impls (const _: () = { impl Foo {} };
  • Put the fn project() impl in the regular outer scope if the projection type is renamed (and the same for fn project_ref())
• Rust-Analyzer doesn't infer projection type parameters (let foo: Foo<T>; foo.project() is inferred as FooProj<{unknown}>, Method calls with custom receiver types "forget" their type arguments rust-lang/rust-analyzer#8100)
  • Workaround: The type is inferred correctly when called using UFCS (let foo: Foo<T>; Foo::project(foo) is inferred correctly as FooProj<T>)
  • This also happens when the impl is written manually, so this seems to be some RA bug that we can't do much about
• Reexported macro can't be seen properly if also importing #[pin_project]
  • Workaround: Standardize on either #[pin_project] or #[derive(PinProject)] within a single module

[taiki-e]

As said in #320, the rust-analyzer team seems to be starting to work on support for attribute proc-macros (rust-lang/rust-analyzer#8486), so I would prefer to wait for it instead of adding the API on the pin-project side for now.

[taiki-e]

rust-analyzer added experimental support for attribute macros: rust-lang/rust-analyzer#9128

[jonas-schievink]

• Rust-Analyzer doesn't see "macro-private" impls (const _: () = { impl Foo {} };

This should also work now

[Aaron1011]

Issue rust-lang/rust-analyzer#6029 has been closed - is there anything left to do here?

[nightkr]

Doesn't seem to be working for me.. on https://gist.github.com/teozkr/0971d3f7d7ce0369861f167287bc5de0, Rust-Analyzer has no idea about either WrapperProj or Wrapper::project existing. This is on rust-lang/rust-analyzer@009e6ce (the current master).

I haven't had the time yet to investigate which piece is still missing.

[nightkr]

Curiously, it seems to work fine in VSCode, while Emacs completely ignores the proc macro and everything it generates. So maybe this is actually just a problem with how lsp-mode configures rust-analyzer now?

[nightkr]

Yeah, apparently I had screwed up enabling proc attr macro support in my RA. After fixing that pin-project worked just fine! So it looks like this issue can finally be closed, then.