3526: Silence "file out of workspace" errors r=matklad a=matklad
We really should fix this limitation of the VFS, but it's some way off
at the moment, so let's just silence the user-visible error for now.
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
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 <flodiebold@gmail.com>
3516: Handle visibility in more cases in completion r=matklad a=flodiebold
This means we don't show private items when completing paths or method calls.
We might want to show private items if we can edit their definition and provide a "make public" assist, but I feel like we'd need better sorting of completion items for that, so they can be not shown or sorted to the bottom by default. Until then, they're usually more of a distraction to me.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
3518: Add parse_to_token_tree r=matklad a=edwin0cheng
This PR introduce a function for parsing `&str` to `tt::TokenTree`:
```rust
// Convert a string to a `TokenTree`
pub fn parse_to_token_tree(text: &str) -> Option<(tt::Subtree, TokenMap)> {
````
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
3499: Resolve `Self::AssocTy` in impls r=matklad a=flodiebold
To do this we need to carry around the original resolution a bit, because `Self`
gets resolved to the actual type immediately, but you're not allowed to write
the equivalent type in a projection. (I tried just comparing the projection base
type with the impl self type, but that seemed too dirty.) This is basically how
rustc does it as well.
Fixes#3249.
Co-authored-by: Florian Diebold <florian.diebold@freiheit.com>
To do this we need to carry around the original resolution a bit, because `Self`
gets resolved to the actual type immediately, but you're not allowed to write
the equivalent type in a projection. (I tried just comparing the projection base
type with the impl self type, but that seemed too dirty.) This is basically how
rustc does it as well.
Fixes#3249.
