aboutsummaryrefslogtreecommitdiff
path: root/crates
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
| |
* | 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.
* | 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!
* | | move ra_prof dep where it belongsAleksey Kladov2019-06-262-5/+4
|/ /
* / add cpuprofile to ra_profAleksey Kladov2019-06-263-0/+38
|/ | | | | | | | | 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
| |
| * fill_match_arm works with trivial armironyman2019-06-241-2/+54
| |
* | Add commentShotaro Yamada2019-06-251-6/+8
| |
* | Method resolution for slicesShotaro Yamada2019-06-241-25/+36
| |
* | Merge #1429bors[bot]2019-06-242-1/+10
|\ \ | | | | | | | | | | | | | | | | | | | | | 1429: Add box postfix completion r=matklad a=kanru Co-authored-by: Kan-Ru Chen <[email protected]>
| * | Add box postfix completionKan-Ru Chen2019-06-232-1/+10
| |/
* | Merge #1415bors[bot]2019-06-245-1/+149
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | 1415: fix: specialization r=matklad a=csmoe Closes #1402 r? @matklad Co-authored-by: csmoe <[email protected]>
| * | fix: specialization(with blindly parsing)csmoe2019-06-195-1/+149
| | | | | | | | | | | | Change-Id: Ic5d2767e8781568d76d4d0013cd6081e95ae8a95
* | | Add SourceRoot::is_library, in preparation for salsa's durabilityAleksey Kladov2019-06-242-1/+16
| |/ |/|
* | Bump cargo_metadata, ena, flexi_loggerkjeremy2019-06-205-6/+6
| |
* | don' collect macrosAleksey Kladov2019-06-201-3/+6
| |
* | Merge #1419bors[bot]2019-06-193-17/+38
|\ \ | | | | | | | | | | | | | | | | | | | | | 1419: Add firewall query to lang items r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * | Add firewall query to lang itemsAleksey Kladov2019-06-193-17/+38
| | | | | | | | | | | | | | | With an intermediate query, changing one module won't cause reparsing of all modules
* | | Merge #1414bors[bot]2019-06-198-6/+97
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | 1414: fix: box_syntax/pattern r=matklad a=csmoe Closes #1412 r? @matklad Co-authored-by: csmoe <[email protected]>
| * | fix: box_patterncsmoe2019-06-199-11/+94
| | | | | | | | | | | | Change-Id: I45a856d74fb616d3bce33050f9e69d327186bd59
| * | fix: box_syntax(#1412)csmoe2019-06-182-0/+8
| |/ | | | | | | Change-Id: I6e20e0163fa545de37226c1561b3b7103615626c
* / rename XSignature -> XDataAleksey Kladov2019-06-1810-70/+66
|/
* Merge #1409bors[bot]2019-06-164-19/+16
|\ | | | | | | | | | | | | | | | | | | | | | | 1409: The Fall down of failures r=matklad a=mominul :grin: Replaced all the uses of `failure` crate with `std::error::Error`. Closes #1400 Depends on rust-analyzer/teraron#1 Co-authored-by: Muhammad Mominul Huque <[email protected]>
| * Update teraron versionMuhammad Mominul Huque2019-06-161-1/+1
| |
| * Fall down of failuresMuhammad Mominul Huque2019-06-154-19/+16
| |
* | add analysis-bench to benchmark incremental analysisAleksey Kladov2019-06-168-81/+232
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Can be used like this: ``` $ cargo run --release -p ra_cli -- \ analysis-bench ../chalk/ \ --complete ../chalk/chalk-engine/src/logic.rs:94:0 loading: 225.970093ms from scratch: 8.492373325s no change: 445.265µs trivial change: 95.631242ms ``` Or like this: ``` $ cargo run --release -p ra_cli -- \ analysis-bench ../chalk/ \ --highlight ../chalk/chalk-engine/src/logic.rs loading: 209.873484ms from scratch: 9.504916942s no change: 7.731119ms trivial change: 124.984039ms ``` "from scratch" includes initial analysis of the relevant bits of the project "no change" just asks the same question for the second time. It measures overhead on assembling the answer outside of salsa. "trivial change" doesn't do an actual salsa change, it just advances the revision. This test how fast is salsa at validating things.
* | Merge #1408bors[bot]2019-06-1618-70/+453
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | 1408: Associated type basics & Deref support r=matklad a=flodiebold This adds the necessary Chalk integration to handle associated types and uses it to implement support for `Deref` in the `*` operator and autoderef; so e.g. dot completions through an `Arc` work now. It doesn't yet implement resolution of associated types in paths, though. Also, there's a big FIXME about handling variables in the solution we get from Chalk correctly. Co-authored-by: Florian Diebold <[email protected]>
| * | Add test for autoderef infinite recursionFlorian Diebold2019-06-161-0/+25
| | |
| * | Simplifications / cleanup from reviewFlorian Diebold2019-06-167-38/+31
| | |
| * | Some more cleanupFlorian Diebold2019-06-151-4/+4
| | |
| * | Check that Deref has the right number of parametersFlorian Diebold2019-06-151-2/+7
| | |
| * | Somewhat handle variables in the derefed type, and add another testFlorian Diebold2019-06-153-5/+61
| | |
| * | Implement * operation using Deref traitFlorian Diebold2019-06-151-3/+5
| | |
| * | Implement autoderef using the Deref traitFlorian Diebold2019-06-1511-47/+152
| | | | | | | | | | | | - add support for other lang item targets, since we need the Deref lang item
| * | Add basic infrastructure for assoc type projectionFlorian Diebold2019-06-158-21/+189
| | |
| * | Add test for DerefFlorian Diebold2019-06-151-0/+29
| |/
* | Merge #1406bors[bot]2019-06-165-108/+88
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1406: reuse AnalysisHost in batch analysis r=matklad a=matklad We do some custom setup in `AnalysisHost`, like setting up LRU size. I figure it's a good idea to not duplicate this work in batch analysis, *if* we want to keep batch and non-batch close. Long-term, I see a value in keeping batch a separate, lighter weight thing. However, because now we use batch to measure performance, keeping them closer makes more sense. I'd also like to add ability to get completions by using batch analysis, and that will require ra_ide_api as well. @flodiebold were there some reason why we haven't started with this approach from the start? Co-authored-by: Aleksey Kladov <[email protected]>
| * | reuse AnalysisHost in batch analysisAleksey Kladov2019-06-155-108/+88
| |/
* | Fix formattingShotaro Yamada2019-06-151-7/+3
| |
* | Skip attrs in `Literal::token`Shotaro Yamada2019-06-151-2/+17
|/
* re-enable backtraces on panicAleksey Kladov2019-06-151-2/+1
|
* Merge #1404bors[bot]2019-06-1520-72/+61
|\ | | | | | | | | | | | | | | | | | | 1404: Fight down failures! r=matklad a=mominul issue #1400 Now only `ra_tools` crate depends on `failure`, should I also fight those? :grin: Co-authored-by: Muhammad Mominul Huque <[email protected]>
| * CleanupMuhammad Mominul Huque2019-06-151-1/+1
| |
| * Fix a doc testMuhammad Mominul Huque2019-06-151-2/+3
| |
| * cargo formatMuhammad Mominul Huque2019-06-154-12/+4
| |
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-11 23:20:09 +0000