| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
`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.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Doc comments *are* attributes, so there's no reason to have two crates
here.
|
|\ |
|
| | |
|
| | |
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
5823: Don't underline function definition if self is &mut r=Nashenas88 a=matklad
The self is right there, and is already underlined, so it makes little
sense to emit even more underlines.
before:
![before](https://user-images.githubusercontent.com/1711539/90672843-0d379500-e257-11ea-840f-b0caed4410f1.png)
after:
![after](https://user-images.githubusercontent.com/1711539/90672840-0c9efe80-e257-11ea-9739-23af433841c6.png)
Co-authored-by: Aleksey Kladov <[email protected]>
|
| |
| |
| |
| |
| | |
The self is right there, and is already underlined, so it makes little
sense to emit even more underlines.
|
| | |
|
|/ |
|
| |
|
|
|
|
|
|
| |
We might want to provide more efficient impls for check if usages
exist, limiting the search, filtering and cancellation, so let's
violate YAGNI a bit here.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Main one: instead of adding a parameter to function to handle special
case, make the caller handle it.
Second main one: make sure that function does a reasonable thing.
`highlight_def` picks a color for def, *regardless* of the context
the def is use. Feeding an info from the call-site muddies the
responsibilities here.
Minor smells, flagging the function as having space for improvement in
the first place:
* many parameters, some of which are set as constants on most
call-sites (introduce severalfunction instad)
* boolean param (add two functions instead)
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
5811: Minor
r=matklad a=matklad
bors r+
🤖
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
5643: Add new consuming modifier, apply consuming and mutable to methods r=matklad a=Nashenas88
This adds a new `consuming` semantic modifier for syntax highlighters.
This also emits `mutable` and `consuming` in two cases:
- When a method takes `&mut self`, then it now has `function.mutable` emitted.
- When a method takes `self`, and the type of `Self` is not `Copy`, then `function.consuming` is emitted.
CC @flodiebold
Co-authored-by: Paul Daniel Faria <[email protected]>
|
| |
| |
| |
| |
| |
| |
| | |
self
The options are Shared, Mutable, Consuming, and Copied. Use this to add proper
highlighting to methods based on usage.
|
| |
| |
| |
| | |
`consuming`.
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
5695: Added completion for unstable features r=matklad a=Fihtangolz
Added xtask for downloading list of unstable features from the unstable book and codegen for it. Also included small changes from linter.
Co-authored-by: Dmitry <[email protected]>
Co-authored-by: Dmitry Opokin <[email protected]>
|
| |\ \ |
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
5804: Add type safety to diagnostic codes
r=matklad a=matklad
bors r+
🤖
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | | | |
|
|/ / / / |
|
| | | | |
|
| |/ /
|/| | |
|
|\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
5682: Add an option to disable diagnostics r=matklad a=popzxc
As far as I know, currently it's not possible to disable a selected type of diagnostics provided by `rust-analyzer`.
This causes an inconvenient situation with a false-positive warnings: you either have to disable all the diagnostics, or you have to ignore these warnings.
There are some open issues related to this problem, e.g.: https://github.com/rust-analyzer/rust-analyzer/issues/5412, https://github.com/rust-analyzer/rust-analyzer/issues/5502
This PR attempts to make it possible to selectively disable some diagnostics on per-project basis.
Co-authored-by: Igor Aleksanov <[email protected]>
|