Commit Graph

14970 Commits

Author SHA1 Message Date
Vladyslav Katasonov
f0d2bb9131 disable test for downgrading mutability on extract 2021-02-03 17:46:57 +03:00
Vladyslav Katasonov
88b3034636 convert IdentPat to Pat via Into
before child getter was used
2021-02-03 17:45:36 +03:00
bors[bot]
fd84df9e1b
Merge #7541
7541: Use block_def_map in body lowering (third time's the charm) r=jonas-schievink a=jonas-schievink

After https://github.com/rust-analyzer/rust-analyzer/pull/7380 and https://github.com/rust-analyzer/rust-analyzer/pull/7506 both had to be reverted, this should have finally resolved all remaining bugs.

Most importantly, the optimization to skip `block_def_map` computation when the block contains no inner items was fixed (which fortunately was simpler than expected).

I've ran `analysis-stats` on libstd locally, which works fine, and also ran this PR locally for a short while without issues.

Note that this *still* has no (or almost no) user-facing impact, because the rest of r-a still relies on some local item support hacks.

bors r+

Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
2021-02-03 14:41:13 +00:00
Jonas Schievink
63744fe128 Test for name resolution with DefMap shortcut 2021-02-03 15:33:25 +01:00
Jonas Schievink
da57f5dc17 Shortcut block_def_map if there's no inner items
This previously didn't work, but apparently only because of the wonky
test setup
2021-02-03 15:33:25 +01:00
bors[bot]
93ecef53a3
Merge #7539
7539: Add cargo file tidy test r=edwin0cheng a=edwin0cheng

bors r+

cc @pksunkara 

Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
2021-02-03 14:02:30 +00:00
Edwin Cheng
e73ffbf1e5 Add cargo file tidy test 2021-02-03 22:01:09 +08:00
Jonas Schievink
7eff6705cc Use body lowering for block_def_map tests
Removes the hacky and buggy custom lowering code
2021-02-03 14:21:15 +01:00
Jonas Schievink
b7be2b1d3c Use block_def_map in body lowering 2021-02-03 14:21:15 +01:00
bors[bot]
85e1f0905a
Merge #7538
7538: Make sure normal dependencies always have version r=edwin0cheng a=pksunkara

How do I prevent this happening in the future by doing something in the CI? IIRC this is the second time.

Co-authored-by: Pavan Kumar Sunkara <pavan.sss1991@gmail.com>
2021-02-03 12:59:22 +00:00
Pavan Kumar Sunkara
a89fc070c6
Make sure normal dependencies always have version 2021-02-03 12:51:07 +00:00
bors[bot]
05b3fe4255
Merge #7537
7537: Fix spelling mistakes in docs/dev r=Veykril a=Veykril

Also adds a line for `crates/cfg` and `crates/stdx` to the architecture.

bors r+

Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
2021-02-03 12:48:13 +00:00
Lukas Wirth
f82ce500a9 Fix spelling mistakes in docs/dev 2021-02-03 13:46:51 +01:00
bors[bot]
81a9ad3672
Merge #7536
7536: Make architecture more informative r=matklad a=matklad

bors r+
🤖

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2021-02-03 11:26:49 +00:00
Aleksey Kladov
1008aaae58 Make architecture more informative
Call out boundaries and invariants
2021-02-03 14:26:23 +03:00
Vladyslav Katasonov
1e6f13a0be support extracting methods; no mut lowering
currently mut refernce will *not* be downgraded to shared
if it is sufficient(see relevant test for example)
2021-02-03 12:27:53 +03:00
Vladyslav Katasonov
bc3ae81a87 initial version of extract function assist
there are a few currently limitations:
* no modifications of function body
* does not handle mutability and references
* no method support
* may produce incorrect results
2021-02-03 10:57:11 +03:00
bors[bot]
95e03ec499
Merge #7528
7528: Update mimalloc r=kjeremy a=kjeremy



Co-authored-by: kjeremy <kjeremy@gmail.com>
2021-02-02 22:18:58 +00:00
kjeremy
b9ad1f587d Update mimalloc 2021-02-02 17:17:49 -05:00
bors[bot]
7e66cde764
Merge #7525
7525: Fix resolution of `crate` paths from within blocks r=jonas-schievink a=jonas-schievink

They resolve to the crate root, not the DefMap's root module (which
can be a block)

bors r+

Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
2021-02-02 17:02:48 +00:00
Jonas Schievink
5914f86d47 Fix resolution of crate paths from within blocks
They resolve to the crate root, not the DefMap's root module (which
can be a block)
2021-02-02 18:02:12 +01:00
bors[bot]
12e8cc4aa2
Merge #7523
7523: Bump chalk and rustc_lexer r=lnicola a=lnicola

bors r+

Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
2021-02-02 15:40:43 +00:00
Laurențiu Nicola
6b60206669 Bump rustc_lexer 2021-02-02 17:40:01 +02:00
Laurențiu Nicola
9c4b799dce Bump chalk 2021-02-02 17:40:01 +02:00
bors[bot]
042e07d891
Merge #7522
7522: Use non-deprecated memmap2 crate r=kjeremy a=kjeremy

`cargo audit` complains that `memmap` is unmaintained so switch to
RazrFalcon's maintained version.

Removes yet another edge on winapi

Co-authored-by: kjeremy <kjeremy@gmail.com>
2021-02-02 15:27:01 +00:00
kjeremy
953883ca54 Use non-deprecated memmap2 crate
`cargo audit` complains that `memmap` is unmaintained so switch to
RazrFalcon's maintained version.

Removes yet another edge on winapi
2021-02-02 10:25:17 -05:00
bors[bot]
a02a7a9aa6
Merge #7521
7521: cargo update r=kjeremy a=kjeremy

Pulls in soundness fix from rowan.

Co-authored-by: kjeremy <kjeremy@gmail.com>
2021-02-02 15:09:34 +00:00
kjeremy
1c9e216f69 cargo update 2021-02-02 10:00:34 -05:00
bors[bot]
cc3112de1b
Merge #7520
7520: Show alias underlying type r=lnicola a=lumenian

Closes #7511 

Display underlying type in the tooltip:
```rust
pub type SomeAlias = f64
```
instead of:
```rust
pub type SomeAlias
```

Co-authored-by: lumenian <lumenian@gmail.com>
2021-02-02 14:59:29 +00:00
lumenian
cafaab8b96 Show alias underlying type 2021-02-02 17:47:56 +03:00
bors[bot]
96f9f0741f
Merge #7519
7519: add useless types to the styleguide r=matklad a=matklad

bors r+

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2021-02-02 13:09:21 +00:00
Aleksey Kladov
283c3b0133 add useless types to the styleguide 2021-02-02 15:41:57 +03:00
bors[bot]
8720f7f146
Merge #7518
7518: Use the right `DefMap` when looking up modules r=jonas-schievink a=jonas-schievink

Fixes the bugs encountered in https://github.com/rust-analyzer/rust-analyzer/pull/7506#issuecomment-771417467

bors r+

Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
2021-02-02 11:37:45 +00:00
Jonas Schievink
cd9659ffce Use the right DefMap when looking up modules 2021-02-02 12:36:38 +01:00
bors[bot]
157156276b
Merge #7516
7516: Revert "Use block_def_map in body lowering" r=jonas-schievink a=jonas-schievink

Reverts rust-analyzer/rust-analyzer#7506

bors r+

Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
2021-02-02 10:47:22 +00:00
Jonas Schievink
7202ce6c96
Revert "Use block_def_map in body lowering" 2021-02-02 11:46:58 +01:00
bors[bot]
3c1fcfcd1b
Merge #7514
7514: Only allow one proc-macro process r=edwin0cheng a=edwin0cheng

cc @lnicola

bors r+

Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
2021-02-01 20:57:26 +00:00
Edwin Cheng
4adf13e2ef Only allow one proc-macro process 2021-02-02 04:55:17 +08:00
bors[bot]
379b677559
Merge #7512
7512: Reap proc macro server instances r=lnicola a=lnicola

Fixes #7510, but not the root cause.

Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
2021-02-01 19:25:00 +00:00
Laurențiu Nicola
7ed80bae92 Reap proc macro server instances 2021-02-01 21:24:09 +02:00
bors[bot]
c0d3e315e3
Merge #7509
7509: Improve nvim-lsp setup instructions r=lnicola a=lnicola

bors r+

Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
2021-02-01 18:20:53 +00:00
Laurențiu Nicola
84c324b3dd Improve nvim-lsp setup instructions 2021-02-01 20:20:15 +02:00
bors[bot]
4131e88bb7
Merge #7508
7508: Don't filter code suggestions on Applicability r=lnicola a=CryZe

I've noticed that there are various suggestions that rust-analyzer seems to filter out, even if they make sense.

Here's an example of where it seems like there should be a suggestion, but there isn't:

![https://i.imgur.com/wsjM6iz.png](https://i.imgur.com/wsjM6iz.png)

It turns out that this specific suggestion is not considered `MachineApplicable`, which are the only suggestions that rust-analyzer accepts. However if you read the documentation for `MachineApplicable`,

[Source](b3897e3d13/compiler/rustc_lint_defs/src/lib.rs (L27-L29))
```rust
/// The suggestion is definitely what the user intended. This suggestion should be
/// automatically applied.
MachineApplicable,
```

then you realize that these are specifically only those suggestions that rust-analyzer could even automatically apply (in some distant future, behind some setting or command or so). Other suggestions that may have some semantic impact do not use `MachineApplicable`. So all other suggestions are still intended to be suggested to the user, just not automatically applied without the user being consulted.

[Source](b3897e3d13/compiler/rustc_lint_defs/src/lib.rs (L22-L24))
```rust
/// All suggestions are marked with an `Applicability`. Tools use the applicability of a suggestion
/// to determine whether it should be automatically applied or if the user should be consulted
/// before applying the suggestion.
```

So with that in mind, rust-analyzer should almost definitely not filter out `MaybeIncorrect` (which honestly is named horribly, it just means that it's a semantic change, not just a syntactical one).

Then there's `HasPlaceholders` which basically is just another semantic one, but with placeholders. The user will have to make some adjustments, but the suggestion still is perfectly valid. rust-analyzer could probably detect those placeholders and put proper "tab through" markers there for the IDE, but that's not necessary for now.

Then the last one is `Unspecified` which is so unknown that I don't even know how to judge it, meaning that the suggestion should probably also just be suggested to the user and then they can decide.

So with all that in mind, I'm proposing to get rid of the check for Applicability entirely.

Co-authored-by: Christopher Serr <christopher.serr@gmail.com>
2021-02-01 16:41:52 +00:00
Christopher Serr
b072bbed2a Update Test Data 2021-02-01 17:36:51 +01:00
Christopher Serr
2e8c1d13ad Don't filter code suggestions on Applicability
I've noticed that there are various suggestions that rust-analyzer seems
to filter out, even if they make sense.

Here's an example of where it seems like there should be a suggestion,
but there isn't:

![https://i.imgur.com/wsjM6iz.png](https://i.imgur.com/wsjM6iz.png)

It turns out that this specific suggestion is not considered
`MachineApplicable`, which are the only suggestions that rust-analyzer
accepts. However if you read the documentation for `MachineApplicable`,

b3897e3d13/compiler/rustc_lint_defs/src/lib.rs (L27-L29)

then you realize that these are specifically only those suggestions that
rust-analyzer could even automatically apply (in some distant future,
behind some setting or so). Other suggestions that may have some
semantic impact do not use `MachineApplicable`. So all other suggestions
are still intended to be suggested to the user, just not automatically
applied without the user being consulted.

b3897e3d13/compiler/rustc_lint_defs/src/lib.rs (L22-L24)

So with that in mind, rust-analyzer should almost definitely not filter
out `MaybeIncorrect` (which honestly is named horribly, it just means
that it's a semantic change, not just a syntactical one).

Then there's `HasPlaceholders` which basically is just another semantic
one, but with placeholders. The user will have to make some adjustments,
but the suggestion still is perfectly valid. rust-analyzer could
probably detect those placeholders and put proper "tab through" markers
there for the IDE, but that's not necessary for now.

Then the last one is `Unspecified` which is so unknown that I don't even
know how to judge it, meaning that the suggestion should probably also
just be suggested to the user and then they can decide.

So with all that in mind, I'm proposing to get rid of the check for
Applicability entirely.
2021-02-01 16:57:04 +01:00
bors[bot]
2d9bb69990
Merge #7507
7507: Explain what to do if a release fails r=lnicola a=lnicola

bors r+

Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
2021-02-01 14:46:56 +00:00
Laurențiu Nicola
5e61d62fdc Explain what to do if a release fails 2021-02-01 16:46:23 +02:00
bors[bot]
746b89d1c3
Merge #7506
7506: Use block_def_map in body lowering r=jonas-schievink a=jonas-schievink

This makes `lower_block` update the `DefMap` and `ModuleId` used by the expander to the corresponding `block_def_map`. This cleans up a bit of code, but doesn't expose any new features.

bors r+

Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
2021-02-01 12:42:31 +00:00
Jonas Schievink
b4aa860cac Shortcut block_def_map if there's no inner items
This previously didn't work, but apparently only because of the wonky
test setup
2021-02-01 13:33:18 +01:00
Jonas Schievink
80ae583dc0 Use body lowering for block_def_map tests
Removes the hacky and buggy custom lowering code
2021-02-01 13:33:18 +01:00