| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
3543: Parameter inlay hint separate from variable type inlay? #2876 r=matklad a=slyngbaek
Add setting to allow enabling either type inlay hints or parameter
inlay hints or both. Group the the max inlay hint length option
into the object.
- Add a new type for the inlayHint options.
- Add tests to ensure the inlays don't happen on the server side
Co-authored-by: Steffen Lyngbaek <[email protected]>
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
- Instead of a single object type, use several individual nested types
to allow toggling from the settings GUI
- Remove unused struct definitions
- Install and test that the toggles work
|
| |
| |
| |
| |
| |
| |
| | |
- Updated naming of config
- Define struct in ra_ide and use remote derive in rust-analyzer/config
- Make inlayConfig type more flexible to support more future types
- Remove constructor only used in tests
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add setting to allow enabling either type inlay hints or parameter
inlay hints or both. Group the the max inlay hint length option
into the object.
- Add a new type for the inlayHint options.
- Add tests to ensure the inlays don't happen on the server side
|
|/ |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The new name seems much simpler and it doesn't limit
this config value only to downloading the server binary.
Thus we wouldn't need to create another config
properties to handle other downloads whatsoever.
Anyway, I believe (heuristically) that most of the users
would want to set "askBeforeDownload": false once
and never bother clicking on the notification again
(because otherwise there is no big point in installing rust-analyzer if it cannot install the server)
|
|
|
|
|
|
|
| |
Also renamed BinarySource to ArtifactSource in anticipation of
nightlies installation that requires downloading
not a binary itself but .vsix package, thus generalized
to `artifact` term
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
further)
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
3388: Remove inlay hint in diff views r=matklad a=vbfox
If the left side of a diff view that contain the old version of the file apply inlays they are misplaced and produce a weird display:
![image](https://user-images.githubusercontent.com/131878/75628802-b1ac1900-5bdc-11ea-8c26-6722d8e38371.png)
After the change:
![image](https://user-images.githubusercontent.com/131878/75628831-e91ac580-5bdc-11ea-9039-c6b4ffbdb2be.png)
The detection is done by blacklisting the url schemes used by git and subversion scm extensions, whitelisting `file` is also possible but neither is perfect as VSCode now support both pluggable scm extensions and pluggable remote filesystems. But I suspect that the list of scm extensions is more easily manageable.
**Note**: I can rebase on #3378 if needed as it touches the same lines of code
Co-authored-by: Julien Roncaglia <[email protected]>
|
| |
| |
| |
| | |
Also move visibleRustEditors to Ctx
|
| |
| |
| |
| |
| |
| |
| |
| | |
If the left side of a diff view that contain the old
version of the file apply inlays they are misplaced.
The detection is done by blacklisting the url schemes used
by git and subversion scm extensions.
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Otherwise, we get bold hints on `true` and `false`
|
| |
|
| |
|
| |
|
|\
| |
| | |
Enable SemanticTokens on the client
|
| |
| |
| |
| | |
This will crash the extension on stable and insiders without the "--enable-proposed-api matklad.rust-analyzer" command line switch.
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
3295: Refactoring fetchArtifactReleaseInfo() r=matklad a=Veetaha
https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/no-unnecessary-type-assertion.md
I fact this rule doesn't work when you put an unnecessary non-null assertion in an expression (as we had `(awat f())!`, but it is useful in other cases...
Closes #3295, i guess...
Co-authored-by: Veetaha <[email protected]>
|