aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* put source maps first for better statsAleksey Kladov2019-06-302-8/+8
|
* Merge #1464bors[bot]2019-06-301-0/+1
|\ | | | | | | | | | | | | | | 1464: collect more macros, they are heavy r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * collect more macros, they are heavyAleksey Kladov2019-06-301-0/+1
|/
* Merge #1463bors[bot]2019-06-307-13/+101
|\ | | | | | | | | | | | | | | 1463: print memory usage for queries r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * print memory usage for queriesAleksey Kladov2019-06-307-13/+101
|/
* Merge #1462bors[bot]2019-06-309-68/+78
|\ | | | | | | | | | | | | | | 1462: Move memory usage statistics to ra_prof r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * Move memory usage statistics to ra_profAleksey Kladov2019-06-309-68/+78
| |
* | Merge #1458bors[bot]2019-06-303-6/+21
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | 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]>
| * Run VS Code tests on CIRyan Cumming2019-06-293-6/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | Merge #1461bors[bot]2019-06-305-0/+129
|\ \ | | | | | | | | | | | | | | | | | | | | | 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]>
| * | Remove parse error on array initializer attributesRyan Cumming2019-06-303-76/+0
| | | | | | | | | | | | | | | This is actually allowed by the `rustc` parser but most attributes will fail later due to attributes on expressions being experimental.
| * | Support attributes on array membersRyan Cumming2019-06-307-0/+205
| |/ | | | | | | | | | | | | | | | | | | | | | | 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 `;`.
* | Merge #1459bors[bot]2019-06-303-1/+70
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
| * | Include primary span label in VS Code diagnosticsRyan Cumming2019-06-303-1/+70
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | Merge #1460bors[bot]2019-06-301-0/+1
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | 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]>
| * Consider unreachable code to be unnecessary in VSCRyan Cumming2019-06-301-0/+1
|/ | | | | | 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.
* Merge #1456bors[bot]2019-06-291-1/+31
|\ | | | | | | | | | | | | | | 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]>
| * Deduplicate method candidatesFlorian Diebold2019-06-291-1/+31
| |
* | Merge #1457bors[bot]2019-06-294-6/+91
|\ \ | | | | | | | | | | | | | | | | | | | | | 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]>
| * | Complete associated methods on enums (and unions) as wellFlorian Diebold2019-06-294-6/+91
| |/
* | Merge #1454bors[bot]2019-06-2910-254/+498
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
| * Comment on the key of `suggestedFixes`Ryan Cumming2019-06-291-0/+3
| | | | | | | | This isn't immediately obvious without looking at the users of the map
| * Fix `cargo watch` code action filteringRyan Cumming2019-06-2910-254/+495
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | Merge #1455bors[bot]2019-06-292-2/+2
|\ \ | |/ |/| | | | | | | | | | | 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]>
| * Add noUnusedLocals to VsCode tsconfigRyan Cumming2019-06-292-2/+2
|/ | | | | | `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.
* Merge #1453bors[bot]2019-06-291-0/+26
|\ | | | | | | | | | | | | | | 1453: Add show syntax tree function to emacs r=matklad a=zbelial This PR adds preliminary support for showing syntax tree. Co-authored-by: zbelial <[email protected]>
| * Add show syntax tree function to emacszbelial2019-06-291-0/+26
|/
* Merge #1452bors[bot]2019-06-282-5/+25
|\ | | | | | | | | | | | | | | 1452: Show macros in file structure r=matklad a=viorina Co-authored-by: Ekaterina Babshukova <[email protected]>
| * show macros in file structureEkaterina Babshukova2019-06-282-5/+25
|/
* Merge #1440bors[bot]2019-06-284-7/+90
|\ | | | | | | | | | | | | | | 1440: fixed #1384 r=matklad a=zbelial This PR fixed #1384 . Co-authored-by: zjy <[email protected]>
| * fixed #1384zjy2019-06-284-7/+90
| |
* | Merge #1450bors[bot]2019-06-273-6/+35
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | 1450: Extract lint scopes from `cargo watch` r=matklad a=etaoins Currently all of our VS Code diagnostics are given the source of `rustc`. However, if you have something like `cargo-watch.command` set to `clippy` it will also watch for Clippy lints. The `rustc` source is a bit misleading in that case. Fortunately, Rust's tool lints ([RFC 2103](https://github.com/rust-lang/rfcs/blob/master/text/2103-tool-attributes.md)) line up perfectly with VS Code's concept of `source`. This checks for lints scoped to a given tool and then splits them in to a `source` and tool-specific `code`. Co-authored-by: Ryan Cumming <[email protected]>
| * | Extract lint scopes from `cargo watch`Ryan Cumming2019-06-263-6/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently all of our VS Code diagnostics are given the source of `rustc`. However, if you have something like `cargo-watch.command` set to `clippy` it will also watch for Clippy lints. The `rustc` source is a bit misleading in that case. Fortunately, Rust's tool lints (RFC 2103) line up perfectly with VS Code's concept of `source`. This checks for lints scoped to a given tool and then splits them in to a `source` and tool-specific `code`.
* | | Merge #1449bors[bot]2019-06-271-10/+25
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1449: Swallow expected `rustfmt` errors r=matklad a=etaoins My workflow in Visual Studio Code + Rust Analyzer has become: 1. Make a change to Rust source code using all the analysis magic 2. Save the file to trigger `cargo watch`. I have format on save enabled for all file types so this also runs `rustfmt` 3. Fix any diagnostics that `cargo watch` finds Unfortunately if the Rust source has any syntax errors the act of saving will pop up a scary "command has failed" message and will switch to the "Output" tab to show the `rustfmt` error and exit code. I did a quick survey of what other Language Servers do in this case. Both the JSON and TypeScript servers will swallow the error and return success. This is consistent with how I remember my workflow in those languages. The syntax error will show up as a diagnostic so it should be clear why the file isn't formatting. I checked the `rustfmt` source code and while it does distinguish "parse errors" from "operational errors" internally they both result in exit status of 1. However, more catastrophic errors (missing `rustfmt`, SIGSEGV, etc) will return 127+ error codes which we can distinguish from a normal failure. This changes our handler to log an info message and feign success if `rustfmt` exits with status 1. Another option I considered was only swallowing the error if the formatting request came from format-on-save. However, the Language Server Protocol doesn't seem to distinguish those cases. Co-authored-by: Ryan Cumming <[email protected]>
| * | Swallow expected `rustfmt` errorsRyan Cumming2019-06-261-10/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | My workflow in Visual Studio Code + Rust Analyzer has become: 1. Make a change to Rust source code using all the analysis magic 2. Save the file to trigger `cargo watch`. I have format on save enabled for all file types so this also runs `rustfmt` 3. Fix any diagnostics that `cargo watch` finds Unfortunately if the Rust source has any syntax errors the act of saving will pop up a scary "command has failed" message and will switch to the "Output" tab to show the `rustfmt` error and exit code. I did a quick survey of what other Language Servers do in this case. Both the JSON and TypeScript servers will swallow the error and return success. This is consistent with how I remember my workflow in those languages. The syntax error will show up as a diagnostic so it should be clear why the file isn't formatting. I checked the `rustfmt` source code and while it does distinguish "parse errors" from "operational errors" internally they both result in exit status of 1. However, more catastrophic errors (missing `rustfmt`, SIGSEGV, etc) will return 127+ error codes which we can distinguish from a normal failure. This changes our handler to log an info message and feign success if `rustfmt` exits with status 1. Another option I considered was only swallowing the error if the formatting request came from format-on-save. However, the Language Server Protocol doesn't seem to distinguish those cases.
* | | Merge #1448bors[bot]2019-06-261-13/+13
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | 1448: :arrow_up: rowan r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * | :arrow_up: rowanAleksey Kladov2019-06-261-13/+13
| | | | | | | | | | | | | | | New rowan includes one more memory optimization: green nodes are deduplicated within a single tree
* | | Merge #1447bors[bot]2019-06-267-48/+55
|\| | | | | | | | | | | | | | | | | | | | | | | 1447: make sure that CrateDefMap is independent from syntax r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * | make sure that CrateDefMap is independent from syntaxAleksey Kladov2019-06-267-48/+55
|/ /
* | Merge #1443bors[bot]2019-06-263-194/+240
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1443: cache chalk queries r=flodiebold a=matklad This gives a significant speedup, because chalk will call these functions several times even withing a single revision. The only significant one here is `impl_data`, but I figured it might be good to cache others just for consistency. The results I get are: Before: from scratch: 16.081457952s no change: 15.846493ms trivial change: 352.95592ms comment change: 361.998408ms const change: 457.629212ms After: from scratch: 14.910610278s no change: 14.934647ms trivial change: 85.633023ms comment change: 96.433023ms const change: 171.543296ms Seems like a nice win! Co-authored-by: Aleksey Kladov <[email protected]>
| * | cache chalk queriesAleksey Kladov2019-06-263-194/+240
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This gives a significant speedup, because chalk will call these functions several times even withing a single revision. The only significant one here is `impl_data`, but I figured it might be good to cache others just for consistency. The results I get are: Before: from scratch: 16.081457952s no change: 15.846493ms trivial change: 352.95592ms comment change: 361.998408ms const change: 457.629212ms After: from scratch: 14.910610278s no change: 14.934647ms trivial change: 85.633023ms comment change: 96.433023ms const change: 171.543296ms Seems like a nice win!
* | | Merge #1446bors[bot]2019-06-2612-61/+784
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1446: Initial Visual Studio Code unit tests r=matklad a=etaoins As promised in #1439 this is an initial attempt at unit testing the VSCode extension. There are two separate parts to this: getting the test framework working and unit testing the code in #1439. The test framework nearly intact from the VSCode extension generator. The main thing missing was `test/index.ts` which acts as an entry point for Mocha. This was simply copied back in. I also needed to open the test VSCode instance inside a workspace as our file URI generation depends on a workspace being open. There are two ways to run the test framework: 1. Opening the extension's source in VSCode, pressing F5 and selecting the "Extensions Test" debug target. 2. Closing all copies of VSCode and running `npm test`. This is started from the command line but actually opens a temporary VSCode window to host the tests. This doesn't attempt to wire this up to CI. That requires running a headless X11 server which is a bit daunting. I'll assess the difficulty of that in a follow-up branch. This PR is at least helpful for local development without having to induce errors on a Rust project. For the actual tests this uses snapshots of `rustc` output from [a real Rust project](https://github.com/etaoins/arret) captured from the command line. Except for extracting the `message` object and reformatting they're copied verbatim into fixture JSON files. Only four different types of diagnostics are tested but they represent the main combinations of code actions and related information possible. They can be considered the happy path tests; as we encounter corner-cases we can introduce new tests fixtures. Co-authored-by: Ryan Cumming <[email protected]>
| * | | Document the VS Code extension test frameworkRyan Cumming2019-06-261-0/+19
| | | |
| * | | Initial Visual Studio Code unit testsRyan Cumming2019-06-2611-61/+765
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As promised in #1439 this is an initial attempt at unit testing the VSCode extension. There are two separate parts to this: getting the test framework working and unit testing the code in #1439. The test framework nearly intact from the VSCode extension generator. The main thing missing was `test/index.ts` which acts as an entry point for Mocha. This was simply copied back in. I also needed to open the test VSCode instance inside a workspace as our file URI generation depends on a workspace being open. There are two ways to run the test framework: 1. Opening the extension's source in VSCode, pressing F5 and selecting the "Extensions Test" debug target. 2. Closing all copies of VSCode and running `npm test`. This is started from the command line but actually opens a temporary VSCode window to host the tests. This doesn't attempt to wire this up to CI. That requires running a headless X11 server which is a bit daunting. I'll assess the difficulty of that in a follow-up branch. This PR is at least helpful for local development without having to induce errors on a Rust project. For the actual tests this uses snapshots of `rustc` output from a real Rust project captured from the command line. Except for extracting the `message` object and reformatting they're copied verbatim into fixture JSON files. Only four different types of diagnostics are tested but they represent the main combinations of code actions and related information possible. They can be considered the happy path tests; as we encounter corner-cases we can introduce new tests fixtures.
* | | Merge #1444bors[bot]2019-06-263-52/+51
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | 1444: move ra_prof dep where it belongs r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * | move ra_prof dep where it belongsAleksey Kladov2019-06-263-52/+51
|/ /
* | Merge #1442bors[bot]2019-06-264-0/+90
|\ \ | |/ |/| | | | | | | | | | | 1442: add cpuprofile to ra_prof r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * add cpuprofile to ra_profAleksey Kladov2019-06-264-0/+90
|/ | | | | | | | | Now, one can use `let _p = ra_prof::cpu_profiler()` to capture profile of a block of code. This is not an out of the box experience, as that relies on gperfools See the docs on https://github.com/AtheMathmo/cpuprofiler for more!
* Merge #1432bors[bot]2019-06-251-2/+57
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1432: Make fill_match_arm work with trivial arm r=matklad a=ironyman Addresses this issue https://github.com/rust-analyzer/rust-analyzer/issues/1399 One minor issue I noticed is that complete_postfix creates an arm like this ``` match E::X { <|>_ => {}, } ``` but fill_match_arms creates arms like this ``` E::X => (), ``` Co-authored-by: ironyman <[email protected]> Co-authored-by: Changyu Li <[email protected]>
| * Review 1Changyu Li2019-06-251-16/+19
| |