aboutsummaryrefslogtreecommitdiff
path: root/crates/ra_hir_expand
Commit message (Collapse)AuthorAgeFilesLines
* Convert code to text-sizeAleksey Kladov2020-04-252-4/+4
|
* Improve remove dervie attrsEdwin Cheng2020-04-212-10/+97
|
* Some clippy fixesJeremy Kolb2020-04-192-5/+5
|
* Simplify Diagnostic structureAleksey Kladov2020-04-171-2/+1
| | | | | | 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.
* Correctly highlight ranges of diagnostics from macrosAleksey Kladov2020-04-171-1/+1
| | | | closes #2799
* Don't expose impl details of SyntaxPtrAleksey Kladov2020-04-171-3/+1
|
* Align grammar for record patterns and literalsAleksey Kladov2020-04-111-0/+9
| | | | | | The grammar now looks like this [name_ref :] pat
* Forward compatAleksey Kladov2020-04-101-1/+1
|
* Improve tt::Subtree debug printEdwin Cheng2020-04-091-1/+1
|
* Fix unnecessary braces warningsLaurențiu Nicola2020-04-061-3/+3
|
* Implement ra_proc_macro client logicEdwin Cheng2020-03-311-1/+26
|
* Merge #3727bors[bot]2020-03-261-15/+14
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
| * Remove deps on tt_mbeEdwin Cheng2020-03-261-2/+3
| |
| * Add ProcMacroClientEdwin Cheng2020-03-251-16/+14
| |
* | Get rid of ItemOrMacroAleksey Kladov2020-03-261-2/+0
|/
* Rename to CustomDeriveEdwin Cheng2020-03-254-4/+4
|
* Refactoring a bitEdwin Cheng2020-03-251-5/+5
|
* Use dummy implementationEdwin Cheng2020-03-251-2/+3
|
* Add basic custom derive loweringEdwin Cheng2020-03-256-19/+63
|
* Generalise syntax rewriting infrastructure to allow removal of nodesAleksey Kladov2020-03-241-10/+7
|
* Fix typoEdwin Cheng2020-03-211-1/+1
|
* Add identity expansion checkingEdwin Cheng2020-03-211-3/+21
|
* Simplify Arena to use a generic indexAleksey Kladov2020-03-191-5/+3
|
* Turn ExpandResult into structFlorian Diebold2020-03-161-8/+4
|
* Add test, remove printlnsFlorian Diebold2020-03-161-1/+0
|
* wipFlorian Diebold2020-03-161-6/+10
|
* Make MBE expansion more resilient (WIP)Florian Diebold2020-03-161-41/+49
|
* Use `dyn Trait` for working with databseAleksey Kladov2020-03-164-8/+8
| | | | | | | 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).
* ra_hir_expand: change the ordering of imports as per the formatterVeetaha2020-03-151-1/+1
|
* ra_hir_expand: migrate to impl_intern_key!()Veetaha2020-03-151-17/+3
|
* Update commentEdwin Cheng2020-03-111-4/+4
| | | | Co-Authored-By: bjorn3 <[email protected]>
* Implement dummy assert macroEdwin Cheng2020-03-113-0/+58
|
* Add extern sourceEdwin Cheng2020-03-111-1/+2
|
* Add and fix testsEdwin Cheng2020-03-101-60/+121
|
* Add resolve_extern_path in DBEdwin Cheng2020-03-101-1/+8
|
* Merge #3513bors[bot]2020-03-091-4/+67
|\ | | | | | | | | | | | | | | | | | | | | 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]>
| * Move hypothetical expansion to hir_expandFlorian Diebold2020-03-082-17/+35
| |
| * Remove TODOsFlorian Diebold2020-03-071-5/+6
| |
| * Try to complete within macrosFlorian Diebold2020-03-072-9/+53
| |
* | Add parse_to_token_treeEdwin Cheng2020-03-081-4/+4
|/
* Prevent include! macro include itselfEdwin Cheng2020-03-071-1/+6
|
* Fix test and add more commentEdwin Cheng2020-03-071-1/+4
|
* Use a not so dummy implementation of env macroEdwin Cheng2020-03-071-1/+1
|
* Implment include macroEdwin Cheng2020-03-063-19/+62
|
* Add comment for parents loggingEdwin Cheng2020-03-041-7/+12
|
* Fix whitespace in testsEdwin Cheng2020-03-042-3/+3
|
* Fix #3436Edwin Cheng2020-03-041-6/+2
|
* Add more logEdwin Cheng2020-03-041-0/+9
|
* Fixed a typo in commentEdwin Cheng2020-03-031-1/+1
|
* Fix panic on eager expansionEdwin Cheng2020-03-031-2/+18
|