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>
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>
1031: Move most things out of ra_ide_api_light r=matklad a=detrumi
This moves everything except `structure` out of `ra_ide_api_light`. So this PR and #1019 finish up #1009, whichever is merged last should probably remove the `ra_ide_api_light` crate.
Also, `LocalEdit` was removed since it wasn't used any more.
Co-authored-by: Wilco Kusee <wilcokusee@gmail.com>
1021: Wasm dependencies r=matklad a=detrumi
As a first step towards running RA on WASM (see #1007), this tweaks the dependencies somewhat so that projects built using `wasm-pack` can use `ra_ide_api` as a dependency.
There were two problems:
- use of undeclared type or module `MmapInner`
This error occurred because of the `memmap` crate, as a dependency of `fst`
Solution: specify `default-features = false` for the `fst` package (see https://github.com/BurntSushi/fst/issues/70)
- use of undeclared type or module `imp`
This happened in the `wait-timeout` crate ([which uses `Command` under the hood](https://github.com/alexcrichton/wait-timeout/issues/18)), a dependency of `rusty-fork` which is a dependency of `proptest`.
Solution: move `proptest` to dev-dependencies and add `#[cfg(test)]` to the `test_utils` crate.
**Edit:** Oh, that causes trouble with resolving the import when running the tests. Hmm...
Co-authored-by: Wilco Kusee <wilcokusee@gmail.com>
We simply remove all the CUSTOM_MARKERS before attempting to parse the file.
This allows for the syntax selection to work with most of the test strings.
This allows us to select a string or portions of it and try parsing it as rust
syntax. This is mostly helpful when developing tests where the test
itself contains some rust syntax as a string.
908: Enable markup for hover on expressions which resolve using type_of r=matklad a=vipentti
This adds highlighting when hovering over items which are resolved using
`type_of`.
This adds basic highlighting, discussed in #904.
Co-authored-by: Ville Penttinen <villem.penttinen@gmail.com>
This contains the syntax range of the name itself, allowing NavigationTarget to
properly set the focus_range. This should make it so that when using symbol
based navigation, we should always focus on the name, instead of the full range.
866: Implement basic support for Associated Methods r=flodiebold a=vipentti
This is my attempt at learning to understand how the type inference works by adding basic support for associated methods. Currently it does not resolve associated types or constants.
The basic idea is that `Resolver::resolve_path` returns a new `PathResult` type, which has two variants, `FullyResolved` and `PartiallyResolved`, fully resolved matches the previous behavior, where as `PartiallyResolved` contains the `PerNs<Resolution` in addition to a `segment_index` which contains the index of the segment which we failed to resolve. This index can then be used to continue inference in `infer_path_expr` using the `Type` we managed to resolve.
This changes some of the previous apis, so looking for feedback and suggestions.
This should enable fixing #832
Co-authored-by: Ville Penttinen <villem.penttinen@gmail.com>
This also adds new pub(crate) resolve_path_segments which returns the
PathResult, which may or may not be fully resolved. PathResult is also now
pub(crate) since it is an implementation detail.
864: Fix handling of generics in tuple variants and refactor a bit r=matklad a=flodiebold
(The problem was that we created separate substitutions for the return value, so we lost the connection between the type arguments in the constructor call and the type arguments of the result.)
Also make them display a tiny bit nicer.
Fixes#860.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
Co-authored-by: Florian Diebold <florian.diebold@freiheit.com>
This is done in `infer_path_expr`. When `Resolver::resolve_path` returns
`PartiallyResolved`, we use the returned `Resolution` together with the given
`segment_index` to check if we can find something matching the segment at
segment_index in the impls for that particular type.
