aboutsummaryrefslogtreecommitdiff
path: root/LICENSE-MIT
diff options
context:
space:
mode:
authorbors[bot] <26634292+bors[bot]@users.noreply.github.com>2020-03-13 12:05:02 +0000
committerGitHub <[email protected]>2020-03-13 12:05:02 +0000
commit93527b5f193ed214f6ae0f8112eaec2eebabd016 (patch)
treefda6b0e03da9ef7fc7426dbf785bd6c050e845dd /LICENSE-MIT
parent02b44006b8e37a8cd3f96d5b1c949d62e01be2e8 (diff)
parentd6195fa21f09aa3f987e09d847c156e1788ec834 (diff)
Merge #3574
3574: Fix completion of HashMap::new r=matklad a=flodiebold 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.) The `ty` function for fields was used for signature help, so there we want placeholders so that it looks nicer, I think. Hence I renamed it to `signature_ty`. Co-authored-by: Florian Diebold <[email protected]>
Diffstat (limited to 'LICENSE-MIT')
0 files changed, 0 insertions, 0 deletions