| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
| |
|
|\
| |
| | |
Fix unnecessary braces warnings
|
| | |
|
|/ |
|
|
|
|
|
| |
Use the trait solver to check if there's an existing implementation of
From<type_in_enum_variant> for the enum.
|
|
|
|
|
|
| |
Basically adds a From impl for tuple enum variants with one field. Added
to cover the fairly common case of implementing your own Error that can
be created from another one, although other use cases exist.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| | |
ra_hir: add more privacy for Type
|
| | |
|
|\ \
| | |
| | | |
Fix rename argument in macro call
|
| | |
| | |
| | | |
Co-Authored-By: Veetaha <[email protected]>
|
| | | |
|
| | | |
|
| |/
|/| |
|
|/ |
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|