| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Signed-off-by: Benjamin Coenen <[email protected]>
|
| |
|
|
| |
Signed-off-by: Benjamin Coenen <[email protected]>
|
| |
|
|
| |
Signed-off-by: Benjamin Coenen <[email protected]>
|
| |
|
|
|
|
| |
implementation, include sort in Completions struct
Signed-off-by: Benjamin Coenen <[email protected]>
|
| |\
| |
| |
| | |
Signed-off-by: Benjamin Coenen <[email protected]>
|
| |/
|
|
| |
Signed-off-by: Benjamin Coenen <[email protected]>
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Trait items should be public by default.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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]>
|
| | |
| |
| |
| |
| | |
Two uses only needed the crate; one was wrong and should use the module from the
scope instead.
|
| | | |
|
| |/ |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
