aboutsummaryrefslogtreecommitdiff
path: root/crates/ra_ide/src
Commit message (Collapse)AuthorAgeFilesLines
...
* | Merge #4999bors[bot]2020-06-231-0/+1
|\ \ | | | | | | | | | | | | | | | | | | | | | 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]>
| * | SSR: Allow matching of whole macro callsDavid Lattimore2020-06-221-0/+1
| |/ | | | | | | Matching within macro calls is to come later and matching of macro calls within macro calls later still.
* | Merge #5000bors[bot]2020-06-221-5/+5
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
| * | Remove RelativePathBuf from fixtureAleksey Kladov2020-06-221-5/+5
| |/ | | | | | | | | The paths in fixture are not really relative (the default one is `/main.rs`), so it doesn't make sense to use `RelativePathBuf` here.
* | Merge #4988bors[bot]2020-06-221-0/+3
|\ \ | | | | | | | | | | | | | | | | | | | | | 4988: Don't offer to add missing fields of unknown types r=flodiebold a=lnicola Co-authored-by: LaurenČ›iu Nicola <[email protected]>
| * | Don't offer to add missing fields of unknown typesLaurențiu Nicola2020-06-221-0/+3
| |/
* | Merge #4900bors[bot]2020-06-221-0/+80
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | 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]>
| * Created goto Self enum variant testBGluth2020-06-211-0/+80
| |
* | Merge #4899bors[bot]2020-06-221-72/+206
|\ \ | | | | | | | | | | | | | | | | | | | | | 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]>
| * | don't complete top level attrs inside nested attrs and add better labels #4899Benjamin Coenen2020-06-221-8/+1
| | | | | | | | | | | | Signed-off-by: Benjamin Coenen <[email protected]>
| * | don't complete top level attrs inside nested attrs and add better labels #4899Benjamin Coenen2020-06-211-16/+105
| | | | | | | | | | | | Signed-off-by: Benjamin Coenen <[email protected]>
| * | don't complete top level attrs inside nested attrs and add better labels #4890Benjamin Coenen2020-06-181-16/+8
| | | | | | | | | | | | Signed-off-by: Benjamin Coenen <[email protected]>
| * | don't complete top level attrs inside nested attrs and add better labels #4890Benjamin Coenen2020-06-151-63/+123
| | | | | | | | | | | | Signed-off-by: Benjamin Coenen <[email protected]>
* | | Merge #4921bors[bot]2020-06-222-555/+10
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
| * | | Allow SSR to match type references, items, paths and patternsDavid Lattimore2020-06-222-555/+10
| | |/ | |/| | | | | | | Part of #3186
* | | Merge #4928bors[bot]2020-06-221-48/+139
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | 4928: Fix renaming mod in use tree r=matklad a=unexge Fixes #4825 Co-authored-by: unexge <[email protected]>
| * | Fix renaming mod in use treeunexge2020-06-171-48/+139
| | |
* | | Syntax highlighting for documentation comments on macro definitionsLeander Tentrup2020-06-193-2/+19
| | |
* | | Merge #4851bors[bot]2020-06-191-2/+96
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
| * | | Add quickfix to add a struct fieldTimo Freiberg2020-06-121-2/+96
| | | |
* | | | Merge #4839bors[bot]2020-06-192-22/+1122
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
| * | | | Apply suggestions from code reviewvsrs2020-06-181-2/+253
| | | | |
| * | | | Add Type::walk methodvsrs2020-06-181-4/+21
| | | | |
| * | | | Remove AdtOrTraitvsrs2020-06-182-17/+13
| | | | |
| * | | | Add associated type test.vsrs2020-06-181-0/+57
| | | | |
| * | | | Fix type "items" order.vsrs2020-06-181-17/+18
| | | | |
| * | | | Add `Go to Type Definition` hover action.vsrs2020-06-183-22/+800
| | | | |
* | | | | Merge #4903bors[bot]2020-06-184-41/+55
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
| * | | | | Remove logic to mark all doctest code asPaul Daniel Faria2020-06-182-14/+13
| | | | | |
| * | | | | Ensure all existing doctest code highlights have documentation modifierPaul Daniel Faria2020-06-173-21/+22
| | | | | |
| * | | | | Add highlighting support for doc commentsPaul Daniel Faria2020-06-174-41/+55
| | | | | |
* | | | | | Merge #4821bors[bot]2020-06-182-9/+32
|\ \ \ \ \ \ | |_|/ / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 4821: display Doctest code lens before comment r=matklad a=bnjjj close #4785 Co-authored-by: Benjamin Coenen <[email protected]>
| * | | | | display Doctest code lens before comment #4785Benjamin Coenen2020-06-182-9/+3
| | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Benjamin Coenen <[email protected]>
| * | | | | display Doctest code lens before comment #4785Benjamin Coenen2020-06-141-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Benjamin Coenen <[email protected]>
| * | | | | display Doctest code lens before comment #4785Benjamin Coenen2020-06-092-3/+32
| | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Benjamin Coenen <[email protected]>
* | | | | | Remove special casing for library symbolsAleksey Kladov2020-06-182-6/+11
| |_|_|/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We might as well handle them internally, via queries. I am not sure, but it looks like the current LibraryData setup might even predate salsa? It's not really needed and creates a bunch of complexity.
* | | | | Syntax highlighting for escape sequences in stringsLeander Tentrup2020-06-1710-5/+36
| |/ / / |/| | |
| | | |
| \ \ \
*-. \ \ \ Merge #4913 #4915 #4916bors[bot]2020-06-173-4/+22
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 4913: Remove debugging code for incremental sync r=matklad a=lnicola 4915: Inspect markdown code fences to determine whether to apply syntax highlighting r=matklad a=ltentrup Fixes #4904 4916: Warnings as hint or info r=matklad a=GabbeV Fixes #4229 This PR is my second attempt at providing a solution to the above issue. My last PR(#4721) had to be rolled back(#4862) due to it overriding behavior many users expected. This PR solves a broader problem while trying to minimize surprises for the users. ### Problem description The underlying problem this PR tries to solve is the mismatch between [Rustc lint levels](https://doc.rust-lang.org/rustc/lints/levels.html) and [LSP diagnostic severity](https://microsoft.github.io/language-server-protocol/specification#diagnostic). Rustc currently doesn't have a lint level less severe than warning forcing the user to disable warnings if they think they get to noisy. LSP however provides two severitys below warning, information and hint. This allows editors like VSCode to provide more fine grained control over how prominently to show different diagnostics. Info severity shows a blue squiggly underline in code and can be filtered separately from errors and warnings in the problems panel. ![image](https://user-images.githubusercontent.com/13839236/84830640-0bb8d900-b02a-11ea-9e2f-0561b0e8f1ef.png) ![image](https://user-images.githubusercontent.com/13839236/84826931-ffca1880-b023-11ea-8080-5e5b91a6ac0d.png) Hint severity doesn't show up in the problems panel at all and only show three dots under the affected code or just faded text if the diagnostic also has the unnecessary tag. ![image](https://user-images.githubusercontent.com/13839236/84827165-55062a00-b024-11ea-8bd6-bdbf1217c4c5.png) ### Solution The solution provided by this PR allows the user to configure lists of of warnings to report as info severity and hint severity respectively. I purposefully only convert warnings and not errors as i believe it's a good idea to have the editor show the same severity as the compiler as much as possible. ![image](https://user-images.githubusercontent.com/13839236/84829609-50437500-b028-11ea-80a8-1bbd05680ba7.png) ### Open questions #### Discoverability How do we teach this to new and existing users? Should a section be added to the user manual? If so where and what should it say? #### Defaults Other languages such as TypeScript report unused code as hint by default. Should rust-analyzer similarly report some problems as hint/info by default? Co-authored-by: LaurenČ›iu Nicola <[email protected]> Co-authored-by: Leander Tentrup <[email protected]> Co-authored-by: Gabriel Valfridsson <[email protected]>
| | * | | | Inspect markdown code fences to determine whether to apply syntax highlightingLeander Tentrup2020-06-163-4/+22
| |/ / / /
* / / / / Remove :expr from placeholdersDavid Lattimore2020-06-171-54/+20
|/ / / / | | | | | | | | | | | | Reasoning discussed at #3186
* | | | Anchor file-system operations to the file, and not to the source root.Aleksey Kladov2020-06-162-62/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Anchoring to the SourceRoot wont' work if the path is absolute: #[path = "/tmp/foo.rs"] mod foo; Anchoring to a file will. However, we *should* anchor, instead of just producing an abs path. I can imagine a situation where, for example, rust-analyzer processes crates from different machines (or, for example, from in-memory git branch), where the same absolute path in different crates might refer to different files in the end!
* | | | Syntactic highlighting of NAME_REF for injectionsLeander Tentrup2020-06-1512-16/+102
| |_|/ |/| | | | | | | | | | | | | | This commit adds a function that tries to determine the syntax highlighting class of NAME_REFs based on the usage. It is used for highlighting injections (such as highlighting of doctests) as the semantic logic will most of the time result in unresolved references. It also adds a color to unresolved references in HTML encoding.
* | | Merge #4877bors[bot]2020-06-153-16/+37
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 4877: Fix syntax highlighting of recursive macros r=matklad a=ltentrup Add syntax highlighting for the BANG (`!`) token if the parent is `MACRO_CALL`. Before: <img width="514" alt="before" src="https://user-images.githubusercontent.com/201808/84595030-11f65c00-ae56-11ea-9bb2-b1abe2236990.png"> After: <img width="516" alt="recursive-macro" src="https://user-images.githubusercontent.com/201808/84594981-d196de00-ae55-11ea-8636-f877d5d795ff.png"> Fixes #4694. Co-authored-by: Leander Tentrup <[email protected]>
| * | | Fix syntax highlighting of recursive macrosLeander Tentrup2020-06-153-16/+37
| | | | | | | | | | | | | | | | Add syntax highlighting for the BANG (`!`) token if the parent is `MACRO_CALL`.
* | | | Deprecate hir::Path::from_astAleksey Kladov2020-06-151-0/+1
|/ / /
* | | Merge #4868bors[bot]2020-06-131-4/+4
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 4868: Fix if and while postfix completions r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | | Fix if and while postfix completionsAleksey Kladov2020-06-131-4/+4
| | |/ | |/|
* | | More concise completion testsAleksey Kladov2020-06-132-182/+146
| | |
* | | CleanupAleksey Kladov2020-06-134-255/+154
| | |
* | | Add keywords completions on source file positionMikhail Rakhmanov2020-06-133-21/+124
| | |
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-16 03:45:10 +0000