-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
⬆️ rust-analyzer
#109069
Conversation
…u when clauses to prevent irrelevant commands in non-rust files
minor: Sync from downstream
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.
minor: Simplify
Some changes occurred in src/tools/rust-analyzer cc @rust-lang/rust-analyzer |
ea18568
to
e862901
Compare
@bors r+ p=1 |
⌛ Testing commit e862901 with merge 7b693790ea41b0882c0a7fdc3c4ec428d24d75cc... |
💔 Test failed - checks-actions |
⌛ Testing commit e862901 with merge 5d918ffedbb4af0fdce78cc476d6c3158758b992... |
💔 Test failed - checks-actions |
☀️ Test successful - checks-actions |
Finished benchmarking commit (8efa635): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesResultsThis 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.
|
…lnicola ⬆️ `rust-analyzer` r? `@ghost`
r? @ghost