| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Basically, `Iterator` is re-exported via several steps, which happened to not be
resolved yet when we got to the prelude import, but since the name resolved to
the reexport from `core::iter` (just to no actual items), we gave up trying to
resolve it further.
Maybe part of the problem is that we can have
`PartialResolvedImport::Unresolved` or `PartialResolvedImport::Indeterminate`
with `None` in all namespaces, and handle them differently.
Fixes #2683.
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
2742: Split `infer` query into two for better profiling r=flodiebold a=michalt
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]>
Co-authored-by: Michal Terepeta <[email protected]>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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]>
|
|/
|
|
|
|
|
|
| |
The `-` turned into a `+` during a refactoring.
The original issue was caused by `Read` resolving wrongly to a trait without
type parameters instead of a struct with one parameter; this only fixes the
crash, not the wrong resolution.
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
2657: Omit closure parameters in closure type display strings r=flodiebold a=SomeoneToIgnore
Part of https://github.com/rust-analyzer/rust-analyzer/issues/1946
I wonder, should we display the the closure trait (Fn/FnMut/FnOnce) in inlay hints instead of `|...|` at all?
Co-authored-by: Kirill Bulatov <[email protected]>
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
2661: Implement infer await from async function r=flodiebold a=edwin0cheng
This PR is my attempt for trying to add support for infer `.await` expression from an `async` function, by desugaring its return type to `Impl Future<Output=RetType>`.
Note that I don't know it is supposed to desugaring it in that phase, if it is not suitable in current design, just feel free to reject it :)
r=@flodiebold
Co-authored-by: Edwin Cheng <[email protected]>
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
It's not very different, except we can directly use Salsa IDs instead of casting
them. This means we need to refactor the handling of errors to get rid of
UNKNOWN_TRAIT though.
|
| | |
|
|/ |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
2626: Recursive collect macros in impl items r=matklad a=edwin0cheng
Co-authored-by: Edwin Cheng <[email protected]>
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| | |
2625: Clippy lints r=matklad a=kjeremy
Co-authored-by: kjeremy <[email protected]>
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
2624: Separate module item from module scope r=matklad a=matklad
bors r+
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | |
|
|\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
2623: Add support macros in impl blocks r=matklad a=edwin0cheng
This PR add support for macros in impl blocks, which reuse `Expander` for macro expansion.
see also: #2459
Co-authored-by: Edwin Cheng <[email protected]>
|
| |/ |
|
| |
| |
| |
| | |
E.g. `let x: fn(A) -> B = |x| { y };`
|
| | |
|
|/
|
|
| |
Fixes #2547.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
2592: Add std::ops::Index support for infering r=edwin0cheng a=edwin0cheng
see also #2534
Seem like this can't fix #2534 for this case:
```rust
fn foo3(bar: [usize; 2]) {
let baz = bar[1]; // <--- baz is still unknown ?
println!("{}", baz);
}
```
Co-authored-by: Edwin Cheng <[email protected]>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|/ |
|
| |
|
|
|
|
|
|
|
| |
When calling a function, argument-position impl Trait is transparent; same for
return-position impl Trait when inside the function. So in these cases, we need
to represent that type not by `Ty::Opaque`, but by a type variable that can be
unified with whatever flows into there.
|
| |
|
| |
|
| |
|
| |
|