Add some more highlighting configurations
The following can be enabled/disabled now in terms of highlighting:
- doc comment injection (enabled by default)
- punctuation highlighting (disabled by default)
- operator highlighting (enabled by default)
- punctuation specialized highlighting (disabled by default)
- operator specialized highlighting (disabled by default)
- macro call bang highlighting (disabled by default)
This PR also changes our `attribute` semantic token type to the `decorator` type which landed upstream (but not yet in lsp-types).
Specialized highlighting is disabled by default, as all clients will have to ship something to map these back to the standard punctuation/operator token (we do this in VSCode via the inheritance mapping for example). This is a lot of maintenance work, and not something every client wants to do, pushing that need to use the user. As this is a rather niche use in the first place this will just be disabled by default.
Punctuation highlighting is disabled by default, punctuation is usually something that can be done by the native syntactic highlighting of the client, so there is no loss in quality. The main reason for this though is that punctuation adds a lot of extra token data that we sent over, a lot of clients struggle with applying this, so disabling this improves the UX for a lot of people. Note that we still highlight punctuations with special meaning as that special entity, (the never type `!` will still be tagged as a builtin type if it occurs as such)
Separate highlighting of the macro call bang `!` is disabled by default, as I think people actually didn't like that change that much, though at the same time I feel like not many people even noticed that change (I prefer it be separate, but that's not enough reason for it to be enabled by default I believe :^) )
cc https://github.com/rust-lang/rust-analyzer/issues/12783https://github.com/rust-lang/rust-analyzer/issues/13066
feat: emit SCIP from rust-analyzer
hi rust-analyzer team
I'm one of the engineers at Sourcegraph (and have done a few small changes related to the LSIF work done in rust-analyzer). Recently, we've moved to a new protocol as the primary way to interact with Sourcegraph (LSIF is still possible to upload, so existing jobs will not stop working any time soon). This new protocol is SCIP (I linked a blog post below with more information).
I've implemented SCIP support (based largely on the existing LSIF support). In addition to supporting the existing features that `rust-analyzer`'s LSIF support does, this PR adds the ability to move between crates on sourcegraph.com. So if both your project and a dependency are indexed, you would be able to hop to the particular version and view the source code. I'd be happy to record a demo of that on my local instance if you're interested.
There are a few TODO's left in the code (some that you might have insights on) which I'm happy to fix in this PR, but I just wanted to open this up for discussion first.
Thanks for your time :)
TJ
- [announcing scip](https://about.sourcegraph.com/blog/announcing-scip)
fix: Fix panics on GATs involving const generics
This workaround avoids constant crashing of rust analyzer when using GATs with const generics,
even when the const generics are only on the `impl` block.
The workaround treats GATs as non-existing if either itself or the parent has const generics and
removes relevant panicking code-paths.
Fixes#11989, fixes#12193
Consider bounds on inherent impl in method resolution
There are three type-related things we should consider in method resolution: `Self` type, receiver type, and impl bounds. While we check the first two and impl bounds on trait impls, we've been ignoring the impl bounds on inherent impls. With this patch rust-analyzer now takes them into account and is able to select the appropriate inherent method.
Resolves#5441Resolves#12308
internal: Build release binaries on `ubuntu-20.04`
Ubuntu 18.04 is still available until December 1st, but will start failing from time to time, which is not something we want when building nightlies.
feat: Generate static method using Self::assoc() syntax
This change improves the `generate_function` assist to support generating static methods/associated functions using the `Self::assoc()` syntax. Previously, one could generate a static method, but only when specifying the type name directly (like `Foo::assoc()`). After this change, `Self` is supported as well as the type name.
Fixes#13012
