5930: Migrate to the latest Semantic Tokens Proposal for LSP 3.16 r=matklad a=kjeremy
This stabilizes call hierarchy and semantic tokens features on the client side and changes the server-side semantic tokens protocol to match the latest proposal for 3.16.
The server-side change will break clients depending on the earlier semantic tokens draft.
Fixes#4942
Co-authored-by: kjeremy <kjeremy@gmail.com>
5921: Don't publish every day and do it only for release r=matklad a=pksunkara
I think this is a good balance.
Co-authored-by: Pavan Kumar Sunkara <pavan.sss1991@gmail.com>
5910: Fix some typos r=matklad a=SomeoneToIgnore
5912: Remove fixme from inlay_hints.ts r=matklad a=Veetaha
I have reevaluated the fixme and it doesn't seem necessary to pass an array of files
to the inlay hints request.
This will (a) make the request more compilcated (b), make us wait for
inlay hints for `all` active editors resolve at once before rendering and (c)
doesn't seem required because 99% of the time there is a single active editor
in the IDE
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
Co-authored-by: Veetaha <veetaha2@gmail.com>
5909: Add rust-analyzer.checkOnSave.target to package.json r=matklad a=lnicola
This was already implemented, but it's missing from the manifest.
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
I have reevaluated the fixme and it doesn't seem necessary to pass an array of files
to the inlay hints request.
This will (a) make the request more compilcated (b), make us wait for
inlay hints for `all` active editors resolve at once before rendering and (c)
doesn't seem required because 99% of the time there is a single active editor
in the IDE
5906: Use SVG logo in readme r=matklad a=arzg
This also adds the two versions of the logo created by @Aloso to `/assets` for any future uses. I found the logo SVGs in [this issue](https://github.com/rust-analyzer/rust-analyzer.github.io/issues/23).
Co-authored-by: Aramis Razzaghipour <aramisnoah@gmail.com>
`hir` should know nothing about URLs, markdown and html. It should
only be able to:
* resolve stringy path from documentation
* generate canonical stringy path for a def
In contrast, link rewriting should not care about semantics of paths
and names resolution, and should be concern only with text mangling
bits.
