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).
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>
2795: Use dummy value for macro file in bulitin macros r=matklad a=edwin0cheng
This PR skip the actual line and column computation for `MacroFile` and return a dummy value instead.
Related to #2794
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
2614: Clippy cleanup r=matklad a=kjeremy
Just a few tweaks from the latest clippy. There are a lot more but we should probably tweak our settings.
Co-authored-by: kjeremy <kjeremy@gmail.com>
2562: Fix NavigationTarget ranges r=matklad a=edwin0cheng
Fix the issue described in https://github.com/rust-analyzer/rust-analyzer/pull/2544#issuecomment-565572553
This PR change the order for finding `full_range` of `focus_range` in following orders:
1. map both ranges to macro_call
2. map focus range to a token inside macro call, and full range to the whole of macro call
3. map both ranges to the whole of macro call
And fix the corresponding tests and make these tests easily to follow.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
2550: Infer - and ! using std::ops::{Neg, Not} r=flodiebold a=kiljacken
Found some low hanging fruit while taking a cursory look at index inferring.
Co-authored-by: Emil Lauridsen <mine809@gmail.com>
SourceAnalyzer didn't work properly within expression macro expansions because
it didn't find the enclosing function. Fix this by going up the expansion chain
to find ancestors. This makes the test work, but apparently in real usage it's
still not working.
2362: Expand compile_error! r=edwin0cheng a=kjeremy
Does not validate that the input is a string literal. I thought that I could `match_ast!` against the `macro_args` but that did not work. Even if it had I am not sure which error would be appropriate.
Co-authored-by: Jeremy Kolb <kjeremy@gmail.com>
