| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| | |
1482: Some clippy fixes for 1.36 r=kjeremy a=kjeremy
Some clippy fixes now that 1.36 is released. ~~Plus the requisite format run (I can rebase after #1481 is merged to make this cleaner) .~~
The change from `map(|it| *it)` to `copied()` changes the minimum rust stable to 1.36.
Co-authored-by: Jeremy Kolb <[email protected]>
|
| | |
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| | |
1484: Update to lsp-types 0.58.0 r=matklad a=kjeremy
Fixes CodeActionResponse
Co-authored-by: Jeremy Kolb <[email protected]>
|
| | |
|
| | |
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| | |
1485: rand 0.7.0 r=matklad a=kjeremy
Co-authored-by: Jeremy Kolb <[email protected]>
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| | |
1486: allow rustfmt to reorder imports r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| |
| |
| |
| |
| |
| | |
This wasn't a right decision in the first place, the feature flag was
broken in the last rustfmt release, and syntax highlighting of imports
is more important anyway
|
|\ \
| |/
|/|
| |
| |
| |
| |
| | |
1478: [WIP] Added resolve submodules with raw name r=matklad a=andreevlex
#1211
Co-authored-by: Alexander Andreev <[email protected]>
|
| | |
|
| |
| |
| |
| | |
Added test for check module resolution with raw name
|
| |
| |
| |
| | |
#1211
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1476: Extend add_impl_members to constants and types r=matklad a=viorina
Co-authored-by: Ekaterina Babshukova <[email protected]>
|
| |/ |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| | |
1477: Update vsce to 1.64.0 r=matklad a=kjeremy
Gets rid of the annoying warning asking you to run `npm install -g vsce` on `cargo install`.
Co-authored-by: kjeremy <[email protected]>
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| | |
1472: Add completion for type aliases r=matklad a=sinkuu
Co-authored-by: Shotaro Yamada <[email protected]>
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| | |
1468: Use inline snapshots in complete_path r=matklad a=funkill
Relates to #1127
Co-authored-by: funkill2 <[email protected]>
|
| | |
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| | |
1465: put source maps first for better stats r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| | |
1464: collect more macros, they are heavy r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| | |
1463: print memory usage for queries r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| | |
1462: Move memory usage statistics to ra_prof r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
1458: Run VS Code tests on CI r=matklad a=etaoins
This is actually much faster than I expected; it takes about 13 seconds to download VS Code and run the unit tests. This means the VS Code tests are still significantly faster than the Rust ones.
If this ends up being unreliable we can always remove it later or move it to a separate optional job.
We also need to ignore the `.vscode-test` directory when running `prettier` or it will get upset about some temporary JSON files VS Code creates.
cc @killercup
Co-authored-by: Ryan Cumming <[email protected]>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is actually much faster than I expected; it takes about 13 seconds
to download VS Code and run the unit tests. This means the VS Code tests
are still significantly faster than the Rust ones.
If this ends up being unreliable we can always remove it later or move
it to a separate optional job.
We also need to ignore the `.vscode-test` directory when running
`prettier` or it will get upset about some temporary JSON files VS Code
creates.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1461: Support attributes on array members r=matklad a=etaoins
Array members are allowed to have attributes such as `#[cfg]`.
Co-authored-by: Ryan Cumming <[email protected]>
|
| | |
| | |
| | |
| | |
| | | |
This is actually allowed by the `rustc` parser but most attributes will
fail later due to attributes on expressions being experimental.
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Array members are allow to have attributes such as `#[cfg]`.
This is a bit tricky as we don't know if the first expression is an
initializer or a member until we encounter a `;`. This reuses a trick
from `stmt` where we remember if we saw an attribute and then raise an
error if the first expression ends up being an initializer.
This isn't perfect as the error isn't correctly located on the attribute
or initializer; it ends up immediately after the `;`.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1459: Include primary span label in VS Code diagnostics r=matklad a=etaoins
In most cases the primary label span repeats information found elsewhere in the diagnostic. For example, with E0061:
```json
{
"message": "this function takes 2 parameters but 3 parameters were supplied",
"spans": [{"label": "expected 2 parameters"}]
}
```
However, with some mismatched type errors (E0308) the expected type only appears in the primary span's label, e.g.:
```json
{
"message": "mismatched types",
"spans": [{"label": "expected usize, found u32"}]
}
```
I initially added the primary span label to the message unconditionally. However, for most error types the child diagnostics repeat the primary span label with more detail. `rustc` also renders the duplicate text but because the span label and child diagnostics appear in visually distinct places it's not as confusing.
This takes a heuristic approach where it will only add the primary span label if there are no child message lines. For most error types the child messages repeat the primary span label with more detail.
Co-authored-by: Ryan Cumming <[email protected]>
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In most cases the primary label span repeats information found elsewhere
in the diagnostic. For example, with E0061:
```
{
"message": "this function takes 2 parameters but 3 parameters were supplied",
"spans": [{"label": "expected 2 parameters"}]
}
```
However, with some mismatched type errors (E0308) the expected type only
appears in the primary span's label, e.g.:
```
{
"message": "mismatched types",
"spans": [{"label": "expected usize, found u32"}]
}
```
I initially added the primary span label to the message unconditionally.
However, for most error types the child diagnostics repeat the primary
span label with more detail. `rustc` also renders the duplicate text but
because the span label and child diagnostics appear in visually distinct
places it's not as confusing.
This takes a heuristic approach where it will only add the primary span
label if there are no child message lines.
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
1460: Consider unreachable code to be unnecessary in VSC r=matklad a=etaoins
This adds `unreachable_code` to the list of diagnostic codes we map to `Unnecessary` in Visual Studio Code. This is consistent with what the TypeScript language server does.
Before:
<img width="308" alt="Screen Shot 2019-06-30 at 12 08 56" src="https://user-images.githubusercontent.com/687534/60391416-133d5480-9b31-11e9-86fb-e252739ab3a8.png">
After:
<img width="303" alt="Screen Shot 2019-06-30 at 12 16 49" src="https://user-images.githubusercontent.com/687534/60391418-19333580-9b31-11e9-9eea-850c62eb9a07.png">
Co-authored-by: Ryan Cumming <[email protected]>
|
|/
|
|
|
|
| |
This adds `unreachable_code` to the list of diagnostic codes we map to
`Unnecessary` in Visual Studio Code. This is consistent with what the
TypeScript language server does.
|
|\
| |
| |
| |
| |
| |
| |
| | |
1456: Deduplicate method candidates r=matklad a=flodiebold
With trait method completion + autoderef, we were getting a lot of duplicates, which was really annoying...
Co-authored-by: Florian Diebold <[email protected]>
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1457: Complete associated methods on enums (and unions) as well r=matklad a=flodiebold
This has been seriously annoying me for a while ;)
Co-authored-by: Florian Diebold <[email protected]>
|
| |/ |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
1454: Fix `cargo watch` code action filtering r=etaoins a=etaoins
There are two issues with the implementation of `provideCodeActions` introduced in #1439:
1. We're returning the code action based on the file its diagnostic is in; not the file the suggested fix is in. I'm not sure how often fixes are suggested cross-file but it's something we should handle.
2. We're not filtering code actions based on the passed range. The means if there is any suggestion in a file we'll show an action for every line of the file. I naively thought that VS Code would filter for us but that was wrong.
Unfortunately the VS Code `CodeAction` object is very complex - it can handle edits across multiple files, run commands, etc. This makes it complex to check them for equality or see if any of their edits intersects with a specified range.
To make it easier to work with suggestions this introduces a `SuggestedFix` model object and a `SuggestFixCollection` code action provider. This is a layer between the raw Rust JSON and VS Code's `CodeAction`s. I was reluctant to introduce another layer of abstraction here but my attempt to work directly with VS Code's model objects was worse.
Co-authored-by: Ryan Cumming <[email protected]>
|
| |
| |
| |
| | |
This isn't immediately obvious without looking at the users of the map
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There are two issues with the implementation of `provideCodeActions`
introduced in #1439:
1. We're returning the code action based on the file its diagnostic is
in; not the file the suggested fix is in. I'm not sure how often
fixes are suggested cross-file but it's something we should handle.
2. We're not filtering code actions based on the passed range. The means
if there is any suggestion in a file we'll show an action for every
line of the file. I naively thought that VS Code would filter for us
but that was wrong.
Unfortunately the VS Code `CodeAction` object is very complex - it can
handle edits across multiple files, run commands, etc. This makes it
complex to check them for equality or see if any of their edits
intersects with a specified range.
To make it easier to work with suggestions this introduces a
`SuggestedFix` model object and a `SuggestFixCollection` code action
provider. This is a layer between the raw Rust JSON and VS Code's
`CodeAction`s. I was reluctant to introduce another layer of abstraction
here but my attempt to work directly with VS Code's model objects was
worse.
|
|\ \
| |/
|/|
| |
| |
| |
| |
| | |
1455: Add noUnusedLocals to VsCode tsconfig r=matklad a=etaoins
`tslint` doesn't catch this because TypeScript has had this check builtin since 2.9. However, it's disabled by default so right now nothing is checking for unused variables.
Co-authored-by: Ryan Cumming <[email protected]>
|
|/
|
|
|
|
| |
`tslint` doesn't catch this because TypeScript has had this check
builtin since 2.9. However, it's disabled by default so right now
nothing is checking for unused variables.
|