1112: Fix literal support in token tree to ast item list r=matklad a=edwin0cheng
This PR implements following things :
1. Expose `next_token` from `ra_parse`
2. Fix the literal conversion in `token_tree_to_ast_item_list`
3. Add test for the conversion
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
1111: Add multi-byte token support in token tree to ast item list r=matklad a=edwin0cheng
As discusion in https://github.com/rust-analyzer/rust-analyzer/pull/1105 , this PR add implement all multi-byte tokens in `ra_mbe` crate.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
1101: Parse unsafe async / const unsafe fns properly r=matklad a=robojumper
Also adds tests that `unsafe async fn` as well as `const unsafe fn` parse properly and that these keywords in the reversed order cause parse errors.
[Playground link to verify that this is the correct order.](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=7850b8d92579de31c38f835f76afa4ce)
Closes#1086.
Co-authored-by: robojumper <robojumper@gmail.com>
1068: profiling crate first draft r=matklad a=pasa
I've made this first draft for #961
Could you look at it? Is this something what you are looking for?
It has lack of tests. I can't figure out how to test stderr output in rust right now. Do you have some clues?
Additionally I'm thinking about to implement procedural macros to annotate methods with this profiler. Will it be helpful?
Co-authored-by: Sergey Parilin <sergey.parilin@fxdd.com>
1097: Fix VSCode cargo-watch functionality on Linux. r=matklad a=kiljacken
As of #1079 the VSCode cargo-watch functionality has been broken on
Linux systems.
The cause seems to be that linux takes the added quotes inside process
arguments literally, so it attempts to make cargo-watch run the command
`cargo "check --message-format json"` with the entire quoted part being
treated as a single long subcommand, which cargo doesn't know how to
handle.
Removing the extra quotes solves the issue.
Closes#1096
Co-authored-by: Emil Lauridsen <mine809@gmail.com>
As tested by @edwin0cheng, Windows requires the quotes removed in the
previous commit. This commit re-adds the quotes gated by an if statement
on the node environment, so that quotes are only added on Windows.
As of #1079 the VSCode cargo-watch functionality has been broken on
Linux systems.
The cause seems to be that linux takes the added quotes inside process
arguments literally, so it attempts to make cargo-watch run the command
`cargo "check --message-format json"` with the entire quoted part being
treated as a single long subcommand, which cargo doesn't know how to
handle.
Removing the extra quotes solves the issue.
1076: Const body inference r=flodiebold a=Lapz
This is the second part of #887. I've added type inference on const bodies and introduced the DefWithBody containing Function, Const and Static. I want to add tests but im unsure on how I would go about testing that completions work.
Co-authored-by: Lenard Pratt <l3np27@gmail.com>
1094: Improve cargo-watch animation and refactoring r=matklad a=edwin0cheng
* Refactoring code and fixed some minor bugs.
* Add more error log and better error handling.
* Add current checking artifact name in Cargo-watch animation.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
1079: Improve cargo-watch usage in vscode plugin r=matklad a=edwin0cheng
*This PR try to improve current cargo-watch usage in VSCode :*
1. Add Multi-lines error support :
2. Add cargo-watch status animation :
*Implementation Details*
* Current VSCode `ProblemMatcher` still do not support multiple line parsing.
* However we can, spawn a cargo watch process instead of using vscode.Task to allow more control.
* Use `cargo-check --message-format json` to get json format of compiler-message.
* Use `vscode.DiagnosticCollection` to manage the problems directly, which allow multiple lines diagnostic.
However,
* VSCode use non mono-space font for problems, at this moment i cannot find a good solution about it.
* I am not so good in typescript, please let me know if anything is bad in this PR.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
Co-authored-by: Edwin Cheng <edwin@m-inverse.com>
