aboutsummaryrefslogtreecommitdiff
path: root/crates/ra_hir_expand
Commit message (Collapse)AuthorAgeFilesLines
...
* Store proc-macro result in salsa dbEdwin Cheng2020-05-141-1/+35
|
* fix typo unimplementated -> unimplementedTrevor Spiteri2020-05-121-2/+2
| | | | | Pretty harmless typo, but it does get exposed in lsp-rust-analyzer-expand-macro.
* Merge #4234bors[bot]2020-05-024-11/+28
|\ | | | | | | | | | | | | | | | | | | | | | | 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]>
| * Update crates/ra_hir_expand/src/builtin_derive.rs Edwin Cheng2020-05-021-1/+1
| | | | | | | | | | Fix spacing Co-authored-by: Jonas Schievink <[email protected]>
| * Support local_inner_macrosEdwin Cheng2020-05-014-11/+28
| |
* | Introduce EffectExprAleksey Kladov2020-05-021-2/+1
| |
* | Introduce LowerCtx for path loweringEdwin Cheng2020-05-011-1/+1
|/
* Check dep name to detect it is coreEdwin Cheng2020-04-271-4/+6
|
* Use empty-deps tricks to detect it is coreEdwin Cheng2020-04-271-5/+21
|
* Add testEdwin Cheng2020-04-271-1/+1
|
* Use core instead of std for builtin derive macrosEdwin Cheng2020-04-271-32/+61
|
* Merge #4125bors[bot]2020-04-251-1/+1
|\ | | | | | | | | | | | | | | 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]>
| * Avoid lossy OsString conversionsLaurențiu Nicola2020-04-251-1/+1
| |
* | 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
| |
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-10 01:09:25 +0000