| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
| |
Pretty harmless typo, but it does get exposed in
lsp-rust-analyzer-expand-macro.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
4234: Support local_inner_macros r=jonas-schievink a=edwin0cheng
This PR implements `#[macro_export(local_inner_macros)]` support.
Note that the rustc implementation is quite [hacky][1] too. :)
[1]: https://github.com/rust-lang/rust/blob/614f273e9388ddd7804d5cbc80b8865068a3744e/src/librustc_resolve/macros.rs#L456
Co-authored-by: Edwin Cheng <[email protected]>
|
| |
| |
| |
| |
| | |
Fix spacing
Co-authored-by: Jonas Schievink <[email protected]>
|
| | |
|
| | |
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
4125: Avoid lossy OsString conversions r=matklad a=lnicola
This is a bit invasive, and perhaps for not much benefit since non-UTF-8 environment variables don't work anyway.
Co-authored-by: Laurențiu Nicola <[email protected]>
|
| | |
|
|/ |
|
| |
|
| |
|
|
|
|
|
|
| |
It's not entirely clear what subnode ranges should mean in the
presence of macros, so let's leave them out for now. We are not using
them heavily anyway.
|
|
|
|
| |
closes #2799
|
| |
|
|
|
|
|
|
| |
The grammar now looks like this
[name_ref :] pat
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
3727: Introduce ra_proc_macro r=matklad a=edwin0cheng
This PR implemented:
1. Reading dylib path of proc-macro crate from cargo check , similar to how `OUTDIR` is obtained.
2. Added a new crate `ra_proc_macro` and implement the foot-work for reading result from external proc-macro expander.
3. Added a struct `ProcMacroClient` , which will be responsible to the client side communication to the External process.
Co-authored-by: Edwin Cheng <[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).
|
| |
|
| |
|
|
|
|
| |
Co-Authored-By: bjorn3 <[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]>
|
| | |
|
| | |
|