| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |
|
| | |
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
This crate will hold everything to small to be worth publishing
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
3694: Complete only missing fields r=matklad a=SomeoneToIgnore
Co-authored-by: Kirill Bulatov <[email protected]>
|
| |
| |
| |
| | |
Co-Authored-By: Aleksey Kladov <[email protected]>
|
| | |
|
|/ |
|
|
|
|
|
| |
- Add test for @ matching
- Address comments
|
|
|
|
|
|
|
| |
- Exclude const, static, functions form is_pat_binding_and_path
(there might be more?)
- Add a check to filter out Record Fields
- Fix tests
|
|
|
|
|
| |
- Exclude BindPats with @ or ref
- Remove outdated test and add one testing for ref
|
|
|
|
|
|
|
|
| |
Iterate through TupleStructPat's until a MatchArm if
one exists. Store in a new is_pat_bind_and_path bool
and allow the `complete_scope` to find matches.
Added some tests to ensure it works in simple and nested cases.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Trait items should be public by default.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `ty` function in code_model returned the type with placeholders for type
parameters. That's nice for printing, but not good for completion, because
placeholders won't unify with anything else: So the type we got for `HashMap`
was `HashMap<K, V, T>`, which doesn't unify with `HashMap<?, ?, RandomState>`,
so the `new` method wasn't shown.
Now we instead return `HashMap<{unknown}, {unknown}, {unknown}>`, which does
unify with the impl type. Maybe we should just expose this properly as variables
though, i.e. we'd return something like `exists<type, type, type> HashMap<?0,
?1, ?2>` (in Chalk notation). It'll make the API more complicated, but harder to
misuse. (And it would handle cases like `type TypeAlias<T> = HashMap<T, T>` more
correctly.)
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
3553: Completions do not show for function with same name as mod r=matklad a=JoshMcguigan
fixes #3444
I've added a test case in `crates/ra_ide/src/completion/complete_path.rs` which verifies the described behavior in #3444. Digging in, I found that [the module scope iterator](https://github.com/JoshMcguigan/rust-analyzer/blob/ba62d8bd1ce8a68b8d21aaf89ae1ea6787f18366/crates/ra_ide/src/completion/complete_path.rs#L22) only provides the module `z`, and does not provide the function `z` (although if I name the function something else then it does show up here).
I thought perhaps the name wasn't being properly resolved, but I added a test in `crates/ra_hir_def/src/nameres/tests.rs` which seems to suggest that it is? I've tried to figure out how to bridge the gap between these two tests (one passing, one failing) to see where the function `z` is being dropped, but to this point I haven't been able to track it down.
Any pointers on where I might look for this?
Co-authored-by: Josh Mcguigan <[email protected]>
|
| | |
|
| | |
|
|/ |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To test whether the receiver type matches for the impl, we unify the given self
type (in this case `HashSet<{unknown}>`) with the self type of the
impl (`HashSet<?0>`), but if the given self type contains Unknowns, they won't
be unified with the variables in those places. So we got a receiver type that
was different from the expected one, and concluded the impl doesn't match.
The fix is slightly hacky; if after the unification, our variables are still
there, we make them fall back to Unknown. This does make some sense though,
since we don't want to 'leak' the variables.
Fixes #3547.
|
| |
|
| |
|
|\
| |
| | |
Next steps in assoc item completion #3183
|
| |
| |
| |
| | |
Blacklists are prone to more errors
|
| |
| |
| |
| | |
- Add test to ensure nested completions don't happen
|