Commit Graph

17 Commits

Author SHA1 Message Date
bors[bot]
86c534f244
Merge #10440
10440: Fix Clippy warnings and replace some `if let`s with `match` r=Veykril a=arzg

I decided to try fixing a bunch of Clippy warnings. I am aware of this project’s opinion of Clippy (I have read both [rust-lang/clippy#5537](https://github.com/rust-lang/rust-clippy/issues/5537) and [rust-analyzer/rowan#57 (comment)](https://github.com/rust-analyzer/rowan/pull/57#discussion_r415676159)), so I totally understand if part of or the entirety of this PR is rejected. In particular, I can see how the semicolons and `if let` vs `match` commits provide comparatively little benefit when compared to the ensuing churn.

I tried to separate each kind of change into its own commit to make it easier to discard certain changes. I also only applied Clippy suggestions where I thought they provided a definite improvement to the code (apart from semicolons, which is IMO more of a formatting/consistency question than a linting question). In the end I accumulated a list of 28 Clippy lints I ignored entirely.

Sidenote: I should really have asked about this on Zulip before going through all 1,555 `if let`s in the codebase to decide which ones definitely look better as `match` :P

Co-authored-by: Aramis Razzaghipour <aramisnoah@gmail.com>
2021-10-05 08:58:40 +00:00
Aramis Razzaghipour
9583dd5725
Replace if let with match where appropriate 2021-10-05 09:00:21 +11:00
Lukas Wirth
a359a1f2e3 Fix extract_variable not allowing to extract macro calls 2021-10-03 11:09:49 +02:00
Aleksey Kladov
2bf81922f7 internal: more reasonable grammar for blocks
Consider these expples

        { 92 }
  async { 92 }
    'a: { 92 }
   #[a] { 92 }

Previously the tree for them were

  BLOCK_EXPR
    { ... }

  EFFECT_EXPR
    async
    BLOCK_EXPR
      { ... }

  EFFECT_EXPR
    'a:
    BLOCK_EXPR
      { ... }

  BLOCK_EXPR
    #[a]
    { ... }

As you see, it gets progressively worse :) The last two items are
especially odd. The last one even violates the balanced curleys
invariant we have (#10357) The new approach is to say that the stuff in
`{}` is stmt_list, and the block is stmt_list + optional modifiers

  BLOCK_EXPR
    STMT_LIST
      { ... }

  BLOCK_EXPR
    async
    STMT_LIST
      { ... }

  BLOCK_EXPR
    'a:
    STMT_LIST
      { ... }

  BLOCK_EXPR
    #[a]
    STMT_LIST
      { ... }
2021-09-26 19:16:09 +03:00
Lukas Wirth
a044175412 Simplify 2021-09-13 18:50:19 +02:00
Lukas Wirth
b96f1adf5c Give TypeInfo fields and methods more appropriate names 2021-08-03 17:28:51 +02:00
Lukas Wirth
8afa2722b2 Revise TypeInfo::ty usage 2021-08-03 17:24:43 +02:00
Lukas Wirth
25ff7171c4 Introduce TypeInfo 2021-08-03 16:41:53 +02:00
Lukas Wirth
9279c1c939 Don't offer extract_variable assist when there is no surrounding block 2021-07-21 17:52:54 +02:00
Brandon
7d2710218f Don't show extract into variable assist for unit expressions 2021-06-02 00:59:09 -07:00
Aleksey Kladov
984d20aad8 cleanups 2021-05-09 18:01:54 +03:00
Aleksey Kladov
30d6419bc9 fix: extract variable works in guards
closes #8336
2021-04-05 14:40:56 +03:00
Laurențiu Nicola
fc9eed4836 Use upstream cov-mark 2021-03-08 22:19:44 +02:00
Vladyslav Katasonov
afc68277f6 pull out suggest_name::* to utils; enchance heuristics 2021-03-02 16:25:22 +03:00
Vladyslav Katasonov
f915ab79fa suggest parameter name before function name 2021-03-02 16:23:00 +03:00
Vladyslav Katasonov
3b75dda745 try to suggest name when extracting variable 2021-03-02 16:23:00 +03:00
Chetan Khilosiya
e4756cb4f6 7526: Rename crate assists to ide_assists. 2021-02-23 00:59:16 +05:30