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>
