`hir` should know nothing about URLs, markdown and html. It should
only be able to:
* resolve stringy path from documentation
* generate canonical stringy path for a def
In contrast, link rewriting should not care about semantics of paths
and names resolution, and should be concern only with text mangling
bits.
5893: Allow running a test as a binary r=matklad a=jonas-schievink
If a test uses `harness = false`, it just contains an `fn main` that is executed via `cargo test`. This adds support for that.
Note though that Cargo doesn't actually tell us whether `harness = false`, so this hint will always show up when you put an `fn main` into an integration test. Normally people shouldn't be doing that if they do use the harness though.
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
Overlapping indels are a bug. Checking this *always* is tricky (needs
a sorted data structure to not suffer O(N^2) perf). But
opportunistically checking small indels should give provide 80% of the
benefits.
4873: Resolve links in hover documentation r=matklad a=zacps
This PR resolves links in hover documentation. Both the upcoming intra-doc-links style and the old "path-based" style.
## Todo
* [x] More tests
* [ ] Benchmark (Is there an easy way to benchmark this?)
* [x] ~~Resolve issues with the markdown parser/get rid of it~~ Migrate to `pulldown_cmark_to_cmark`
* [x] Reorganise code (Tips appreciated)
---
Fixes#503
Co-authored-by: Zac Pullar-Strecker <zacmps@gmail.com>
4776: Do a weekly minor publish to crates.io r=matklad a=pksunkara
This is the same system I set up on Chalk repo.
Every week it creates a new minor version, pushes it to github and then deploys it to crates.io.
Co-authored-by: Pavan Kumar Sunkara <pavan.sss1991@gmail.com>
5845: Omit lenses for not runnable doctests r=matklad a=SomeoneToIgnore
Ideally, we should properly parse the doctest attributes before, but since I need it for the code lens only, this way should suffice for now
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
We might want to provide more efficient impls for check if usages
exist, limiting the search, filtering and cancellation, so let's
violate YAGNI a bit here.
Main one: instead of adding a parameter to function to handle special
case, make the caller handle it.
Second main one: make sure that function does a reasonable thing.
`highlight_def` picks a color for def, *regardless* of the context
the def is use. Feeding an info from the call-site muddies the
responsibilities here.
Minor smells, flagging the function as having space for improvement in
the first place:
* many parameters, some of which are set as constants on most
call-sites (introduce severalfunction instad)
* boolean param (add two functions instead)
5643: Add new consuming modifier, apply consuming and mutable to methods r=matklad a=Nashenas88
This adds a new `consuming` semantic modifier for syntax highlighters.
This also emits `mutable` and `consuming` in two cases:
- When a method takes `&mut self`, then it now has `function.mutable` emitted.
- When a method takes `self`, and the type of `Self` is not `Copy`, then `function.consuming` is emitted.
CC @flodiebold
Co-authored-by: Paul Daniel Faria <Nashenas88@users.noreply.github.com>
5695: Added completion for unstable features r=matklad a=Fihtangolz
Added xtask for downloading list of unstable features from the unstable book and codegen for it. Also included small changes from linter.
Co-authored-by: Dmitry <mamhigtt@gmail.com>
Co-authored-by: Dmitry Opokin <mamhigtt@gmail.com>
5682: Add an option to disable diagnostics r=matklad a=popzxc
As far as I know, currently it's not possible to disable a selected type of diagnostics provided by `rust-analyzer`.
This causes an inconvenient situation with a false-positive warnings: you either have to disable all the diagnostics, or you have to ignore these warnings.
There are some open issues related to this problem, e.g.: https://github.com/rust-analyzer/rust-analyzer/issues/5412, https://github.com/rust-analyzer/rust-analyzer/issues/5502
This PR attempts to make it possible to selectively disable some diagnostics on per-project basis.
Co-authored-by: Igor Aleksanov <popzxc@yandex.ru>
5687: Fix document symbols order r=matklad a=magurotuna
Resolves#5655
And adds tests for `handle_document_symbol`, both with `hierarchical_symbols` enabled and with it disabled.
Previously document symbols were displayed in reverse order in sublime text with its LSP plugin, but this patch fixes it like this:
Co-authored-by: Yusuke Tanaka <yusuktan@maguro.dev>
5758: SSR: Explicitly autoderef and ref placeholders as needed r=matklad a=davidlattimore
Structural search replace now inserts *, & and &mut in the replacement to match any auto[de]ref in the matched code.
e.g. `$a.foo() ==>> bar($a)` might convert `x.foo()` to `bar(&mut x)`
Co-authored-by: David Lattimore <dml@google.com>
The idea here is that, on CI, we only want to cache crates.io
dependencies, and not local crates. This keeps the size of the cache
low, and also improves performance, as network and moving files on
disk (on Windows) can be slow.
5776: Fix eslint errors on .eslintrc.js and rollup.config.js r=matklad a=fuafa
Eslint complains if these two files does not include in the `tsconfig.json`.
```
Parsing error: "parserOptions.project" has been set for @typescript-eslint/parser.
The file does not match your project config: .eslintrc.js.
The file must be included in at least one of the projects provided.eslint
```
5780: Fixup whitespace when adding missing impl items r=matklad a=jDomantas
Generate properly formatted whitespace when adding impl items - with an empty line between items and removing extra whitespace that often appears at the end.
This is my first time working on rust analyzer so I'm not very familiar with its internal APIs. If there's a better way to do such syntax tree editing I'd be glad to hear it.
Co-authored-by: xiaofa <xiaofalzx@gmail.com>
Co-authored-by: jDomantas <djadenkus@gmail.com>
5766: Hacky support for fn-like proc macros r=matklad a=jonas-schievink
It turns out that this is all that's needed to get something like this working:
```rust
#[proc_macro]
pub fn function_like_macro(_args: TokenStream) -> TokenStream {
TokenStream::from_str("fn fn_success() {}").unwrap()
}
```
```rust
function_like_macro!();
fn f() {
fn_success();
}
```
The drawback is that it also makes this work, because there is no distinction between different proc macro kinds in the rest of r-a:
```rust
#[derive(function_like_macro)]
struct S {}
fn f() {
fn_success();
}
```
Another issue is that it seems to panic, and then panic, when using this on the rustc code base, due to some issue in the inscrutable proc macro bridge code.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
Conjecture: it's impossible to use hir::Path *correctly* from an IDE.
I am not entirely sure about this, and we might need to add it back at
some point, but I have to arguments that convince me that we probably
won't:
* `hir::Path` has to know about hygiene, which an IDE can't set up
properly.
* `hir::Path` lacks identity, but you actually have to know identity
to resolve it correctly
5637: SSR: Matching trait associated constants, types and functions r=matklad a=davidlattimore
This fixes matching of things like `HashMap::default()` by resolving `HashMap` instead of `default` (which resolves to `Default::default`).
Same for associated constants and types that are part of a trait implementation.
However, we still don't support matching calls to trait methods.
Co-authored-by: David Lattimore <dml@google.com>
5553: Add fix ranges for diagnostics r=matklad a=SomeoneToIgnore
A follow-up of https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Fwg-rls-2.2E0/topic/Less.20red.20in.20the.20code
Now diagnostics can apply fixes in a range that's different from the range used to highlight the diagnostics.
Previous logic did not consider the fix range, having both ranges equal, which could cause a lot of red noise in the editor.
Now, the fix range gets used with the fix, the diagnostics range is used for everything else which allows to improve the error highlighting.
before:
<img width="191" alt="image" src="https://user-images.githubusercontent.com/2690773/88590727-df9a6a00-d063-11ea-97ed-9809c1c5e6e6.png">
after:
<img width="222" alt="image" src="https://user-images.githubusercontent.com/2690773/88590734-e1fcc400-d063-11ea-9b7c-25701cbd5352.png">
`MissingFields` and `MissingPatFields` diagnostics now have the fix range as `ast::RecordFieldList` of the expression with an error (as it was before this PR), and the diagnostics range as a `ast::Path` of the expression, if it's present (do you have any example of `ast::Expr::RecordLit` that has no path btw?).
The rest of the diagnostics have both ranges equal, same as it was before this PR.
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
4743: Add tracking of packed repr, use it to highlight unsafe refs r=matklad a=Nashenas88
Taking a reference to a misaligned field on a packed struct is an
unsafe operation. Highlight that behavior. Currently, the misaligned
part isn't tracked, so this highlight is a bit too aggressive.
Fixes#4600
Co-authored-by: Paul Daniel Faria <Nashenas88@users.noreply.github.com>
Co-authored-by: Paul Daniel Faria <nashenas88@users.noreply.github.com>
Co-authored-by: Paul Daniel Faria <paulf@pop-os.localdomain>
5699: Fix clippy warnings r=matklad a=popzxc
Currently clippy spawns a bunch of warnings on the `rust-analyzer` project. Nothing critical, but easy to fix, so I guess it won't harm.
Co-authored-by: Igor Aleksanov <popzxc@yandex.ru>
Without this users have no clue why flycheck fails to run.
This is what is printed to the output channel:
```
[ERROR rust_analyzer::main_loop] cargo check failed: Cargo watcher failed,the command produced no valid metadata (exit code: ExitStatus(ExitStatus(25856)))
```
I stumbled with this figuring out that rust-analyzer adds `--all-features` which is not intended
for some crates in the workspace (e.g. they have mutually-exclusive features.
Having the command rust-analyzer ran should help a lot
Taking a reference to a misaligned field on a packed struct is an
unsafe operation. Highlight that behavior. Currently, the misaligned
part isn't tracked, so this highlight is a bit too aggressive.
5692: Add support for extern crate r=jonas-schievink a=Nashenas88
This adds syntax highlighting, hover and goto def functionality for extern crate.
Fixes#5690
Co-authored-by: Paul Daniel Faria <Nashenas88@users.noreply.github.com>
5693: Fix no inlay hints / unresolved tokens until manual edit to refresh r=jonas-schievink a=Veetaha
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/5349
Now we return ContentModified during the workspace loading. This signifies the language
client to retry the operation (i.e. the client will
continue polling the server while it returns ContentModified).
I believe that there might be cases of overly big projects where the backoff
logic we have setup in `sendRequestWithRetry` (which we use for inlay hints)
might bail too early (currently the largest retry standby time is 10 seconds).
However, I've tried on one of my project with 500+ dependencies and it is still enough.
Here are the examples before/after the change (the gifs are quite lengthy because they show testing rather large cargo workspace).
<details>
<summary>Before</summary>
Here you can see that the client receives empty array of inlay hints and does nothing more.
Same applies to semantic tokens. The client receives unresolved tokens and does nothing more.
The user needs to do a manual edit to refresh the editor.
</details>
<details>
<summary>After</summary>
Here the server returns ContentModified, so the client periodically retries the requests and eventually receives the wellformed response.
</details>
Co-authored-by: Veetaha <veetaha2@gmail.com>
5414: Fix test code lens r=jonas-schievink a=avrong
Closes#5217
The implementation is quite similar to #4821. Maybe we should somehow deal with duplicated code.
Also, both of these requests introduce some unclear behavior. I'm not sure how to process this, therefore asking for advice. Examples are below.
<img width="286" alt="image" src="https://user-images.githubusercontent.com/6342851/87713209-83595f80-c7b2-11ea-8c0f-a12e7571e7df.png">
Co-authored-by: Aleksei Trifonov <avrong@avrong.me>
No we return ContentModified during the workspace loading. This signifies the language
client to retry the operation (i.e. the client will
continue polling the server while it returns ContentModified).
I believe that there might be cases of overly big projects where the backoff
logic we have setup in `sendRequestWithRetry` (which we use for inlay hints)
might bail too early (currently the largest retry standby time is 10 seconds).
However, I've tried on one of my project with 500+ dependencies and it is still enough.
5684: Semantic highlighting for unsafe union field access r=jonas-schievink a=Nashenas88
This change adds support for unions in inference and lowering, then extends on that to add the unsafe semantic modifier on field access only. The `is_possibly_unsafe` function in `syntax_highlighting.rs` could be extended to support fns and static muts so that their definitions are not highlighted as unsafe, but only their usage.
Also, each commit of this PR updates the tests. By reviewing the files by commit, it's easy to see how the changes in the code affected the tests.
Co-authored-by: Paul Daniel Faria <Nashenas88@users.noreply.github.com>
5679: Account for static mut in missing unsafe diagnostic r=jonas-schievink a=Nashenas88
Accessing or modifying a static mut is an unsafe operation. The "missing unsafe" diagnostic now tracks this.
Co-authored-by: Paul Daniel Faria <Nashenas88@users.noreply.github.com>
5678: Static mut unsafe semantic highlighting r=jonas-schievink a=Nashenas88
This marks static mutable names as unsafe, since accessing or modifying a static mut is an unsafe operation.
Co-authored-by: Paul Daniel Faria <Nashenas88@users.noreply.github.com>
