8993: fix: don't show pd/ppd completions where it shouldn't be r=flodiebold a=eduardocanellas
Closes #8992
Co-authored-by: Eduardo Canellas <eduardocanellas98@gmail.com>
8994: Check for subdirs in vfs loader exclusions. r=matklad a=ammkrn
The current logic used to transfer global_excludes into vfs exclusions
only transfers global_excludes that are the parent of an item in
dirs.include.
This commit additionally adds an item from global_exclude to the vfs
exclusions if the global_exclude is a child of an included item.
Co-authored-by: ammkrn <ammkrn@tuta.io>
The current logic used to transfer global_excludes into vfs exclusions
only transfers global_excludes that are the parent of an item in
dirs.include.
This commit additionally adds an item from global_exclude to the vfs
exclusions if the global_exclude is a child of an included item.
The idea here is to eventually get rid of `dyn Diagnostic` and
`DiagnosticSink` infrastructure altogether, and just have a `enum
hir::Diagnostic` instead.
The problem with `dyn Diagnostic` is that it is defined in the lowest
level of the stack (hir_expand), but is used by the highest level (ide).
As a first step, we free hir_expand and hir_def from `dyn Diagnostic`
and kick the can up to `hir_ty`, as an intermediate state. The plan is
then to move DiagnosticSink similarly to the hir crate, and, as final
third step, remove its usage from the ide.
One currently unsolved problem is testing. You can notice that the test
which checks precise diagnostic ranges, unresolved_import_in_use_tree,
was moved to the ide layer. Logically, only IDE should have the infra to
render a specific range.
At the same time, the range is determined with the data produced in
hir_def and hir crates, so this layering is rather unfortunate. Working
on hir_def shouldn't require compiling `ide` for testing.
8990: feat: Also do goto implementation on assoc consts r=lnicola a=lf-
I forgot to put this into #8988, sorry.
Goto implementation on a const on the trait will go to the
implementations with their respective definitions of the const, if
present.
Co-authored-by: Jade <software@lfcode.ca>
I forgot to put this into #8988, sorry.
Goto implementation on a const on the trait will go to the
implementations with their respective definitions of the const, if
present.
8987: Fix lowering of FnOnce() without return type r=flodiebold a=flodiebold
This should result in an implicit `-> ()`, not leaving out the binding.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
8767: implement range formatting r=matklad a=euclio
Fixes#7580.
This PR implements the `textDocument/rangeFormatting` request using `rustfmt`'s `--file-lines` option.
Still needs some tests. What I want to know is how I should handle the instability of the `--file-lines` option. It's still unstable in rustfmt, so it's only available on nightly, and needs a special flag to enable. Is there a way for `rust-analyzer` to detect if it's using nightly rustfmt, or for users to opt-in?
Co-authored-by: Andy Russell <arussell123@gmail.com>
8986: Add go to type definition for struct fields within struct r=matklad a=lf-
Example:
```rust
struct A;
struct B {
a/*<- cursor*/: A,
}
```
Go to type definition used to not work on this position. It now goes to
`A` as expected.
Co-authored-by: Jade <software@lfcode.ca>
Example:
```rust
struct A;
struct B {
a/*<- cursor*/: A,
}
```
Go to type definition used to not work on this position. It now goes to
`A` as expected.
8942: Add `library` semantic token modifier to items from other crates r=arzg a=arzg
Closes#5772.
A lot of code here is pretty repetitive; please let me know if you have any ideas how to improve it, or whether it’s fine as-is.
Side-note: How can I add tests for this? I don’t see a way for the test Rust code in `test_highlighting` to reference other crates to observe the new behaviour.
Co-authored-by: Aramis Razzaghipour <aramisnoah@gmail.com>
8979: minor: update `CrateGraph` comment r=jonas-schievink a=jonas-schievink
`cfg` flags are now implemented, and crates *may* have names, it doesn't
doesn't matter for name resolution
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
8975: Use todo!() as placeholder body for generated match arms r=matklad a=jDomantas
`todo!()` seems to be a better fit for this than `{}`. Seeing that this assist predates stabilization of `todo` my guess is that simply no one bothered to change it yet.
Also fixed the issue where if the last arm was not block-like, rust-analyzer would not add a comma after it and would generate invalid code.
Co-authored-by: Domantas Jadenkus <djadenkus@gmail.com>
8970: fix: duplicate dependencies that have multiple DepKinds r=jonas-schievink a=jonas-schievink
Cargo collapses identical dependencies that are listed under `[dependencies]` and `[build-dependencies]` into a single `NodeDep`. We have to undo that by duplicating the dependency for each of its listed `DepKind`s.
Not doing that would incorrectly treat a dependency as `DepKind::Normal`, even though it is *also* meant to be a `DepKind::Build`.
Fixes https://github.com/rust-analyzer/rust-analyzer/pull/8812#issuecomment-847125395
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
8955: feature: Support standalone Rust files r=matklad a=SomeoneToIgnore
Closes https://github.com/rust-analyzer/rust-analyzer/issues/6388
Caveats:
* I've decided to support multiple detached files in the code (anticipating the scratch files), but I found no way to open multiple files in VSCode at once: running `code *.rs` makes the plugin to register in the `vscode.workspace.textDocuments` only the first file, while code actually displays all files later.
Apparently what happens is the same as when you have VSCode open at some workplace already and then run `code some_other_file.rs`: it gets opened in the same workspace of the same VSCode with no server to support it.
If there's a way to override it, I'd appreciate the pointer.
* No way to toggle inlay hints, since the setting is updated for the workspace (which does not exist for a single file opened)
> [2021-05-24 00:22:49.100] [exthost] [error] Error: Unable to write to Workspace Settings because no workspace is opened. Please open a workspace first and try again.
* No runners/lens to run or check the code are implemented for this mode.
In theory, we can detect `rustc`, run it on a file and run the resulting binary, but not sure if worth doing it at this stage.
Otherwise imports, hints, completion and other features work.
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
8938: internal: Fix#8931 r=flodiebold a=flodiebold
- and add some better checking for similar bugs
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
The problem was the skipping of binders in
`resolve_method_call_as_callable`; this still doesn't use the _correct_
substitution, but at least it doesn't return a type with free variables
in it.
Fixes#8931.
8921: Resolve any lifetime variables to 'static after inference r=flodiebold a=flodiebold
Chalk's unification can sometimes create lifetime variables, which we
currently don't really deal with, but at least we don't want to leak
them outside of inference.
Should fix#8919.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
Chalk's unification can sometimes create lifetime variables, which we
currently don't really deal with, but at least we don't want to leak
them outside of inference.
Should fix#8919.
8901: fix: `fill_match_arms` hangs on a tuple of large enums r=matklad a=iDawer
+ Lazy computation of missing arms.
+ Convenience function to test lazy computation: `ide_assists::tests::check_assist_unresolved`.
Fixes#8835
Co-authored-by: Dawer <7803845+iDawer@users.noreply.github.com>
8856: Use Chalk for unification r=flodiebold a=flodiebold
- use Chalk's unification, get rid of our own `unify`
- rewrite coercion to not use unification internals and to be more analogous to rustc
- fix various coercion bugs
- rewrite handling of obligations, since the old hacky optimization where we noted when an inference variable changes wasn't possible anymore
- stop trying to deeply resolve types all the time during inference, instead only do it shallowly where necessary
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
We can't do the easy hack that we did before anymore, where we kept
track of whether any inference variables changed since the last time we
rechecked obligations. Instead, we store the obligations in
canonicalized form; that way we can easily check the inference variables
to see whether they have changed since the goal was canonicalized.
8873: Implement import-granularity guessing r=matklad a=Veykril
This renames our `MergeBehavior` to `ImportGranularity` as rustfmt has it as the purpose of them are basically the same. `ImportGranularity::Preserve` currently has no specific purpose for us as we don't have an organize imports assist yet, so it currently acts the same as `ImportGranularity::Item`.
We now try to guess the import style on a per file basis and fall back to the user granularity setting if the file has no specific style yet or where it is ambiguous. This can be turned off by setting `import.enforceGranularity` to `true`.
Closes https://github.com/rust-analyzer/rust-analyzer/issues/8870
Co-authored-by: Lukas Tobias Wirth <lukastw97@gmail.com>
8885: internal: greatly simplify eager macro representation r=jonas-schievink a=jonas-schievink
- Share structures with lazy macros, make both use `MacroCallLoc`.
- Remove `intern_eager_expansion`, `EagerCallLoc`, `EagerMacroId`, and *many* matches on `MacroCallId`.
- Make a lot of FIXMEs obsolete since the code no longer distinguishes between eager and lazy macros.
- Add `EagerCallInfo`, which is `Some` for calls to eager macros and holds the argument or expansion result and the included file.
8887: fix: fix derive collection after unresolved attribute fallback r=jonas-schievink a=jonas-schievink
Fixes https://github.com/rust-analyzer/rust-analyzer/pull/8882#issuecomment-844379170
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
8884: fix: add_explicit_type produces invalid code on `@` patterns r=Veykril a=iDawer
In
```rust
let name @ () = ();
```
an explicit type should be inserted after the pattern, not just after the name.
`let` statement defined as `LetStmt = Attr* 'let' Pat (':' Type)? '=' initializer:Expr ';'`
Co-authored-by: Dawer <7803845+iDawer@users.noreply.github.com>
8882: internal: resolve attributes in name resolution (minimal version) r=jonas-schievink a=jonas-schievink
Closes https://github.com/rust-analyzer/rust-analyzer/pull/7049
This should not have any observable effect, since we don't attempt to expand attribute macros yet, and I have implemented a fallback that treats items with unresolved attributes as if the attribute wasn't there.
Derive helpers are not yet resolved. `#![register_{attr,tool}]` are not yet supported.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
7698: Add new LSP extension for workspace symbol lookup r=matklad a=alcroito
As well as all symbol types (functions, modules).
Remove outdated documentation regarding symbol lookup filtering.
Closes#4881
Co-authored-by: alcroito <placinta@gmail.com>
The new extension allows filtering of workspace symbool lookup
results by search scope or search kind.
Filtering can be configured in 3 different ways:
- The '#' or '*' markers can be added inline with the symbol lookup
query.
The '#' marker means symbols should be looked up in the current
workspace and any dependencies. If not specified, only current
workspace is considered.
The '*' marker means all kinds of symbols should be looked up
(types, functions, etc). If not specified, only type symbols are
returned.
- Each LSP request can take an optional search_scope or search_kind
argument query parameter.
- Finally there are 2 global config options that can be set for all
requests served by the active RA instance.
Add support for setting the global config options to the VSCode
extension.
The extension does not use the per-request way, but it's useful for
other IDEs.
The latest version of VSCode filters out the inline markers, so
currently the only reasonable way to use the new functionality is
via the global config.
8795: Allow semantic tokens for strings to be disabled r=matklad a=djrenren
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/7111
Pretty straightforward change, but open to any suggestions if there's a more recommended testing strategy than what I went with.
Co-authored-by: John Renner <john@jrenner.net>
8813: Get some more array lengths! r=lf- a=lf-
This is built on #8799 and thus contains its changes. I'll rebase it onto master when that one gets merged. It adds support for r-a understanding the length of:
* `let a: [u8; 2] = ...`
* `let a = b"aaa"`
* `let a = [0u8; 4]`
I have added support for getting the values of byte strings, which was not previously there. I am least confident in the correctness of this part and it probably needs some more tests, as we currently have only one test that exercised that part (!).
Fixes#2922.
Co-authored-by: Jade <software@lfcode.ca>
8819: Use package root as `cargo check` working directory r=matklad a=bcully
Cargo commands are affected by the `.cargo/config` files above
their working directory. If cargo is invoked from above the directory
holding `Cargo.toml`, it may not pick up important settings like
registry replacements, causing it to behave differently or even fail.
Most cargo invocations are currently setting their working directories
to the directory containing `Cargo.toml`, but a couple of paths remain
in which cargo is invoked from the default workspace root instead.
This change fixes that, resolving some cargo check failures that I
experienced in a multi-root workspace in which packages used different
registries.
Co-authored-by: Brendan Cully <brendan@cully.org>
Fix#2922: add unknown length as a condition for a type having unknown.
Incorporate reviews:
* Extract some of the const evaluation workings into functions
* Add fixmes on the hacks
* Add tests for impls on specific array lengths (these work!!! 😁)
* Add tests for const generics (indeed we don't support it yet)
Cargo commands are affected by the `.cargo/config` files above
their working directory. If cargo is invoked from above the directory
holding `Cargo.toml`, it may not pick up important settings like
registry replacements, causing it to behave differently or even fail.
Most cargo invocations are currently setting their working directories
to the directory containing `Cargo.toml`, but a couple of paths remain
in which cargo is invoked from the default workspace root instead.
This change fixes that, resolving some cargo check failures that I
experienced in a multi-root workspace in which packages used different
registries.
8799: Add basic support for array lengths in types r=flodiebold a=lf-
This recognizes `let a = [1u8, 2, 3]` as having type `[u8; 3]` instead
of the previous `[u8; _]`. Byte strings and `[0u8; 2]` kinds of range
array declarations are unsupported as before.
I don't know why a bunch of our rustc tests had single quotes inside
strings un-escaped by `UPDATE_EXPECT=1 cargo t`, but I don't think it's
bad? Maybe something in a nightly?
Co-authored-by: Jade <software@lfcode.ca>
8802: Keep comments and attrs when extracting struct from enum variant r=Veykril a=DropDemBits
Fixes#6730
Still unsure if existing visibilities of fields should be forced to pub (which is what was previously done), or if it's okay to keep it in the extracted struct.
Co-authored-by: DropDemBits <r3usrlnd@gmail.com>
8806: fix: Strip delimiter from fn-like macro invocations r=jonas-schievink a=jonas-schievink
This broke in https://github.com/rust-analyzer/rust-analyzer/pull/8796 (again), the fix is easy though
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
8796: internal: rewrite `#[derive]` removal to be based on AST (take 2) r=jonas-schievink a=jonas-schievink
Second attempt of https://github.com/rust-analyzer/rust-analyzer/pull/8443, this uses syntactical attribute offsets in `hir_expand`, and changes `attr.rs` to make those easy to derive.
This will make it easy to add similar attribute removal for attribute macros, unblocking them.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
