Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

⬆️ rust-analyzer #109069

Merged
merged 169 commits into from
Mar 13, 2023
Merged

⬆️ rust-analyzer #109069

merged 169 commits into from
Mar 13, 2023

Conversation

lnicola
Copy link
Member

@lnicola lnicola commented Mar 13, 2023

r? @ghost

jmviz and others added 30 commits February 17, 2023 17:41
…u when clauses to prevent irrelevant commands in non-rust files
- Remove unnecessary references and derefs
- Manual formatting
minor: Remove file added by mistake

This got added somehow in rust-lang/rust-analyzer#14154.
minor: Try to improve the `rustfmt.overrideCommand` docs

Closes rust-lang#14078
(This is a large commit. The changes to
`compiler/rustc_middle/src/ty/context.rs` are the most important ones.)

The current naming scheme is a mess, with a mix of `_intern_`, `intern_`
and `mk_` prefixes, with little consistency. In particular, in many
cases it's easy to use an iterator interner when a (preferable) slice
interner is available.

The guiding principles of the new naming system:
- No `_intern_` prefixes.
- The `intern_` prefix is for internal operations.
- The `mk_` prefix is for external operations.
- For cases where there is a slice interner and an iterator interner,
  the former is `mk_foo` and the latter is `mk_foo_from_iter`.

Also, `slice_interners!` and `direct_interners!` can now be `pub` or
non-`pub`, which helps enforce the internal/external operations
division.

It's not perfect, but I think it's a clear improvement.

The following lists show everything that was renamed.

slice_interners
- const_list
  - mk_const_list -> mk_const_list_from_iter
  - intern_const_list -> mk_const_list
- substs
  - mk_substs -> mk_substs_from_iter
  - intern_substs -> mk_substs
  - check_substs -> check_and_mk_substs (this is a weird one)
- canonical_var_infos
  - intern_canonical_var_infos -> mk_canonical_var_infos
- poly_existential_predicates
  - mk_poly_existential_predicates -> mk_poly_existential_predicates_from_iter
  - intern_poly_existential_predicates -> mk_poly_existential_predicates
  - _intern_poly_existential_predicates -> intern_poly_existential_predicates
- predicates
  - mk_predicates -> mk_predicates_from_iter
  - intern_predicates -> mk_predicates
  - _intern_predicates -> intern_predicates
- projs
  - intern_projs -> mk_projs
- place_elems
  - mk_place_elems -> mk_place_elems_from_iter
  - intern_place_elems -> mk_place_elems
- bound_variable_kinds
  - mk_bound_variable_kinds -> mk_bound_variable_kinds_from_iter
  - intern_bound_variable_kinds -> mk_bound_variable_kinds

direct_interners
- region
  - intern_region (unchanged)
- const
  - mk_const_internal -> intern_const
- const_allocation
  - intern_const_alloc -> mk_const_alloc
- layout
  - intern_layout -> mk_layout
- adt_def
  - intern_adt_def -> mk_adt_def_from_data (unusual case, hard to avoid)
  - alloc_adt_def(!) -> mk_adt_def
- external_constraints
  - intern_external_constraints -> mk_external_constraints

Other
- type_list
  - mk_type_list -> mk_type_list_from_iter
  - intern_type_list -> mk_type_list
- tup
  - mk_tup -> mk_tup_from_iter
  - intern_tup -> mk_tup
add openDocs command to context menu in VS Code extension

This adds the `openDocs` command to the VS Code context menu. I believe there are probably many user who are unaware of this command existing in the rust analyzer extension, and that this should enhance the discoverability of the command. Additionally, even if people are aware of this capability, it's helpful to have this in the context menu anyway; for example, one might forget the name of the command, or the keybinding they have assigned to it. I think that opening docs is a common enough action to warrant the extra line added to the context menu.

This makes a few other small changes as well. There are two minor style changes to increase style consistency. First, it changes the titles of the two commands that the rust analyzer extension will contribute to the context menu to title case. All standard VS Code commands that appear in the context menu are in title case. Second, it shortens the title of the `openDocs` command from `Open docs under cursor` to `Open Docs`. The implicit assumption in the standard VS Code context menu command titles is that the action applies to the symbol under the cursor: `Go to Definition`, `Find All References`, etc. Note that since these are changes to the command titles, rather than the command names themselves, these changes will not break any users' existing keybindings for these commands.

Second, this adds further restrictions to the `where` clauses of the two commands that the rust analyzer extension will contribute to the context menu, so that the two commands will appear in the context menu only when in a Rust project **and** within a Rust file. Say you have a Python or bash script inside your Rust project. Having these commands appear in the context menu when you right click a symbol in such a non-Rust file is extraneous and potentially confusing.

![demonstration](https://user-images.githubusercontent.com/6609145/219976062-b46ab21b-5753-48f5-a1da-562566cae71c.gif)
minor: import `Either` from `either`

This is a clean-up patch to replace `use itertools::Either` with `use either::Either` for the sake of consistency.
…=lnicola

fix: Add check for extra path segments after a fully qualified one

`type A = <()>;` is parsed just fine by rust-analyzer, but then rejected by rustc:

```
error: expected `::`, found `;`
 --> x.rs:7:14
  |
7 | type A = <()>;
  |              ^ expected `::`

```

Fixed by adding a lookahead for the `::` token after fully-qualified path segments.
Respect $CARGO_HOME when looking up toolchains.

Some people set `$CARGO_HOME` to a location other than `~/.cargo` (`$XDG_DATA_DIR/cargo`,  in my case), and I'd be a little nicer if the rust-analyzer extension and server respect that value when looking up toolchains, instead of having us configure all of `$CARGO`, `$RUSTC` ... manually.

The new implementation still defaults to `~/.cargo` if `$CARGO_HOME` is unset, pretty much like cargo itself does (as documented in https://doc.rust-lang.org/cargo/guide/cargo-home.html), so the change is backwards compatible for most people except those who has configured `$CARGO_HOME` explicitly.

I considered using https://crates.io/crates/home as suggested by https://doc.rust-lang.org/cargo/guide/cargo-home.html, but decided to put int on hold because i) we need mirror impl in node, ii) I thought the consistency matters more and iii) the new implementation shouldn't be worse than the current one (i.e. switching to `home` improvement is rather orthogonal and could be done in another PR). If you have any directions on this, please let me know.
fix:add a case in which remainig is None in resolveing types when resolving hir path.

fix rust-lang#14030 The variable type is being determined incorrectly
This PR fixed a problem in which `go to definition` is jumping to the incorrect position because it was failing to resolve the type in case it defined in the module when resolving hir.
In addition, I added a test for this issue and refactored the related code.
This is my first PR and I am using a translation tool to write this text. Let me know if you have any problems.
add: clean api to get `raw_ptr` type

There doesn't seem to be an API to fetch the type of `raw_ptr`, which is helpful for a project I work on.

Notes:

- I am unsure about the function name, do let me know if I should use something else.
- Also unsure about where to add tests, for hir changes. Will fix it as needed.
@rustbot
Copy link
Collaborator

rustbot commented Mar 13, 2023

Some changes occurred in src/tools/rust-analyzer

cc @rust-lang/rust-analyzer

@lnicola
Copy link
Member Author

lnicola commented Mar 13, 2023

@bors r+ p=1

@bors
Copy link
Contributor

bors commented Mar 13, 2023

📌 Commit e862901 has been approved by lnicola

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 13, 2023
@bors
Copy link
Contributor

bors commented Mar 13, 2023

⌛ Testing commit e862901 with merge 7b693790ea41b0882c0a7fdc3c4ec428d24d75cc...

@bors
Copy link
Contributor

bors commented Mar 13, 2023

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Mar 13, 2023
@lnicola
Copy link
Member Author

lnicola commented Mar 13, 2023

@bors retry #108227

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 13, 2023
@bors
Copy link
Contributor

bors commented Mar 13, 2023

⌛ Testing commit e862901 with merge 5d918ffedbb4af0fdce78cc476d6c3158758b992...

@bors
Copy link
Contributor

bors commented Mar 13, 2023

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Mar 13, 2023
@lnicola
Copy link
Member Author

lnicola commented Mar 13, 2023

@bors retry #108227

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 13, 2023
@bors
Copy link
Contributor

bors commented Mar 13, 2023

⌛ Testing commit e862901 with merge 8efa635...

@bors
Copy link
Contributor

bors commented Mar 13, 2023

☀️ Test successful - checks-actions
Approved by: lnicola
Pushing 8efa635 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Mar 13, 2023
@bors bors merged commit 8efa635 into rust-lang:master Mar 13, 2023
@rustbot rustbot added this to the 1.70.0 milestone Mar 13, 2023
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (8efa635): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-0.7% [-0.8%, -0.7%] 3
Improvements ✅
(secondary)
-0.5% [-0.7%, -0.3%] 2
All ❌✅ (primary) -0.7% [-0.8%, -0.7%] 3

Max RSS (memory usage)

This benchmark run did not return any relevant results for this metric.

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
5.2% [4.2%, 6.3%] 4
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) - - 0

@lnicola lnicola deleted the rust-analyzer-2023-03-13 branch March 14, 2023 06:15
bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 20, 2023
…lnicola

⬆️ `rust-analyzer`

r? `@ghost`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.