Update r-a config suggestions

[Veykril]

The proc-macro server path is required for proc-macros to properly work in r-a when working on rustc.
Pointing the sysroot to the stage0 one is more correct than using the system installed one.

Related PRs in rust-analyzer:
rust-lang/rust-analyzer#13327
rust-lang/rust-analyzer#13326

Note, these configs only work with the next r-a release, that is tomorrows nightly, or next monday's stable release!

[Veykril]

I also just realized, for people working on the library crates, that is std and the like, it is beneficial to set "rust-analyzer.cargo.sysroot": null, as that will make r-a not consider the sysroot at all, getting rid of a bunch of incorrect type mismatches (as well as making most ide functions like goto definition work with the correct library definition, instead of the sysroot one).
I am unsure how to mention this library dev specific set up though, I assume there is no separate config suggestion for library devs?

[jyn514]

Thanks!

[jyn514]

I also just realized, for people working on the library crates, that is std and the like, it is beneficial to set "rust-analyzer.cargo.sysroot": null, as that will make r-a not consider the sysroot at all, getting rid of a bunch of incorrect type mismatches (as well as making most ide functions like goto definition work with the correct library definition, instead of the sysroot one). I am unsure how to mention this library dev specific set up though, I assume there is no separate config suggestion for library devs?

Why would this be specific to working on the standard library?

[Veykril]

the library crates don't depend on the sysroot library crates if I understand this correctly, but instead on each other only. With the sysroot set r-a will still resolve some things in those crates to the sysroot (mainly associated items on primitives) instead of the corresponding library crate.

Not too relevant here though I believe, just on observation I made.

[jyn514]

ah, I see. I think the proper solution for that is for rust-analyzer to understand #[lang = "slice_impl"] and such, otherwise it still won't work when people only run x.py check std and not x.py build std.

But yeah let's put that off for another day.