Commit Graph

9054 Commits

Author SHA1 Message Date
bors[bot]
ebd1309c9a
Merge #3906
3906: Implement proc_macro rustc server r=matklad a=edwin0cheng

This PR implement the `ra_tt::TokenTree` based rustc server for lib_proc_macro. 

Note that span information is not implemented yet. 

Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
2020-04-09 07:38:55 +00:00
Edwin Cheng
836384393b Remove unused func 2020-04-09 13:04:01 +08:00
Edwin Cheng
6af1015f74 Add rustc_server (ra_tt rustc bridge) 2020-04-09 12:22:45 +08:00
bors[bot]
080c983498
Merge #3902
3902: Better Sublime Documentation r=matklad a=Elinvynia

LSP by default now has the correct rust-analyzer configuration, I feel like updating it will make it less confusing for new users.

Co-authored-by: Elinvynia <59487684+Elinvynia@users.noreply.github.com>
2020-04-08 22:36:25 +00:00
Elinvynia
eb1ca5f448 Better Sublime documentation 2020-04-09 00:32:56 +02:00
bors[bot]
937fd557b0
Merge #3899
3899: Enable the SemanticTokensFeature by default r=matklad a=kjeremy

This is covered under vscode's "editor.semanticHighlighting.enabled"
setting plus the user has to have a theme that has opted into highlighting.

Bumps required vscode stable to 1.44

Closes #3773 

Co-authored-by: kjeremy <kjeremy@gmail.com>
2020-04-08 20:39:45 +00:00
kjeremy
6f0f86d2c5 Enable the SemanticTokensFeature by default
This is covered under vscode's "editor.semanticHighlighting.enabled"
setting plus the user has to have a theme that has opted into highlighting.

Bumps required vscode stable to 1.44
2020-04-08 15:45:39 -04:00
bors[bot]
779555c1be
Merge #3884
3884: Match check fix missing pattern panic r=flodiebold a=JoshMcguigan

As reported by @cynecx, match arm exhaustiveness checking could panic when tuple enums were missing their pattern. This was reported in the comments of #3706.

This fixes the panic, and adds a similar test to ensure tuples don't have this problem. 

It turns out malformed tuple patterns are caught in the "type check" outside the `is_useful` function, while malformed enum tuple patterns are not. This makes sense to me in hindsight, since the type checker can tell that an enum is the right type even if it is missing its internal pattern, but a tuple (non-enum) just becomes a different type if it is "missing" its pattern. This discrepency is why we report a diagnostic in the tuple case (because all arms are filtered out, so there are missing arms), but not in the enum tuple case (because we return an `Err(MalformedMatchArm)` from `is_useful`). I don't think this is that big of a deal, because in both cases this is malformed code and there should eventually be a `MalformedMatchArm` diagnostic or similar. But perhaps we should change things so that if any arm fails the type check we skip the entire diagnostic? That would at least make these two cases behave in the same way.

@flodiebold 

Co-authored-by: Josh Mcguigan <joshmcg88@gmail.com>
2020-04-08 17:52:41 +00:00
Josh Mcguigan
36c110ee09 match checking add additional test for match checking tuple with missing pattern 2020-04-08 10:47:05 -07:00
Josh Mcguigan
941615748d fix panic in match checking when tuple enum missing pattern 2020-04-08 10:47:05 -07:00
bors[bot]
4762c6d9c6
Merge #3895
3895: Fix warnings emitted when compiling as part of rustc r=matklad a=matklad



bors r+
🤖

Co-authored-by: Luca Barbieri <luca@luca-barbieri.com>
2020-04-08 14:15:54 +00:00
Luca Barbieri
35a69d09ee Fix warnings emitted when compiling as part of rustc 2020-04-08 14:49:19 +02:00
bors[bot]
8ea7c9cb62
Merge #3826
3826: Flatten nested highlight ranges during DFS traversal r=matklad a=ltentrup

Implements the flattening of nested highlights from #3447.


There is a caveat: I needed to add `Clone` to `HighlightedRange` to split highlight ranges  ~and the nesting does not appear in the syntax highlighting test (it does appear in the accidental-quadratic test but there it is not checked against a ground-truth)~.

I have added a test case for the example mentioned in #3447.

Co-authored-by: Leander Tentrup <leander.tentrup@gmail.com>
2020-04-08 12:00:08 +00:00
bors[bot]
9aa3bca536
Merge #3892
3892: Add L_DOLLAR for TYPE_RECOVERY_SET r=matklad a=edwin0cheng

This PR is a hot fix for issue #3861 that just prevent it make the parser being stuck.

The actual problem described in https://github.com/rust-analyzer/rust-analyzer/pull/3873#issuecomment-610208693 is a very deep rabbit hole I don't want to dig right now :(

Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
2020-04-08 10:51:46 +00:00
Edwin Cheng
53d05448c1 Add L_DOLLAR for TYPE_RECOVERY_SET 2020-04-08 18:34:20 +08:00
Aleksey Kladov
9e3c843847 fmt 2020-04-08 12:19:41 +02:00
Aleksey Kladov
ffb7ea678b Don't strip nightly releases 2020-04-08 11:47:40 +02:00
bors[bot]
d89c189ad1
Merge #3879
3879: Update some packages r=matklad a=kjeremy



Co-authored-by: kjeremy <kjeremy@gmail.com>
2020-04-07 16:55:28 +00:00
bors[bot]
0c927b4584
Merge #3882
3882: Move computation of missing fields into hir r=matklad a=matklad

cc @SomeoneToIgnore, this is that refactoring that moves computation of missing fields to hir. 

it actually removes meaningful duplication between diagnostics code and the completion code. Nontheless, it's a net addition of code :(

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2020-04-07 16:48:15 +00:00
Aleksey Kladov
4c29214bba Move computation of missing fields into hir 2020-04-07 18:34:17 +02:00
bors[bot]
173dccc804
Merge #3881
3881: Add functional update test r=matklad a=matklad



bors r+
🤖

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2020-04-07 16:26:49 +00:00
Aleksey Kladov
7819d99d6b Add functional update test 2020-04-07 18:25:47 +02:00
Aleksey Kladov
d8f6013404 Fix names of test modules 2020-04-07 18:23:18 +02:00
kjeremy
b8426f426a Update some packages 2020-04-07 11:17:54 -04:00
bors[bot]
33c364b545
Merge #3878
3878: A more precise panic macro r=matklad a=matklad



bors r+
🤖

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2020-04-07 14:41:07 +00:00
Aleksey Kladov
3bde2b7423 A more precise panic macro 2020-04-07 16:40:39 +02:00
Aleksey Kladov
5540193fc8 Don't insert !() if there's already some 2020-04-07 16:37:33 +02:00
Aleksey Kladov
73ccf7f495 Reorder imports 2020-04-07 15:07:18 +02:00
bors[bot]
97b963b44b
Merge #3706
3706: missing match arms diagnostic r=flodiebold a=JoshMcguigan

Following up on https://github.com/rust-analyzer/rust-analyzer/pull/3689#issuecomment-602718222, this PR creates a missing match arms diagnostic.

At the moment this is a very early draft, but I wanted to open it just to get some initial feedback.

Initial questions:

* Have I roughly created the correct boilerplate? 
* Inside the new `validate_match` function:
  * Am I correct in thinking I want to do validation by comparing the match arms against `match_expr`? And when analyzing `match_expr` I should be looking at it as a `hir_def::expr::Expr`?
  * I mostly copied the chained if-let statements from the struct validation. Shouldn't there be a non-failable way to get an AstPtr from the hir data structures? 

Thanks for all the guidance.

Co-authored-by: Josh Mcguigan <joshmcg88@gmail.com>
2020-04-07 12:53:47 +00:00
Josh Mcguigan
9fc1f51b7a add fixme to use type checker rather than manually comparing types 2020-04-07 05:17:59 -07:00
Josh Mcguigan
a208de15b7 PR feedback implementation 2020-04-07 05:12:08 -07:00
Josh Mcguigan
da6752d5f9 missing match arms diagnostic change source to match expression 2020-04-07 05:12:08 -07:00
Josh Mcguigan
5fe608fb31 handle match auto-deref 2020-04-07 05:12:08 -07:00
Josh Mcguigan
5b4316377b improving documentation 2020-04-07 05:12:08 -07:00
Josh Mcguigan
43dfd89493 handle non matching enum pattern types 2020-04-07 05:12:08 -07:00
Josh Mcguigan
b87b7a088f remove panics 2020-04-07 05:12:08 -07:00
Josh Mcguigan
8c378af721 missing match arms diagnostic 2020-04-07 05:12:08 -07:00
bors[bot]
b7e5d94bda
Merge #3876
3876: Better naming for scope completion r=matklad a=matklad



bors r+
🤖

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2020-04-07 11:23:03 +00:00
Aleksey Kladov
0215560434 Better naming for scope completion 2020-04-07 13:20:41 +02:00
Aleksey Kladov
a5ffe53c9d Better naming for path completion 2020-04-07 13:19:57 +02:00
Aleksey Kladov
79b48a9e77
Merge pull request #3863 from Veetaha/feature/migrate-to-rast
Migrate tests .txt -> .rast
2020-04-07 13:10:43 +02:00
bors[bot]
c8c6cb8a6b
Merge #3875
3875: When making a release, just promote the latest nightly r=matklad a=matklad



bors r+
🤖

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2020-04-07 09:47:40 +00:00
Aleksey Kladov
372e684f6e When making a release, just promote the latest nightly 2020-04-07 11:42:36 +02:00
Aleksey Kladov
9c482f4a21 Fix yaml 2020-04-07 09:40:01 +02:00
Aleksey Kladov
942836ac33 Fix yaml 2020-04-07 09:24:10 +02:00
Aleksey Kladov
baf9fcc38e
Merge pull request #3866 from lnicola/fewer-braces
Fix unnecessary braces warnings
2020-04-07 09:22:33 +02:00
bors[bot]
27285f93ac
Merge #3874
3874: Better config scheme & defaults r=matklad a=matklad



bors r+
🤖

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2020-04-07 07:01:45 +00:00
Aleksey Kladov
d3ccc80a2d Run analysis-stats nightly 2020-04-07 09:01:16 +02:00
Aleksey Kladov
501c5b45ac Better config scheme & defaults 2020-04-07 08:51:52 +02:00
bors[bot]
25596e1e1a
Merge #3872
3872: fix cargo check config with custom command r=matklad a=JoshMcguigan

fixes #3871

Previously if `get::<Vec<String>>(value, "/checkOnSave/overrideCommand")` returned `Some` we'd never execute `set(value, "/checkOnSave/command", command)`, even if the `overrideCommand` was empty. 

I am not sure of the best way to prove this, but I believe the LSP clients send this config with a default value if it is not set by the user, which means `get::<Vec<String>>(value, "/checkOnSave/overrideCommand")` would return `Some(vec![])` and thus we'd never set the command to the user specified value (in the case of #3871, "clippy").

I have tested this fix manually by installing this modified version of rust-analyzer and verifying I can see clippy lints in my editor (`coc.nvim`) with `rust-analyzer.checkOnSave.command": "clippy"`.

As best I can tell this would have affected rustfmt extra args too, so this PR also applies the same fix there.

Co-authored-by: Josh Mcguigan <joshmcg88@gmail.com>
2020-04-07 06:48:04 +00:00