1122: Add explicit type assist. r=matklad a=marcogroppo
This assist can be used to specify the explicit type in let statements. For example `let num = 1;` becomes `let num: i32 = 1;`.
The assist is applicable only if the inferred type is fully known.
Co-authored-by: Marco Groppo <marco.groppo@gmail.com>
1105: [WIP] Implement ra_mbe meta variables support r=matklad a=edwin0cheng
This PR implements the following meta variable support in `ra_mba` crate (issue #720):
- [x] `path`
- [ ] `expr`
- [ ] `ty`
- [ ] `pat`
- [ ] `stmt`
- [ ] `block`
- [ ] `meta`
- [ ] `item`
*Implementation Details*
In the macro expanding lhs phase, if we see a meta variable type, we try to create a `tt:TokenTree` from the remaining input. And then we use a special set of `ra_parser` to parse it to `SyntaxNode`.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
1119: Add warning when open file outside workspace r=matklad a=edwin0cheng
When file is not found in `ra_vfs` but exist, use `LspError` for warning instead of `error_fmt` to bail out error,
Temporarily fix#967 .
edit: typo
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>
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>
1082: Async block in argument position r=matklad a=andreytkachenko
Fixes case when async block appears in argument position
Co-authored-by: Andrey Tkachenko <andreytkachenko64@gmail.com>
1067: Take number of arguments at the call-site into account for signature help r=matklad a=kjeremy
Fixes#1065
Co-authored-by: kjeremy <kjeremy@gmail.com>
1081: Async closure syntax r=matklad a=robojumper
Fixes#1080.
Also fixes an error introduced by #1072 where something like `async move "foo"` in expression position would trigger the assertion in `block_expr`.
Co-authored-by: robojumper <robojumper@gmail.com>
Now bounds inside a path are parsed as DYN_TRAIT_TYPE, previously they would be
parsed as `PATH_TYPE` followed by `TYPE_BOUND_LIST`.
Basically this means `Box<T + 'f>` is now parsed almost the same as
`Box<dyn T + 'f>` with the exception of not having the `dyn` keyword.
These are now used when parsing type bounds. In addition parsing paths inside a
bound now does not recursively parse paths, rather they are treated as separate
bounds, separated by +.
This solves the problem of "macro expansion can't call into name
resolution, because name resolution calls back into macro expansion"
Because we store macro def as a part of call id, macro expansion just
knows the def!
1034: HIR diagnostics API r=matklad a=matklad
This PR introduces diagnostics API for HIR, so we can now start issuing errors and warnings! Here are requirements that this solution aims to fulfill:
* structured diagnostics: rather than immediately rendering error to string, we provide a well-typed blob of data with error-description. These data is used by IDE to provide fixes
* open set diagnostics: there's no single enum with all possible diagnostics, which hopefully should result in better modularity
The `Diagnostic` trait describes "a diagnostic", which can be downcast to a specific diagnostic kind. Diagnostics are expressed in terms of macro-expanded syntax tree: they store pointers to syntax nodes. Diagnostics are self-contained: you don't need any context, besides `db`, to fully understand the meaning of a diagnostic.
Because diagnostics are tied to the source, we can't store them in salsa. So subsystems like type-checking produce subsystem-local diagnostic (which is a closed `enum`), which is expressed in therms of subsystem IR. A separate step converts these proto-diagnostics into `Diagnostic`, by merging them with source-maps.
Note that this PR stresses type-system quite a bit: we now type-check every function in open files to compute errors!
Discussion on Zulip: https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Fwg-rls-2.2E0/topic/Diagnostics.20API
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
