| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
This makes the intention of inherent vs. trait impls somewhat more
clear and also fixes (?) an issue where trait impls with an unresolved
trait were added as inherent impls instead (hence the test changes).
|
|
|
|
|
|
|
|
| |
If the first type parameter gets inferred, that's still not handled correctly;
it'll require some more refactoring: E.g. if we have `Thing<T, F=fn() -> T>` and
then instantiate `Thing<_>`, that gets turned into `Thing<_, fn() -> _>` before
the `_` is instantiated into a type variable -- so afterwards, we have two type
variables without any connection to each other.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is working, but I'm not that happy with how the lowering works. We might
need an additional representation between `TypeRef` and `Ty` where names are
resolved and `impl Trait` bounds are separated out, but things like inference
variables don't exist and `impl Trait` is always represented the same
way.
Also note that this doesn't implement correct handling of RPIT *inside* the
function (which involves turning the `impl Trait`s into variables and creating
obligations for them). That intermediate representation might help there as
well.
|
| |
|
| |
|
| |
|
|
|
|
| |
This should fix some of the worst performance problems.
|
|
|
|
|
| |
This speeds up inference in analysis-stats by ~30% (even more with the recursive
solver).
|
| |
|
|
|
|
|
|
|
| |
It improves compile time in `--release` mode quite a bit, it doesn't
really slow things down and, conceptually, it seems closer to what we
want the physical architecture to look like (we don't want to
monomorphise EVERYTHING in a single leaf crate).
|
| |
|
|
|
|
|
| |
This slows down analysis-stats a bit (~5% in my measurement), but improves
incremental checking a lot because we can reuse trait solve results.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
don't belong
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the same change as we did with `crate_def_map` and it does seem
that we mostly spend time in salsa, without recomputing much on
rust-analyzer side.
Example output:
```
233ms - handle_inlay_hints
163ms - get_inlay_hints
163ms - SourceAnalyzer::new
67ms - def_with_body_from_child_node
67ms - analyze_container
67ms - analyze_container
67ms - Module::from_definition
67ms - Module::from_file
67ms - crate_def_map
0ms - parse_macro_query (6 calls)
0ms - raw_items_query (1 calls)
66ms - ???
0ms - crate_def_map (1 calls)
0ms - crate_def_map (1 calls)
96ms - infer
2ms - trait_solve_query (2 calls)
94ms - ???
0ms - body_with_source_map_query (1 calls)
0ms - crate_def_map (1 calls)
[...]
```
Signed-off-by: Michal Terepeta <[email protected]>
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
- impl Trait<Self> for S is allowed
- impl Trait for S<Self> is an invalid cycle, but we can add cycle recovery for
it in Salsa now
|
| |
|
|
|