feat!: create alias when renaming an import.
Closes#15858
Implemented:
- [x] - Prevent using `reserved` keywords (e.g self) and `_`.
- [x] - Rename other modules that might be referencing the import.
- [x] - Fix "broken" tests.
- [ ] - Rename **only** "direct" references.
- [ ] - Test more cases.
Future possibilities:
1. Also support `extern crate <name>` syntax.
2. Allow aliasing `self` when it is inside an `UseTreeList`.
~3. If import path already has an alias, "rename" the alias.~
~[4. Create alias even if path is not the last path segment.](https://github.com/rust-lang/rust-analyzer/pull/16489#issuecomment-1930541697)~
feat: add non-exhaustive-let diagnostic
I want this to have a quickfix to add an else branch but I couldn't figure out how to do that, so here's the diagnostic on its own. It pretends a `let` is a match with one arm, and asks the match checking whether that match would be exhaustive.
Previously the pattern was checked based on its own type, but that was causing a panic in `match_check` (while processing e.g. `crates/hir/src/lib.rs`) so I changed it to use the initialiser's type instead, to align with the checking of actual match expressions. I think the panic can still happen, but I hear that `match_check` is going to be updated to a new version from rustc, so I'm posting this now in the hopes that the panic will magically go away when that happens.
Deduplicate references when some of them are in macro expansions
EDIT: I wonder if this is a regression, I'll try to investigate.
Commit 6a06f6f72 (Deduplicate reference search results, 2022-11-07)
deduplicates references within each definition.
Apparently our descend_into_macros() stanza returns
one definition for each time a name is used in a macro.
Each of those definitions has the same set of references.
We return them all, leading to many redundant references.
Work around this by deduplicating definitions as well. Perhaps there
is a better fix to not produce duplicate definitions in the first
place.
I discovered this working with the "bitflags" macro from the crate
of the same name.
Fixes#16357
distribute tool documentations and avoid file conflicts on `x install`
I suggest reading commits one-by-one with the descriptions for more context about the changes.
Fixes#115213
test: include `rename_path_inside_use_tree`.
Keeps tracks the progress of the changes. 3 other tests broke with the changes
of this.
feat: rename all other usages within the current file.
feat: fix most of the implementation problems.
test: `rename_path_inside_use_tree` tests a more complicated scenario.
Commit 6a06f6f72 (Deduplicate reference search results, 2022-11-07) deduplicates references
within each definition.
There is an edge case when requesting references of a macro argument. Apparently, our
descend_into_macros() stanza in references.rs produces a cartesian product of
- references inside the macro times
- times references outside the macro.
Since the above deduplication only applies to the references within a single definition, we
return them all, leading to many redundant references.
Work around this by deduplicating definitions as well. Perhaps there is a better fix to not
produce this cartesian product in the first place; but I think at least for definitions the
problem would remain; a macro can contain multiple definitions of the same name, but since the
navigation target will be the unresolved location, it's the same for all of them.
We can't use unique() because we don't want to drop references that don't have a declaration
(though I dont' have an example for this case).
I discovered this working with the "bitflags" macro from the crate of the same name.
Fixes#16357
feat: Support multiple tab stops for completions in VSCode
Uses the native VSCode support for `SnippetTextEdit`s. Fixes#13229 and fixes#8531.
https://github.com/rust-lang/rust-analyzer/assets/13354275/a2d2c033-bb30-4f34-92ca-bf3f4f744cdc
This is done in a slightly hacky way, as `vscode-languageclient` can't convert RA's `SnippetTextEdit`s into vscode `SnippetTextEdit`s and will appear to use a [different format](295aaa393f/types/src/main.ts (L1501-L1516)) in the future.
---
~~Marked as draft since as-is, this will cause completions to double-indent any multi-line code generated.~~
**Update:** This also fixes up edits so that any multi-line code won't be double-indented.
Specialize some methods of `io::Chain`
This PR specializes the implementation of some methods of `io::Chain`, which could bring performance improvements when using it.
Portable SIMD subtree update
Syncs nightly to the latest changes from rust-lang/portable-simd
r? `@rust-lang/libs`
Also, fixes#119904 which is now fixed upstream.
macro_rules: Preserve all metavariable spans in a global side table
This PR preserves spans of `tt` metavariables used to pass tokens to declarative macros.
Such metavariable spans can then be used in span combination operations like `Span::to` to improve all kinds of diagnostics.
Spans of non-`tt` metavariables are currently kept in nonterminal tokens, but the long term plan is remove all nonterminal tokens from rustc parser and rely on the proc macro model with invisible delimiters (#114647, #67062).
In particular, `NtIdent` nonterminal (corresponding to `ident` metavariables) becomes easy to remove when this PR lands (#119412 does it).
The metavariable spans are kept in a global side table keyed by `Span`s of original tokens.
The alternative to the side table is keeping them in `SpanData` instead, but the performance regressions would be large because any spans from tokens passed to declarative macros would stop being inline and would work through span interner instead, and the penalty would be paid even if we never use the metavar span for the given original span.
(But also see the comment on `fn maybe_use_metavar_location` describing the map collision issues with the side table approach.)
There are also other alternatives - keeping the metavar span in `Token` or `TokenTree`, but associating it with `Span` itsel is the most natural choice because metavar spans are used in span combining operations, and those operations are not necessarily tied to tokens.
Tracking import use types for more accurate redundant import checking
fixes#117448
By tracking import use types to check whether it is scope uses or the other situations like module-relative uses, we can do more accurate redundant import checking.
For example unnecessary imports in std::prelude that can be eliminated:
```rust
use std::option::Option::Some;//~ WARNING the item `Some` is imported redundantly
use std::option::Option::None; //~ WARNING the item `None` is imported redundantly
```
fixes#117448
For example unnecessary imports in std::prelude that can be eliminated:
```rust
use std::option::Option::Some;//~ WARNING the item `Some` is imported redundantly
use std::option::Option::None; //~ WARNING the item `None` is imported redundantly
```
Properly deal with weak alias types as self types of impls
Fixes#114216.
Fixes#116100.
Not super happy about the two ad hoc “normalization” implementations for weak alias types:
1. In `inherent_impls`: The “peeling”, normalization to [“WHNF”][whnf]: Semantically that's exactly what we want (neither proper normalization nor shallow normalization would be correct here). Basically a weak alias type is “nominal” (well...^^) if the WHNF is nominal. [#97974](https://github.com/rust-lang/rust/pull/97974) followed the same approach.
2. In `constrained_generic_params`: Generic parameters are constrained by a weak alias type if the corresp. “normalized” type constrains them (where we only normalize *weak* alias types not arbitrary ones). Weak alias types are injective if the corresp. “normalized” type is injective.
Both have ad hoc overflow detection mechanisms.
**Coherence** is handled in #117164.
r? `@oli-obk` or types
[whnf]: https://en.wikipedia.org/wiki/Lambda_calculus_definition#Weak_head_normal_form
Make `io::BorrowedCursor::advance` safe
This also keeps the old `advance` method under `advance_unchecked` name.
This makes pattern like `std::io::default_read_buf` safe to write.
Support configuring the set of codegen backends to build per host triple
This allows building the compiler itself with one backend while using another backend at runtime. For example this allows compiling rustc to wasm using LLVM, while using Cranelift at runtime to produce actual code. Cranelift can't compile to wasm, but is perfectly capable of running on wasm. LLVM can compile to wasm, but can't run on wasm. [^1]
[^1]: The prototype of this still requires a couple of other patches.
fix: Fix snippets being placed leftwards of where they should be
Snippet bits were being escaped before placing snippets, shifting snippets leftwards. Snippets were also being shifted leftwards on files with CRLF line endings since they were placed done after the Unix -> DOS line ending conversion.
Hoping this fixes all of the little bugs related to snippet rendering 😅
internal: Parse (nightly) `const` and `async` trait bounds
Both of these bound modifiers were added recently:
* `const` trait bounds: https://github.com/rust-lang/rust/pull/119099
* `async` trait bounds: https://github.com/rust-lang/rust/pull/120392
The latter will certainly will not do the right thing; namely, `async Fn` needs to be mapped to the `AsyncFn` trait. IDK how to do that, so advice would be appreciated, though perhaps we could land this first so the parser isn't complaining about these bounds?
