| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| | |
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 <[email protected]>
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
We shouldn't be looking at the source map unless we actually have
diagnostics.
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
9218: Item search now respects trait impl items r=Veykril a=Veykril
Fixes #2977
Co-authored-by: Lukas Wirth <[email protected]>
|
| | |/ |
|
| |/ |
|
| | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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 <[email protected]>
Co-authored-by: Jonas Schievink <[email protected]>
|
| | |/
|/| |
|
| |/ |
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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 <[email protected]>
|
