aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
| * | | | | | | Let shutdown request to pass through when status == LoadingVeetaha2020-08-091-1/+1
| | | | | | | |
| * | | | | | | Fix no inlay hints / unresolved tokens until manual editVeetaha2020-08-082-3/+13
| |/ / / / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | | | | | Merge #5414bors[bot]2020-08-091-1/+1
|\ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]>
| * | | | | | | Fix test code lensAleksei Trifonov2020-08-021-1/+1
| | | | | | | |
* | | | | | | | Merge #5694bors[bot]2020-08-092-1/+33
|\ \ \ \ \ \ \ \ | |_|_|_|_|_|_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 5694: Format docs in to_proto::markup_content r=jonas-schievink a=JmPotato Signed-off-by: JmPotato <[email protected]> Close #5442 Removing # was handled in rust_analyzer::markdown::format_docs(). However, this function is no longer called in rust_analyzer::handlers::handle_hover() since commit e8bb153 (PR #5273). This pr add this formatting function back. Co-authored-by: JmPotato <[email protected]>
| * | | | | | | format in to_proto::markup_contentJmPotato2020-08-092-1/+33
|/ / / / / / / | | | | | | | | | | | | | | | | | | | | | Signed-off-by: JmPotato <[email protected]>
* | | | | | | Merge #5684bors[bot]2020-08-086-20/+122
|\ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]>
| * | | | | | | Apply unsafe semantic highlighting to union field accessPaul Daniel Faria2020-08-082-13/+59
| | | | | | | |
| * | | | | | | Add support for unions in inference and loweringPaul Daniel Faria2020-08-084-11/+17
| | | | | | | |
| * | | | | | | Add additional checks for union inference testsPaul Daniel Faria2020-08-081-5/+33
| | | | | | | |
| * | | | | | | Add test for unsafe union field access highlightingPaul Daniel Faria2020-08-072-0/+22
| | |_|_|_|/ / | |/| | | | |
* | | | | | | Merge #5689bors[bot]2020-08-081-1/+1
|\ \ \ \ \ \ \ | |_|_|/ / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 5689: Remove clone r=kjeremy a=Veetaha Co-authored-by: Veetaha <[email protected]>
| * | | | | | Remove cloneVeetaha2020-08-081-1/+1
|/ / / / / /
* | | | | | Merge #5686bors[bot]2020-08-081-1/+1
|\ \ \ \ \ \ | |_|_|_|/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 5686: Fix typo in settings description r=kjeremy a=rherrmann Remove a duplicate word from the description of the `warningsAsHint` setting. Co-authored-by: Rüdiger Herrmann <[email protected]>
| * | | | | Fix typo in settings descriptionRüdiger Herrmann2020-08-081-1/+1
|/ / / / / | | | | | | | | | | Remove a duplicate word from the description of the `warningsAsHint` setting.
* | | | | Merge #5679bors[bot]2020-08-071-3/+35
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]>
| * | | | | Account for static mut in missing unsafe diagnosticPaul Daniel Faria2020-08-071-3/+35
| |/ / / /
* | | | | Merge #5678bors[bot]2020-08-074-2/+17
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]>
| * | | | | Mark static mutable names as unsafePaul Daniel Faria2020-08-073-4/+5
| | | | | |
| * | | | | Add test for accessing static mutPaul Daniel Faria2020-08-072-0/+14
| |/ / / /
* | | | | Merge #5674bors[bot]2020-08-072-11/+11
|\ \ \ \ \ | |/ / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 5674: Update chalk r=matklad a=kjeremy Co-authored-by: Jeremy Kolb <[email protected]>
| * | | | Update chalkJeremy Kolb2020-08-062-11/+11
| | | | |
* | | | | Merge #5526bors[bot]2020-08-067-14/+208
|\ \ \ \ \ | |/ / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 5526: Handle semantic token deltas r=kjeremy a=kjeremy This basically takes the naive approach where we always compute the tokens but save space sending over the wire which apparently solves some GC problems with vscode. This is waiting for https://github.com/gluon-lang/lsp-types/pull/174 to be merged. I am also unsure of the best way to stash the tokens into `DocumentData` in a safe manner. Co-authored-by: kjeremy <[email protected]> Co-authored-by: Jeremy Kolb <[email protected]>
| * | | | Address PR commentsJeremy Kolb2020-08-064-18/+12
| | | | |
| * | | | Handle semantic token deltaskjeremy2020-08-017-13/+213
| | | | |
* | | | | Merge #5672bors[bot]2020-08-0512-28/+29
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 5672: align names in make r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | | | | align names in makeAleksey Kladov2020-08-0512-28/+29
| | | | | |
* | | | | | Merge #5639bors[bot]2020-08-054-6/+68
|\ \ \ \ \ \ | |/ / / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 5639: SSR: Allow `self` in patterns. r=jonas-schievink a=davidlattimore It's now consistent with other variables in that if the pattern references self, only the `self` in scope where the rule is invoked will be accepted. Since `self` doesn't work the same as other paths, this is implemented by restricting the search to just the current function. Prior to this change (since path resolution was implemented), having self in a pattern would just result in no matches. Co-authored-by: David Lattimore <[email protected]>
| * | | | | Use SyntaxNode.ancestors instead of a loopDavid Lattimore2020-08-051-7/+1
| | | | | |
| * | | | | SSR: Allow `self` in patterns.David Lattimore2020-08-014-6/+74
| | |_|/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's now consistent with other variables in that if the pattern references self, only the `self` in scope where the rule is invoked will be accepted. Since `self` doesn't work the same as other paths, this is implemented by restricting the search to just the current function. Prior to this change (since path resolution was implemented), having self in a pattern would just result in no matches.
* | | | | Merge #5648bors[bot]2020-08-055-1/+425
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 5648: Add expand glob import assist r=jonas-schievink a=unexge closes https://github.com/rust-analyzer/rust-analyzer/issues/5557 Co-authored-by: unexge <[email protected]>
| * | | | | Pattern match on slice elements instead of using `.first().unwrap()`unexge2020-08-051-7/+6
| | | | | |
| * | | | | Look for trait methods in expand glob import assistunexge2020-08-051-13/+65
| | | | | |
| * | | | | Simplify `find_mod_path` with use of `node.ancestors`unexge2020-08-031-20/+1
| | | | | |
| * | | | | Generate doctestunexge2020-08-022-1/+28
| | | | | |
| * | | | | Rename ast::UseItem to ast::Useunexge2020-08-021-1/+1
| | | | | |
| * | | | | Add expand glob import assistunexge2020-08-024-1/+366
| | | | | |
* | | | | | Merge #5664bors[bot]2020-08-053-4/+29
|\ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 5664: Fix renamed self module. r=jonas-schievink a=Nashenas88 Fixes #5663 Now `inner_mod` below is properly marked as a `module`. ```rust use crate::inner::{self as inner_mod}; mod inner {} ``` Co-authored-by: Paul Daniel Faria <[email protected]>
| * | | | | | When resolving a rename, fallback to the name higher in the use tree if the ↵Paul Daniel Faria2020-08-042-4/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | path segment is `self`
| * | | | | | Add test showing unresolved module renamePaul Daniel Faria2020-08-042-1/+7
| | | | | | |
* | | | | | | Merge #5669bors[bot]2020-08-051-0/+31
|\ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 5669: Document release process r=jonas-schievink a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * | | | | | | Update docs/dev/README.mdAleksey Kladov2020-08-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Co-authored-by: Laurențiu Nicola <[email protected]>
| * | | | | | | Document release processAleksey Kladov2020-08-051-0/+31
| | | | | | | |
* | | | | | | | Merge #5494bors[bot]2020-08-054-20/+35
|\ \ \ \ \ \ \ \ | |/ / / / / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 5494: Use salsa's purge to account for all memory r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * | | | | | | Use salsa's purge to account for all memoryAleksey Kladov2020-08-054-20/+35
|/ / / / / / /
* | | | | | | Merge #5668bors[bot]2020-08-051-5/+0
|\ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 5668: Fix relative path handling for custom rustfmt r=matklad a=matklad `current_dir` and relative paths to executables works differently on unix and windows (unix behavior does not make sense), see: https://github.com/oconnor663/duct.rs/blob/17e30e83a16b202551df4d70d0b2cc174cb53e5d/src/lib.rs#L295-L324 The original motivation to set cwd was to make rustfmt read the correct rustfmt.toml, but that was future proofing, rather than a bug fix. So, let's just remove this and see if breaks or fixes more use-cases. If support for per-file config is needed, we could use `--config-path` flag. bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | | | | | | Fix relative path handling for custom rustfmtAleksey Kladov2020-08-051-5/+0
|/ / / / / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `current_dir` and relative paths to executables works differently on unix and windows (unix behavior does not make sense), see: https://github.com/oconnor663/duct.rs/blob/17e30e83a16b202551df4d70d0b2cc174cb53e5d/src/lib.rs#L295-L324 The original motivation to set cwd was to make rustfmt read the correct rustfmt.toml, but that was future proofing, rather than a bug fix. So, let's just remove this and see if breaks or fixes more use-cases. If support for per-file config is needed, we could use `--config-path` flag.
* | | | | | | Merge #5658bors[bot]2020-08-042-1/+44
|\ \ \ \ \ \ \ | |/ / / / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 5658: do not add to `pub use` in assists that insert a use statement r=jonas-schievink a=jbr closes #5657 , see issue for rationale Initially I wrote a version of this that changed the signature of `insert_use_statement` to take an `Option<VisibilityKind>` and only add to use statements with the same visibility, but that didn't make sense for any of the current uses of `insert_use_statement` (they all expected private visibility). Co-authored-by: Jacob Rothstein <[email protected]>
| * | | | | | do not add to `pub use` statementsJacob Rothstein2020-08-032-1/+44
| | | | | | |
* | | | | | | Merge #5659bors[bot]2020-08-042-31/+23
|\ \ \ \ \ \ \ | |/ / / / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 5659: Revert LineIndex optimizations to fix #5656 r=matklad a=lazear This PR reverts the changes from https://github.com/rust-analyzer/rust-analyzer/pull/5532, which was causing issues as described in https://github.com/rust-analyzer/rust-analyzer/issues/5656 Co-authored-by: Michael Lazear <[email protected]>