| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
It creates a big map and duplicates lots of impls that are then left
lying around
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
5169: Add reload workspace command r=matklad a=matklad
bors r+
🤖
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | |
|
|/ |
|
|
|
|
|
|
| |
Add a test in call_hierarchy that already passed
Fixes #5103
|
|\
| |
| |
| |
| |
| |
| |
| | |
5162: Try to reduce Semantics monomorphisations r=matklad a=lnicola
Co-authored-by: Laurențiu Nicola <[email protected]>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| | |
5159: Don't fail expect tests in rewrite mode r=matklad a=matklad
bors r+
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | | |
| \ | |
|\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
5154: Structured search debugging r=matklad a=davidlattimore
Adds a "search" mode to the rust-analyzer binary that does structured search (SSR without the replace part). This is intended primarily for debugging why a bit of code isn't matching a pattern.
5157: Use dynamic dispatch in AstDiagnostic r=matklad a=lnicola
Co-authored-by: David Lattimore <[email protected]>
Co-authored-by: Laurențiu Nicola <[email protected]>
|
| | | |
|
| | | |
|
|\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | |
| | |
| | | |
5158: Use CrateName correctly r=matklad a=matklad
bors r+
🤖
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | |
|
| | | |
|
| | | |
|
|\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
5153: Make SemanticsScope non-generic r=matklad a=lnicola
This slightly reduces the build times:
![image](https://user-images.githubusercontent.com/308347/86210975-3a809480-bb7e-11ea-8975-788457f6b353.png)
(compare to https://github.com/rust-analyzer/rust-analyzer/issues/1987#issuecomment-652202248)
Co-authored-by: Laurențiu Nicola <[email protected]>
|
| |/ |
|
|/
|
|
| |
Closes #5139
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
5142: analysis-stats: allow parallel type inference r=matklad a=jonas-schievink
This is mostly just for testing/fun, but it looks like type inference can be sped up massively with little to no effort (since it runs after the serial phases are already done).
Without `--parallel`:
```
Item Collection: 16.43597698s, 683mb allocated 720mb resident
Inference: 25.429774879s, 1720mb allocated 1781mb resident
Total: 41.865866352s, 1720mb allocated 1781mb resident
```
With `--parallel`:
```
Item Collection: 16.380369815s, 683mb allocated 735mb resident
Parallel Inference: 7.449166445s, 1721mb allocated 1812mb resident
Inference: 143.437157ms, 1721mb allocated 1812mb resident
Total: 23.973303611s, 1721mb allocated 1812mb resident
```
Co-authored-by: Jonas Schievink <[email protected]>
|
| | |
|
| |
| |
| |
| | |
closes #5125
|
| | |
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
5138: Refactor runnable tests r=matklad a=matklad
bors r+
🤖
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| | |
5136: Split namespace maps in `ItemScope` r=jonas-schievink a=jonas-schievink
Reduces memory usage of the CrateDefMap query by ~130 MB (50%) on r-a.
I was also looking into handling glob imports more efficiently (storing scope chains instead of always duplicating everything into the glob-importing module's scope), but it seems that this already gives the most significant wins.
Co-authored-by: Jonas Schievink <[email protected]>
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
Reduces memory usage of the CrateDefMap query by ~130 MB on r-a.
|
| | |
|
| | |
|
| | |
|
|/ |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
5132: Fix some typos r=matklad a=davidlattimore
Co-authored-by: David Lattimore <[email protected]>
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
5101: Add expect -- a light-weight alternative to insta r=matklad a=matklad
This PR implements a small snapshot-testing library. Snapshot updating is done by setting an env var, or by using editor feature (which runs a test with env-var set).
Here's workflow for updating a failing test:
![expect](https://user-images.githubusercontent.com/1711539/85926956-28afa080-b8a3-11ea-9260-c6d0d8914d0b.gif)
Here's workflow for adding a new test:
![expect-fresh](https://user-images.githubusercontent.com/1711539/85926961-306f4500-b8a3-11ea-9369-f2373e327a3f.gif)
Note that colorized diffs are not implemented in this PR, but should be easy to add (we already use them in test_utils).
Main differences from insta (which is essential for rust-analyzer development, thanks @mitsuhiko!):
* self-updating tests, no need for a separate tool
* fewer features (only inline snapshots, no redactions)
* fewer deps (no yaml, no persistence)
* tighter integration with editor
* first-class snapshot object, which can be used to write test functions (as opposed to testing macros)
* trivial to tweak for rust-analyzer needs, by virtue of being a workspace member.
I think eventually we should converge to a single snapshot testing library, but I am not sure that `expect` is exactly right, so I suggest rolling with both insta and expect for some time (if folks agree that expect might be better in the first place!).
# Editor Integration Implementation
The thing I am most excited about is the ability to update a specific snapshot from the editor. I want this to be available to other snapshot-testing libraries (cc @mitsuhiko, @aaronabramov), so I want to document how this works.
The ideal UI here would be a code action (:bulb:). Unfortunately, it seems like it is impossible to implement without some kind of persistence (if you save test failures into some kind of a database, like insta does, than you can read the database from the editor plugin). Note that it is possible to highlight error by outputing error message in rustc's format. Unfortunately, one can't use the same trick to implement a quick fix.
For this reason, expect makes use of another rust-analyzer feature -- ability to run a single test at the cursor position. This does need some expect-specific code in rust-analyzer unfortunately. Specifically, if rust-analyzer notices that the cursor is on `expect!` macro, it adds a special flag to runnable's JSON. However, given #5017 it is possible to approximate this well-enough without rust-analyzer integration. Specifically, an extension can register a special runner which checks (using regexes) if rust-anlyzer runnable covers text with specific macro invocation and do special magic in that case.
closes #3835
Co-authored-by: Aleksey Kladov <[email protected]>
|
| |
| |
| | |
Co-authored-by: Veetaha <[email protected]>
|
| | |
|