| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
4940: Add support for marking doctest items as distinct from normal code r=ltentrup a=Nashenas88
This adds `HighlightTag::Generic | HighlightModifier::Injected` as the default highlight for all elements within a doctest. Please feel free to suggest that a new tag be created or a different one used.
![Screenshot from 2020-06-23 09-18-13](https://user-images.githubusercontent.com/1673130/85408493-9752ce00-b532-11ea-94fe-197353ccc778.png)
Fixes #4929
Fixes #4939
Co-authored-by: Paul Daniel Faria <[email protected]>
Co-authored-by: Paul Daniel Faria <[email protected]>
|
| | |
|
| | |
|
| |
| |
| | |
Co-authored-by: Leander Tentrup <[email protected]>
|
| |
| |
| |
| | |
switch to more general new highlight tag, generic
|
| |
| |
| |
| | |
highlighting in doctests
|
| |
| |
| |
| | |
in the html generator
|
| |
| |
| |
| | |
default tag to all doctest elements
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|/ |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
5002: Fix underflow panic when doctests are at top of file r=Nashenas88 a=Nashenas88
While debugging a comment at the top of a test string, I discovered that the offset calculations could underflow and panic. This only seemed to occur in tests, I assume because it's running a debug mode. The wrapping is quickly fixed later on in release mode, which is why this seems to have gone unnoticed. The new checks ensure the value is always positive or zero.
Co-authored-by: Paul Daniel Faria <[email protected]>
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
4999: SSR: Allow matching of whole macro calls r=matklad a=davidlattimore
Matching within macro calls is to come later and matching of macro calls within macro calls later still.
Co-authored-by: David Lattimore <[email protected]>
|
| |/
| |
| |
| | |
Matching within macro calls is to come later and matching of macro calls within macro calls later still.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
5000: Remove RelativePathBuf from fixture r=matklad a=matklad
The paths in fixture are not really relative (the default one is
`/main.rs`), so it doesn't make sense to use `RelativePathBuf` here.
bors r+
🤖
Co-authored-by: Aleksey Kladov <[email protected]>
|
| |/
| |
| |
| |
| | |
The paths in fixture are not really relative (the default one is
`/main.rs`), so it doesn't make sense to use `RelativePathBuf` here.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
4988: Don't offer to add missing fields of unknown types r=flodiebold a=lnicola
Co-authored-by: Laurențiu Nicola <[email protected]>
|
| |/ |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
4900: Self variant enum res fix r=BGluth a=BGluth
Fixes #4789.
This is my first PR for this project, so it's probably worth giving it an extra close look.
A few things that I wasn't sure about:
- Is `resolve_path` really the best place to perform this check? It seemed like a natural place, but perhaps there's a better place?
- When handling the new variant `PathResolution::VariantDef`, I couldn't see an obvious variant of `TypeNs` to return in `in_type_ns` for Unions and Structs.
Co-authored-by: BGluth <[email protected]>
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
4899: don't complete top level attrs inside nested attrs and add better labels r=matklad a=bnjjj
close #4890
Co-authored-by: Benjamin Coenen <[email protected]>
|
| | |
| | |
| | |
| | | |
Signed-off-by: Benjamin Coenen <[email protected]>
|
| | |
| | |
| | |
| | | |
Signed-off-by: Benjamin Coenen <[email protected]>
|
| | |
| | |
| | |
| | | |
Signed-off-by: Benjamin Coenen <[email protected]>
|
| | |
| | |
| | |
| | | |
Signed-off-by: Benjamin Coenen <[email protected]>
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
4921: Allow SSR to match type references, items, paths and patterns r=davidlattimore a=davidlattimore
Part of #3186
Co-authored-by: David Lattimore <[email protected]>
|
| | |/
| |/|
| | |
| | | |
Part of #3186
|
|\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | | |
4928: Fix renaming mod in use tree r=matklad a=unexge
Fixes #4825
Co-authored-by: unexge <[email protected]>
|
| | | |
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
4851: Add quickfix to add a struct field r=TimoFreiberg a=TimoFreiberg
Related to #4563
I created a quickfix for record literals first because the NoSuchField diagnostic was already there.
To offer that quickfix for FieldExprs with unknown fields I'd need to add a new diagnostic (or create a `NoSuchField` diagnostic for those cases)
I think it'd make sense to make this a snippet completion (to select the generated type), but this would require changing the `Analysis` API and I'd like some feedback before I touch that.
Co-authored-by: Timo Freiberg <[email protected]>
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
4839: `Go to Type Definition` hover action. r=matklad a=vsrs
![hover_actions_goto](https://user-images.githubusercontent.com/62505555/83335671-0122e380-a2b7-11ea-9922-fbdcfb11a7f3.gif)
This implementation supports things like `dyn Trait<SomeType>`, `-> impl Trait`, etc.
Co-authored-by: vsrs <[email protected]>
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
4903: Add highlighting support for doc comments r=matklad a=Nashenas88
The language server protocol includes a semantic modifier for documentation. This change exports that modifier for doc comments so users can choose to highlight them differently compared to regular comments.
Example:
<img width="375" alt="Screen Shot 2020-06-16 at 10 34 14 AM" src="https://user-images.githubusercontent.com/1673130/84788271-f6599580-afbc-11ea-96e5-7a0215da620b.png">
CC @woody77
Co-authored-by: Paul Daniel Faria <[email protected]>
|
| | | | | | |
|
| | | | | | |
|