The completion of cfg will look at the enabled cfg keys when
performing completion.
It will also look crate features when completing a feature cfg
option. A fixed list of known values for some cfg options are
provided.
For unknown keys it will look at the enabled values for that cfg key,
which means that completion will only show enabled options for those.
9264: feat: Make documentation on hover configurable r=Veykril a=Veykril
This also implements deprecation support for config options as this renames `hoverActions_linksInHover` to `hover_linksInHover`.
Fixes#9232
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9227: Add a config setting to disable the 'test' cfg in specified crates r=matklad a=lf-
If you are opening libcore from rust-lang/rust as opposed to e.g.
goto definition from some other crate which would use the sysroot
instance of libcore, a `#![cfg(not(test))]` would previously have made
all the code excluded from the module tree, breaking the editor
experience.
Core does not need to ever be edited with `#[cfg(test)]` enabled,
as the tests are in another crate.
This PR puts in a slight hack that checks for the crate name "core" and
turns off `#[cfg(test)]` for that crate.
Fixes#9203Fixes#9226
Co-authored-by: Jade <software@lfcode.ca>
If you are opening libcore from rust-lang/rust as opposed to e.g.
goto definition from some other crate which would use the sysroot
instance of libcore, a `#![cfg(not(test))]` would previously have made
all the code excluded from the module tree, breaking the editor
experience.
This puts in a slight hack that checks for the crate name "core" and
turns off `#[cfg(test)]`.
9334: feat: Allow to disable import insertion on single path glob imports r=Veykril a=Veykril
On by default as I feel like this is something the majority would prefer.
Closes#8490
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9321: Inline generics in const and function trait completions r=Veykril a=RDambrosio016
This PR does a couple of things:
- moves path_transform from ide_assists to ide_db to be shared by both assists and completions
- when completing a const or a function for a trait, it will "inline" any generics in those associated items instead
of leaving the generic's name. For example:
```rust
trait Foo<T> {
const BAR: T;
fn foo() -> T;
}
struct Bar;
impl Foo<u32> for Bar {
// autocompletes to this
fn foo() -> u32;
// and not this (old)
fn foo() -> T;
// also works for associated consts and where clauses
const BAR: u32 = /* */
}
```
Currently this does not work for const generics, because `PathTransform` does not seem to account for them. If this should work on const generics too, `PathTransform` will need to be changed. However, it is uncommon to implement a trait only for a single const value, so this isnt a huge concern.
Co-authored-by: rdambrosio <rdambrosio016@gmail.com>
9258: minor: Give `ImportPrefix` variants better config names r=matklad a=Veykril
I feel like `crate` and `self` work better than `by_crate` and `by_self`. The only reason for the current names were that `Self` doesn't work for the variant name on the rust side so I forgot about setting proper config names on serde layer.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9294: internal: introduce minicore -- a subset of libcore for testing r=matklad a=matklad
Clearly, we need one more fixed point iteration loop!
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
It's better to handle magical cases upper in the stack, because it
allows for better re-use of the general implementation below. So, we
pull the `self` case up here.
The end goal is to put `Definition::rename` to the `ide_db`, because
it's a generally re-usable functionality useful for different ide
features, alongside with the search which is already there.
NavigationTarget is strictly a UI-level thing -- it describes where the
cursor should be placed when the user presses goto definition. It
doesn't make any semantic guaratees about rage and focus range and, as
such, is not suitable for driving renames.
9260: tree-wide: make rustdoc links spiky so they are clickable r=matklad a=lf-
Rustdoc was complaining about these while I was running with --document-private-items and I figure they should be fixed.
Co-authored-by: Jade <software@lfcode.ca>
At the moment, this moves only a single diagnostic, but the idea is
reafactor the rest to use the same pattern. We are going to have a
single file per diagnostic. This file will define diagnostics code,
rendering range and fixes, if any. It'll also have all of the tests.
This is similar to how we deal with assists.
After we refactor all diagnostics to follow this pattern, we'll probably
move them to a new `ide_diagnostics` crate.
Not that we intentionally want to test all diagnostics on this layer,
despite the fact that they are generally emitted in the guts on the
compiler. Diagnostics care to much about the end presentation
details/fixes to be worth-while "unit" testing. So, we'll unit-test only
the primary output of compilation process (types and name res tables),
and will use integrated UI tests for diagnostics.
9244: feat: Make block-local trait impls work r=flodiebold a=flodiebold
As long as either the trait or the implementing type are defined in the same block.
CC #8961
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
9239: fix: Fix coercion in match with expected type r=flodiebold a=flodiebold
Plus add infrastructure to test type mismatches without expect.
CC #8961
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
9204: feat: more accurate memory usage info on glibc Linux r=jonas-schievink a=jonas-schievink
This adds support for the new `mallinfo2` API added in glibc 2.33. It addresses a shortcoming in the `mallinfo` API where it was unable to handle memory usage of more than 2 GB, which we sometimes exceed.
Blocked on https://github.com/rust-lang/libc/pull/2228
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9192: internal: Build test-macros in a build script r=jonas-schievink a=jonas-schievink
This build the test-proc-macros in `proc_macro_test` in a build script, and copies the artifact to `OUT_DIR`. This should make it available throughout all of rust-analyzer at no cost other than depending on `proc_macro_test`, fixing https://github.com/rust-analyzer/rust-analyzer/issues/9067.
This hopefully will let us later write inline tests that utilize proc macros, which makes my life fixing proc macro bugs easier.
Opening this as a sort of RFC, because I'm not totally sure this approach is the best.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9202: feat: Make `MemoryUsage` work on Windows r=jonas-schievink a=jonas-schievink
Unfortunately there is no convenient API for heap statistics, so this instead uses the Commit Charge value, which is the amount of memory that needs to be allocated either in physical RAM or in the page file. This approximation seems to be good enough to find queries that waste a large amount of memory, but it should generally be expected to be off by several MB.
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9181: Don't complete values in type position r=jonas-schievink a=Veykril
Will add some proper tests in a bit
9182: fix: don't complete derive macros as fn-like macros r=jonas-schievink a=jonas-schievink
Part of https://github.com/rust-analyzer/rust-analyzer/issues/8518
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9169: internal: steps towards attribute macro token mapping r=jonas-schievink a=jonas-schievink
This doesn't work yet, but we seem to be getting a bit further along (for example, we now stop highlighting `use` items inside item with attribute macros as if they were written verbatim).
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9144: Extend convert_tuple_struct_to_named_struct to also apply to enum tuple variants r=matklad a=joshuawarner32
This is largely copied and adapted from the existing `convert_tuple_struct_to_named_struct` code.
Not sure if maybe some of this code can/should be shared between those two assists - but the differences are significant enough to make it at least seem like a non-trivial refactor.
Co-authored-by: Joshua Warner <joshuawarner32@gmail.com>
9164: internal: Reduce the number of direct fields in `CompletionContext` some more r=Veykril a=Veykril
Doesn't make the code much simpler yet.
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
e.g. if you have a trait T and `impl T for S` for some struct, if you
goto definition on some function name inside the impl, it will go to the
definition of that function inside the `trait T` block, rather than the
current behaviour of not going anywhere at all.
9148: minor: Prevent renaming of aliases on usages r=Veykril a=Veykril
Otherwise trying to rename a usage that goes through an alias will still rename the aliased item instead, cc https://github.com/rust-analyzer/rust-analyzer/issues/5671
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9130: Prefix/suffix parameter inlay hint hiding heuristic is more strict r=Veykril a=Veykril
Instead of just plainly checking prefix/suffix of the argument string to the parameter name we only check for prefixes and suffixes if they are split apart via an underscore meaning, with the argument `foo`, it will be hidden for the parameter name `foo_bar` but not for `foobar`.
bors r+
Closes https://github.com/rust-analyzer/rust-analyzer/issues/8878
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9127: internal: make variant fields inherit the enum's visibility in the ItemTree r=jonas-schievink a=jonas-schievink
No observable changes from what I can tell, but this is "more correct".
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9119: fix: some minor "extract type alias" fixes r=jonas-schievink a=jonas-schievink
It now correctly works inside traits, and no longer messes up the indentation of the original node
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9117: Allow expand-macro to be invoked anywhere inside a macro call r=Veykril a=Veykril
I don't really see a reason to only limit this to the name-ref of a macro.
bors r+
Closes#4606
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9108: Don't show extract into variable assist for unit expressions r=jonas-schievink a=brandondong
**Reproduction:**
```rust
fn main() {
let mut i = 3;
$0if i >= 0 {
i += 1;
} else {
i -= 1;
}$0
}
```
1. Select the snippet of code between the $0's.
2. The extract into variable assist shows up, pushing down the more useful extract into function assist.
3. The resulting output of selecting the extract into variable assist is valid but with the extracted variable having the unit type:
```rust
fn main() {
let mut i = 3;
let var_name = if i >= 0 {
i += 1;
} else {
i -= 1;
};
var_name
}
```
**Fix:**
- Don't show the extract into variable assist for unit expressions. I could not think of any scenarios where such a variable extraction would be desired.
Co-authored-by: Brandon <brandondong604@hotmail.com>
9112: Fix some bugs in `extract_struct_from_enum_variant` assist r=Veykril a=Veykril
bors r+
Fixes#9100Fixes#9099
Kind of fixes #9109, it now copies all the generics might be incorrect if the variant doesn't use all of them)
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9111: fix: make "extract type alias" place extracted type alias outside of impl r=jonas-schievink a=jonas-schievink
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
8717: Update match checking algorithm r=iDawer a=iDawer
I've recently got interest in the match checking to extend the current algo to support reporting witnesses of non-exhaustiveness.
It appears the algo is outdated from rustc's implementation. I decided to rewrite it based on the latest rustc's version. It is a diff-based port to ra codebase. That means you can diff-compare these files to rustc.
I'm striving to keep minimal ra-related changes in the algo to make it easier to backport future changes from the upstream.
Based on upstream algorithm of version rust-lang/rust 1.52.0-nightly (25c15cdbe 2021-04-22)
https://github.com/rust-lang/rust/blob/25c15cdbe/compiler/rustc_mir_build/src/thir/pattern/usefulness.rs
The goal of this PR is to cover the current `missing-match-arm` diagnostic.
What is remaining to do:
- [x] Error handling. The errors that are unrelated to match checking will be handled before the check. Just like how it made in rustc.
- [x] Lowering `hir_def::expr::Pat` to `hir_ty::diagnostics::match_check::Pat`. rustc's match checking works on top of `rustc_mir_build::thir::Pat`, which is lowered from `hir::Pat` and carries some extra semantics used by the check. All unrelated checks are done there. RA could use this to rule out running the check on unimplemented cases (`Pat::ConstBlock`, etc).
- [x] ~~Proper~~Loose typecheck of match arm patterns (https://github.com/rust-analyzer/rust-analyzer/pull/8840, https://github.com/rust-analyzer/rust-analyzer/pull/8875).
- [x] Tests from `hir_ty::diagnostics::match_check::tests`.
- [x] Clean up `todo`s
- [x] Test run on real repos https://github.com/rust-analyzer/rust-analyzer/pull/8717#issuecomment-847120265.
Co-authored-by: Dawer <7803845+iDawer@users.noreply.github.com>
fn is_useful , more skeletons
Specify a lifetime on pattern references
impl PatStack
fill impl Matrix
PatStack::pop_head_constructor
Index-based approach
struct PatCtxt
fields construction fn Fields::wildcards
split wildcard
fn Constructor::is_covered_by_any(..)
fn Matrix::specialize_constructor(..)
impl Usefulness
Initial work on witness construction
Reorganize files
Replace match checking diagnostic
Handle types of expanded patterns
unit match checking go brrr
8952: add support of impl block for doctest into runnables r=matklad a=bnjjj
close#6356
Co-authored-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
8866: Update salsa r=matklad a=jonas-schievink
This updates salsa to include https://github.com/salsa-rs/salsa/pull/265, and removes all cancellation-related code from rust-analyzer
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9060: feat: Diagnose unimplemented built-in macros r=matklad a=jonas-schievink
A number of built-in attribute macros are unsupported, I thought it might be useful to put a diagnostic on their definition in libcore. Not sure.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9051: Fix incorrect setting descriptions r=lnicola a=sclu1034
Descriptions for diagnostic warning hint and info display were swapped.
Fixes#8485.
Co-authored-by: Lucas Schwiderski <lucas@lschwiderski.de>
9027: feat: Attribute completion is context aware r=Veykril a=Veykril
This splits off the `lint` and `derive` completions into their own submodules of `attribute`.
The idea is to create a lazy global hashmap that maps `SyntaxKind` to attribute names(`&[&str]`) in which we index with the syntax kind of the "thing" we are attributing giving us the attributes back that are valid for this kind. Then we use this name to do a binary search on the attribute list to fetch and build the corresponding completion item.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9040: Don't label derive macros with their banged_name r=Veykril a=Veykril
cc https://github.com/rust-analyzer/rust-analyzer/issues/7072#issuecomment-850396203
This doesn't fix it non builtin derives yet I think cause of a FIXME somewhere that doesn't categorize proc-macro derives as derives yet
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9029: minor: test that `ItemTree` makes `hir_def` queries syntax-independent r=jonas-schievink a=jonas-schievink
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
8997: internal: stop expanding UseTrees during ItemTree lowering r=jonas-schievink a=jonas-schievink
Closes https://github.com/rust-analyzer/rust-analyzer/issues/8908
Messy diff, but `ItemTree` lowering got simpler, since we now have a strict 1-to-1 mapping between `ast::Item` and `ModItem`.
The most messy part is mapping a single `UseTree` back to its `ast::UseTree` counterpart for diagnostics, but I think the ad-hoc source map built during lowering does the job.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9017: internal: Reduce the number of traits passed through chalk during applicable trait lookup r=SomeoneToIgnore a=SomeoneToIgnore
Inherent traits can be omitted before trait solving, presumably slightly helping https://github.com/rust-analyzer/rust-analyzer/issues/7542 and slightly simplifying the code.
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
9015: Merge pattern completion related bools into an enum r=Veykril a=Veykril
The two bools can never both be set so this is basically just a tri-state enum.
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9012: feat: add tab stops for keyword completions r=matklad a=eduardocanellas
Add tab stops for all the keywords that I judged fit. I also introduced some line breaks and spaces, following the pattern I saw in the `postfix` module.
Co-authored-by: Eduardo Canellas <eduardocanellas98@gmail.com>
9002: Move annotations below item attributes r=Veykril a=Veykril
This moves annotations/code lenses below attributes in items, bringing them inline with functions where this is already the case. This is done by changing the annotations covering range to just the name node's range which is also more inline with what the lsp expects which is that the range should ideally only cover a single line.
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/9000
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
8996: Fix bug where library functions were not highlighted as such r=arzg a=arzg
Sorry about forgetting to test this in my last PR.
Co-authored-by: Aramis Razzaghipour <aramisnoah@gmail.com>
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>
