aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
| * | | | | Apply the api design suggestionsKirill Bulatov2020-01-1510-59/+97
| | | | | |
| * | | | | Another attempt to add multiple editsKirill Bulatov2020-01-158-28/+97
|/ / / / /
* | | | | Merge #2856bors[bot]2020-01-153-19/+54
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 2856: More orthogonal path editing r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * | | | | More orthogonal path editingAleksey Kladov2020-01-153-19/+54
| | | | | |
* | | | | | Merge #2855bors[bot]2020-01-155-48/+48
|\| | | | | | |/ / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 2855: More fluent API r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * | | | More fluent APIAleksey Kladov2020-01-151-10/+12
| | | | |
| * | | | Slightly more fluent APIAleksey Kladov2020-01-152-14/+14
| | | | |
| * | | | SimplifyAleksey Kladov2020-01-151-5/+8
| | | | |
| * | | | SimplifyAleksey Kladov2020-01-151-7/+5
| | | | |
| * | | | RenameAleksey Kladov2020-01-153-17/+14
|/ / / /
* | | | Merge #2853bors[bot]2020-01-153-68/+97
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 2853: Manage `cargo check` state updates in `main_loop` to reduce lock contention r=matklad a=kiljacken State is now updated exclusively from `main_loop` so several threads theoretically can't compete for the lock. Updates to the state are requested via the existing task channel. Also updates some naming to make slightly more sense. Based upon an idea/suggestion from @matklad on Zulip: > I think I've noticed at leas something suspicious! > > In WorldSnapshot, we store an Arc<RwLock<CheckWatcherSharedState>>. We read lock this lock in handle_diagnostics. > > Additionally, we .write this lock from the watcher thread in CheckWatcherState::run. > > I think in general this is less then ideal, b/c diagnostics request can be blocked on another thread. I think it makes sense to architect this in a way which does not block. > > For that, we stop sharing the state between ServerWorld and CheckWatcherState. Instead, the watcher thread sends new diagnostics via a channel, and we accomodate thouse diagnostics intot he server state in the main loop. > > So, instead of: > ```rust > struct Server { > diagnostics: Arc<Mutex<Vec<Diagnostics>>>, > } > > struct Watcher { > diagnostics: Arc<Mutex<Vec<Diagnostics>>>, > } > ``` > we'll have something like this: > ```rust > struct Server { > // this bit now *owns* diagnostics > diagnostisc: Vec<Diagnostics> > } > > struct Watcher { > diagnostics_sink: Sender<Vec<Diagnostics>>, > } > ``` > I am not sure this is the cuprit of slowness on widnows, but I think we should fix it, because it's very useful when all changes to the server's state can occur only via the main loop. > > Note how VFS is set up in a similar way: instead of modifing some global hash map with files, VFS sends a message to the main looop that hey, I have these new files for you. The main loop than incorporates the changes itself. > > Note that I think we'll still need some locks here, to share the state between ServerWorld and WorldSnapshot, but we won't actually be changing anyting mid-snapshot Co-authored-by: Emil Lauridsen <[email protected]>
| * | | | Extract check task handling into functionEmil Lauridsen2020-01-151-47/+56
| | | | |
| * | | | Tweak naming slightlyEmil Lauridsen2020-01-151-5/+5
| | | | |
| * | | | Manage check state updates in main_loop to reduce lock contentionEmil Lauridsen2020-01-153-44/+64
| | | | |
* | | | | Merge #2854bors[bot]2020-01-152-1/+3
|\ \ \ \ \ | |/ / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 2854: Add logo r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * | | | Extension iconAleksey Kladov2020-01-151-0/+0
| | | | |
| * | | | Add logoAleksey Kladov2020-01-151-1/+3
|/ / / /
* | | | Merge #2852bors[bot]2020-01-152-3/+10
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 2852: Don't parse child modules when doing diagnostics r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * | | | Don't parse child modules when doing diagnosticsAleksey Kladov2020-01-152-3/+10
|/ / / /
* | | | Merge #2851bors[bot]2020-01-153-6/+6
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 2851: lsp-types 0.69.0 r=kjeremy a=kjeremy Stabilizes most proposed features Co-authored-by: Jeremy Kolb <[email protected]>
| * | | | lsp-types 0.69.0Jeremy Kolb2020-01-153-6/+6
|/ / / / | | | | | | | | | | | | Stabilizes most proposed features
* | | | Merge #2850bors[bot]2020-01-153-31/+9
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 2850: Use types from vscode-languageclient r=matklad a=kiljacken Now that we're running with 3.15 of the LSP for VSCode we don't need to define these interfaces ourselves. Yay! Co-authored-by: Emil Lauridsen <[email protected]>
| * | | | Use types from vscode-langaugeclientEmil Lauridsen2020-01-153-31/+9
|/ / / /
* | | | Merge #2843bors[bot]2020-01-156-13/+203
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 2843: Add inlay parameter name hints for call expr r=matklad a=imtsuki This patch adds Intellij-like parameter name hints for literal values in function calls. <img width="624" alt="Screenshot" src="https://user-images.githubusercontent.com/8423594/72366533-68d7f800-3735-11ea-9279-cf193ca8ca2f.png"> Signed-off-by: imtsuki <[email protected]> Co-authored-by: imtsuki <[email protected]>
| * | | | FnSignature: use unwrap_or_default for parameter_name_listimtsuki2020-01-151-5/+3
| | | | | | | | | | | | | | | | | | | | Signed-off-by: imtsuki <[email protected]>
| * | | | Update test snapshotimtsuki2020-01-141-2/+2
| | | | | | | | | | | | | | | | | | | | Signed-off-by: imtsuki <[email protected]>
| * | | | Add inlay parameter name hints for function callsimtsuki2020-01-146-13/+205
| | | | | | | | | | | | | | | | | | | | Signed-off-by: imtsuki <[email protected]>
* | | | | Merge #2849bors[bot]2020-01-151-0/+16
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 2849: Display vscode message after changing cargo-watch options r=edwin0cheng a=memoryruins Currently, changed cargo-watch settings do not go into effect until after a reload. This PR checks for changed `cargoWatchOptions` in the same way as the current `cargoFeatures` check. ![2020-01-14_20-52-20](https://user-images.githubusercontent.com/6868531/72398362-b5f5a300-3710-11ea-9bc1-9943bef08447.gif) Co-authored-by: memoryruins <[email protected]>
| * | | | | Improve readabilitymemoryruins2020-01-151-14/+11
| | | | | |
| * | | | | Display vscode message after changing cargo-watch optionsmemoryruins2020-01-151-0/+19
|/ / / / /
* | | | | Merge #2846bors[bot]2020-01-142-16/+16
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 2846: Language Server Protocol 3.15 is now stable r=kjeremy a=kjeremy Update the client Co-authored-by: kjeremy <[email protected]>
| * | | | | Language Server Protocol 3.15 is now stablekjeremy2020-01-142-16/+16
|/ / / / / | | | | | | | | | | | | | | | Update the client
* | | | | Merge #2845bors[bot]2020-01-141-5/+1
|\ \ \ \ \ | |_|/ / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 2845: Cleanup assert r=kjeremy a=kjeremy Re: https://github.com/rust-analyzer/rust-analyzer/pull/2841#discussion_r366510725 thanks @bjorn3! Co-authored-by: kjeremy <[email protected]>
| * | | | Cleanup assertkjeremy2020-01-141-5/+1
|/ / / /
* | | | Merge #2841bors[bot]2020-01-1426-42/+59
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 2841: More UI friendly labels r=kjeremy a=kjeremy Co-authored-by: Jeremy Kolb <[email protected]>
| * | | | unwrapJeremy Kolb2020-01-141-2/+2
| | | | |
| * | | | Assert that first letter is capitalizedJeremy Kolb2020-01-141-0/+6
| | | | |
| * | | | Fix casingJeremy Kolb2020-01-1421-30/+33
| | | | |
| * | | | More UI friendly labelsJeremy Kolb2020-01-1423-35/+43
| | | | |
* | | | | Merge #2844bors[bot]2020-01-142-85/+15
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 2844: Use dummy value for line! and column! macro r=matklad a=edwin0cheng Use dummy value `0` for line! and column! macro. Co-authored-by: Edwin Cheng <[email protected]>
| * | | | | Use dummy value for line! and column! macroEdwin Cheng2020-01-142-85/+15
| | | | | |
* | | | | | Merge #2834bors[bot]2020-01-141-35/+26
|\ \ \ \ \ \ | |_|/ / / / |/| | | / / | | |_|/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 2834: refactor(ra_syntax.validation): removed code duplication from validate_literal() r=kiljacken a=Veetaha Hi! This is my first ever contribution to this project. I've taken some dirty job from issue #223 This is a simple atomic PR to remove code duplication according to FIXME comment in the function that is the main focus of the further development. I just didn't want to mix refactoring with the implementation of new features... I am not sure whether you prefer such atomic PRs here or you'd rather have a single PR that contains all atomic commits inside of it? So if you want me to add all that validation in one PR I'll mark this one as WIP and update it when the work is finished, otherwise, I'll go with the option of creating separate PRs per each feature of validation of strings, numbers, and comments respectively. ### Comments about refactoring Yeah, reducing the duplication is quite hard here, extracting into stateless functions could be another option but the number of their arguments would be very big and repeated across char and string implementations so that just writing their types and names would become cumbersome. I tried the option of having everything captured implicitly in the closure but failed since rust doesn't have templated (or generic) closures as C++ does, this is needed because `unescape_byte*()` and `unescape_char|str()` have different return types... Maybe I am missing something here? I may be wrong because I am not enough experienced in Rust... Well, I am awaiting any kind of feedback! Co-authored-by: Veetaha <[email protected]>
| * | | | refactor(ra_syntax.validation): removed code duplication from ↵Veetaha2020-01-141-35/+26
| | |/ / | |/| | | | | | | | | | validate_literal() function
* | | | Merge #2839bors[bot]2020-01-142-1/+5
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 2839: Tweak add_custom_impl r=matklad a=kjeremy Display a nicer label and categorize Co-authored-by: Jeremy Kolb <[email protected]>
| * | | | Tweak add_custom_implJeremy Kolb2020-01-142-1/+5
| | | | |
* | | | | Merge #2838bors[bot]2020-01-147-112/+192
|\ \ \ \ \ | |/ / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 2838: Move Type API to type r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * | | | Move Type API to typeAleksey Kladov2020-01-144-85/+102
| | | | |
| * | | | Push resolver further upAleksey Kladov2020-01-144-27/+60
| | | | |
| * | | | Push resolver upAleksey Kladov2020-01-141-21/+51
|/ / / /
| | | |
| \ \ \
*-. \ \ \ Merge #2828 #2831bors[bot]2020-01-143-19/+19
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 2828: Update backtrace r=matklad a=kjeremy Has some fixes for WinXP 2831: vscode-languageclient 6.0.0-next.10 r=matklad a=kjeremy The main change is that it removes progress from the proposed section. Co-authored-by: kjeremy <[email protected]>