| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
1052: Flip binary expression assist r=matklad a=marcogroppo
Adds an assist that can flip these binary comparison operators: `==`, `!=`, `>`, `>=`, `<`, `<=`.
This is a small extension to the 'flip ==' assist.
In theory we could easily flip ANY binary expression, but I'm not sure it would be a good idea (IMHO we should try not to change the meaning of the expression).
Does it make sense?
Co-authored-by: Marco Groppo <[email protected]>
|
| | |
|
| |\
| |/
|/|
| | |
flip-binexpr
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1060: more realistic test for incrementality r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/ / |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1059: Typed ids r=matklad a=matklad
just some type-safety and refactorings.
closes https://github.com/rust-analyzer/rust-analyzer/issues/1054
bors r+
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
|\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | | |
1051: Move ra_ide_api unit tests r=matklad a=detrumi
Closes #1048
Co-authored-by: Wilco Kusee <[email protected]>
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
1058: remove some dead code r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/ / / |
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
1057: simplify r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | | |
|
|/ / / |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
1055: store macro def inside macro id r=matklad a=matklad
This makes macro expansion resilient to changes to code inside the macro
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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!
|
|\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | | |
1056: :arrow_up: vfs r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/ / / |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
1040: Trait beginnings r=matklad a=flodiebold
This adds some very simple trait method resolution, going through traits in scope, looking for methods of the given name, and checking very naively whether there's an impl for the given type and trait.
Co-authored-by: Florian Diebold <[email protected]>
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
... to make the infer_trait_method_simple test have the correct result.
|
|/ / / |
|
|\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | | |
1049: Add description & example for inlining local variable r=matklad a=gfreezy
Co-authored-by: gfreezy <[email protected]>
|
| | | |
|
|/ / |
|
|/
|
|
| |
This assist can flip the following operators: ==, !=, >, >=, <, <=.
|
|\
| |
| |
| |
| |
| |
| |
| | |
1037: inline immutable local varialbe r=matklad a=gfreezy
resolved #1033
Co-authored-by: gfreezy <[email protected]>
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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 <[email protected]>
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|