9380: feat: Implement goto_declaration support r=matklad a=Veykril
This is just a simple implementation that falls back to `goto_definition` for everything but modules where it goes to the actual module declaration if possible.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9353: Include extra targets when the pkg_root is not the same as the target root. r=matklad a=rezural
Fixes#7715
For example, if a sub-crate includes sets the path='../somewhere-else/lib.rs', the files will not be in pkg_root , but in the target root's parent.
It may actually be in root.parent().parent(), I'm not sure about that.
At the moment it is just a fix, are there any relevant tests that this could go in? I've got about 1 brain cell left... but im happy to add tests where appropriate.
Co-authored-by: rezural <rezural@protonmail.com>
Definition::visibility was implemented in a rather roundabout way -- by
asking the parent module about the effective visibility.
This is problematic for a couple of reasons:
* first, it doesn't work for local items
* second, asking module about visibility of a child is a linear
operation (that's a problem in itself, tracked in #9378)
Instead, lets ask the declared visibility directly, we have all the code
for it, and need only to actually us it.
9348: output to log file if RA_LOG_FILE is defined in environment r=rezural a=rezural
This adds a check for RA_LOG_FILE, and logs to that if defined. It currently overrides flags.log_file. If this is undesirable, I will add a check.
Co-authored-by: rezural <rezural@protonmail.com>
This story begins in #8384, where we added a smart test for our syntax
highting, which run the algorithm on synthetic files of varying length
in order to guesstimate if the complexity is O(N^2) or O(N)-ish.
The test turned out to be pretty effective, and flagged #9031 as a
change that makes syntax highlighting accidentally quadratic. There was
much rejoicing, for the time being.
Then, lnicola asked an ominous question[1]: "Are we sure that the time
is linear right now?"
Of course it turned out that our sophisticated non-linearity detector
*was* broken, and that our syntax highlighting *was* quadratic.
Investigating that, many brave hearts dug deeper and deeper into the
guts of rust-analyzer, only to get lost in a maze of traits delegating
to traits delegating to macros.
Eventually, matklad managed to peel off all layers of abstraction one by
one, until almost nothing was left. In fact, the issue was discovered in
the very foundation of the rust-analyzer -- in the syntax trees.
Worse, it was not a new problem, but rather a well-know, well-understood
and event (almost) well-fixed (!) performance bug.
The problem lies within `SyntaxNodePtr` type -- a light-weight "address"
of a node in a syntax tree [3]. Such pointers are used by rust-analyzer all
other the place to record relationships between IR nodes and the
original syntax.
Internally, the pointer to a syntax node is represented by node's range.
To "dereference" the pointer, you traverse the syntax tree from the
root, looking for the node with the right range. The inner loop of this
search is finding a node's child whose range contains the specified
range. This inner loop was implemented by naive linear search over all
the children. For wide trees, dereferencing a single `SyntaxNodePtr` was
linear. The problem with wide trees though is that they contain a lot of
nodes! And dereferencing pointers to all the nodes is quadratic in the
size of the file!
The solution to this problem is to speed up the children search --
rather than doing a linear lookup, we can use binary search to locate
the child with the desired interval.
Doing this optimization was one of the motivations (or rather, side
effects) of #6857. That's why `rowan` grew the useful
`child_or_token_at_range` method which does exactly this binary search.
But looks like we've never actually switch to this method? Oups.
Lesson learned: do not leave broken windows in the fundamental infra.
Otherwise, you'll have to repeatedly re-investigate the issue, by
digging from the top of the Everest down to the foundation!
[1]: https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/.60syntax_highlighting_not_quadratic.60.20failure/near/240811501
[2]: https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/Syntax.20highlighting.20is.20quadratic
[3]: https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/Syntax.20highlighting.20is.20quadratic/near/243412392
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>
