| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.)
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| | |
3519: Show mod path on hover r=matklad a=SomeoneToIgnore
Closes #1064
Co-authored-by: Kirill Bulatov <[email protected]>
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
3513: Completion in macros r=matklad a=flodiebold
I experimented a bit with completion in macros. It's kind of working, but there are a lot of rough edges.
- I'm trying to expand the macro call with the inserted fake token. This requires some hacky additions on the HIR level to be able to do "hypothetical" expansions. There should probably be a nicer API for this, if we want to do it this way. I'm not sure whether it's worth it, because we still can't do a lot if the original macro call didn't expand in nearly the same way. E.g. if we have something like `println!("", x<|>)` the expansions will look the same and everything is fine; but in that case we could maybe have achieved the same result in a simpler way. If we have something like `m!(<|>)` where `m!()` doesn't even expand or expands to something very different, we don't really know what to do anyway.
- Relatedly, there are a lot of cases where this doesn't work because either the original call or the hypothetical call doesn't expand. E.g. if we have `m!(x.<|>)` the original token tree doesn't parse as an expression; if we have `m!(match x { <|> })` the hypothetical token tree doesn't parse. It would be nice if we could have better error recovery in these cases.
Co-authored-by: Florian Diebold <[email protected]>
|
| | | | |
|
| | |/ |
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| |
|
|
|
| |
This slows down analysis-stats a bit (~5% in my measurement), but improves
incremental checking a lot because we can reuse trait solve results.
|
| |
|
|
| |
cc #2236
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Callers can now decide for themselves if they should prefer field or
local definition. By default, it's the local.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
3367: Fix highlighting of const patterns r=matklad a=matklad
bors r+
🤖
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This introduces the new type -- Semantics.
Semantics maps SyntaxNodes to various semantic info, such as type,
name resolution or macro expansions.
To do so, Semantics maintains a HashMap which maps every node it saw
to the file from which the node originated. This is enough to get all
the necessary hir bits just from syntax.
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
3169: Show record field names in Enum completion r=flodiebold a=adamrk
Adresses https://github.com/rust-analyzer/rust-analyzer/issues/2947.
Previously the details shown when autocompleting an Enum variant would look like the variant was a tuple even if it was a record:
This change will show the names of the fields for a record and use curly braces instead of parentheses:
This required exposing the type `adt::StructKind` from `ra_hir` and adding a function
```
kind(self, db: &impl HirDatabase) -> StructKind
```
in the `impl` of `EnumVariant`.
There was also a previously existing function `is_unit(self, db: &impl HirDatabase) -> bool` for `EnumVariant` which I removed because it seemed redundant after adding `kind`.
Co-authored-by: adamrk <[email protected]>
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| | |
|
