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 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.
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.
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.
(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
Conditionally add snippet marker.
Fixes#14161.
Heya, I just added the code with some tests, but not sure if it's *the way* to do it -- I didn't refactor existing methods for the `check` test method, but added another calling layer.
