| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
6834: Use Attrs::docs in runnables instead of DocCommentsOwner r=kjeremy a=Veykril
I figured that we should probably move as much of the doc usage to the HIR as possible hence this PR. If we should keep this AST-based feel free to close.
This change does have the nice(but not really useful as I doubt anyones gonna write doc tests like these) side effect that these two doc string snippets allow being run now.
Co-authored-by: Lukas Wirth <[email protected]>
|
| | | |
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
6769: Add native "remove this semicolon" diagnostics r=matklad a=ivan770
Closes #6739
Co-authored-by: ivan770 <[email protected]>
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
They allow to represent paths like `#[path = "C:\path.rs"] mod foo;`
in a lossless cross-platform & network-transparent way.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
6771: Properly attach inner attributes in Attrs::new r=matklad a=Veykril
Properly attach inner and outer attributes to the things they actually belong to in the HIR. ~~I can add some tests for this if wanted once I know where to put them/how to test for this.~~ Put some tests into `hover.rs`.
So the following snippet
```rust
mod foo {
//! Hello
}
```
now shows `Hello` on hover 🎉
Fixes #2148
Co-authored-by: Lukas Wirth <[email protected]>
|
| | |/ |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
6775: Fix MissingFields DiagnosticFix trigger range r=lnicola a=Veykril
Fixes #5950
Co-authored-by: Lukas Wirth <[email protected]>
|
| | |/ |
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
6750: Remove documentation query, move doc handling to attributes r=matklad a=Veykril
Fixes #3182
Removes the documentation query in favor of `Attrs::docs`. Attrs already handlded doc comments partially but the alloc saving check was wrong so it only worked when other attributes existed as well. Unfortunately the `new` constructor has to do an intermediate allocation now because we need to keep the order of mixed doc attributes and doc comments.
I've also partially adjusted the `hover` module to have its tests check the changes, it still has some `HasSource` trait usage due to the `ShortLabel` trait usage, as that is only implemented on the Ast parts and not the Hir, should this ideally be implemented for the Hir types as well?(would be a follow up PR of course)
Co-authored-by: Lukas Wirth <[email protected]>
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| |
| | |
6719: Use items can also have doc comments r=matklad a=Veykril
Prior to this change modules show more docs than they have cause they inherit the docs from documented use items inside of them.
Co-authored-by: Lukas Wirth <[email protected]>
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
6721: Use METHOD semantic token type r=kjeremy a=lnicola
Closes #6685
Co-authored-by: Laurențiu Nicola <[email protected]>
|
| | |/ |
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| |
| | |
6673: Show type of Self on hover r=matklad a=Veykril
Co-authored-by: Lukas Wirth <[email protected]>
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
6665: Support self in reference search r=matklad a=Veykril
The approach here is simply checking the descendants of the function body for `PathExpr` then checking whether it only contains a single `self` `PathSegment`, this is to prevent us from picking up `self` tokens from local `UseTree`s.
Co-authored-by: Lukas Wirth <[email protected]>
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
6599: Add attribute highlight modifier to all tokens inside attributes r=matklad a=Veykril
This has the side effect that we also emit `attribute.attribute` highlights now, as in, the tokens that get the attribute semantic type also get the attribute modifier. I personally don't think it's really a problem but maybe it is to some? It's just that it was really simple to implement it this way, which is why I just went this route for now.
Fixes #6536
Co-authored-by: Lukas Wirth <[email protected]>
|
| | | | | |
|
| | | | | |
|
| | |_|/
|/| | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
6666: Support 'go to definition' for self r=jonas-schievink a=Veykril
Also reverts #6660, instead of showing the type it now works like it does for names by returning the declaration we are already on. This for example enables VSCode to show all references(#6665) when executing `go to definition` on the declaration.
Co-authored-by: Lukas Wirth <[email protected]>
|
| | | |/
| |/| |
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | | |
6664: Show type of self param on hover r=jonas-schievink a=Veykril
Show the type of `self` when hovering the token in a `SelfParam`.
Co-authored-by: Lukas Wirth <[email protected]>
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
6660: Support "go to definition" for SelfParams r=jonas-schievink a=Veykril
Fixes #6657
Co-authored-by: Lukas Wirth <[email protected]>
|
| | |/ / |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
6645: Publish diagnostics for macro expansion errors r=matklad a=jonas-schievink
This adds 2 new diagnostics, emitted during name resolution:
* `unresolved-proc-macro`, a weak warning that is emitted when a proc macro is supposed to be expanded, but was not provided by the build system. This usually means that proc macro support is turned off, but may also indicate setup issues when using rust-project.json. Being a weak warning, this should help set expectations when users see it, while not being too obstructive. We do not yet emit this for attribute macros though, just custom derives and `!` macros.
* `macro-error`, which is emitted when any macro (procedural or `macro_rules!`) fails to expand due to some error. This is an error-level diagnostic, but currently still marked as experimental, because there might be spurious errors and this hasn't been tested too well.
This does not yet emit diagnostics when expansion in item bodies fails, just for module-level macros.
Known bug: The "proc macro not found" diagnostic points at the whole item for custom derives, it should just point at the macro's name in the `#[derive]` list, but I haven't found an easy way to do that.
Screenshots:
Co-authored-by: Jonas Schievink <[email protected]>
|
| | | | | |
|
| | |/ / |
|
