aboutsummaryrefslogtreecommitdiff
path: root/crates/hir_expand
Commit message (Collapse)AuthorAgeFilesLines
...
* Merge #7145bors[bot]2021-01-082-36/+186
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7145: Proper handling $crate Take 2 [DO NOT MERGE] r=edwin0cheng a=edwin0cheng Similar to previous PR (#7133) , but improved the following things : 1. Instead of storing the whole `ExpansionInfo`, we store a similar but stripped version `HygieneInfo`. 2. Instread of storing the `SyntaxNode` (because every token we are interested are IDENT), we store the `TextRange` only. 3. Because of 2, we now can put it in Salsa. 4. And most important improvement: Instead of computing the whole frames every single time, we compute it recursively through salsa: (Such that in the best scenario, we only need to compute the first layer of frame) ```rust let def_site = db.hygiene_frame(info.def.file_id); let call_site = db.hygiene_frame(info.arg.file_id); HygieneFrame { expansion: Some(info), local_inner, krate, call_site, def_site } ``` The overall speed compared to previous PR is much faster (65s vs 45s) : ``` [WITH old PR] Database loaded 644.86ms, 284mi Crates in this dir: 36 Total modules found: 576 Total declarations: 11153 Total functions: 8715 Item Collection: 15.78s, 91562mi Total expressions: 240721 Expressions of unknown type: 2635 (1%) Expressions of partially unknown type: 2064 (0%) Type mismatches: 865 Inference: 49.84s, 250747mi Total: 65.62s, 342310mi rust-analyzer -q analysis-stats . 66.72s user 0.57s system 99% cpu 1:07.40 total [WITH this PR] Database loaded 665.83ms, 284mi Crates in this dir: 36 Total modules found: 577 Total declarations: 11188 Total functions: 8743 Item Collection: 15.28s, 84919mi Total expressions: 241229 Expressions of unknown type: 2637 (1%) Expressions of partially unknown type: 2064 (0%) Type mismatches: 868 Inference: 30.15s, 135293mi Total: 45.43s, 220213mi rust-analyzer -q analysis-stats . 46.26s user 0.74s system 99% cpu 47.294 total ``` *HOWEVER*, it is still a perf regression (35s vs 45s): ``` [WITHOUT this PR] Database loaded 657.42ms, 284mi Crates in this dir: 36 Total modules found: 577 Total declarations: 11177 Total functions: 8735 Item Collection: 12.87s, 72407mi Total expressions: 239380 Expressions of unknown type: 2643 (1%) Expressions of partially unknown type: 2064 (0%) Type mismatches: 868 Inference: 22.88s, 97889mi Total: 35.74s, 170297mi rust-analyzer -q analysis-stats . 36.71s user 0.63s system 99% cpu 37.498 total ``` Co-authored-by: Edwin Cheng <[email protected]>
| * Proper handling $crate Take 2Edwin Cheng2021-01-072-36/+186
| |
* | Add fix to wrap return expression in SomePhil Ellison2021-01-071-0/+2
| |
* | Change <|> to $0 - RebaseKevaundray Wedderburn2021-01-071-1/+1
| |
* | Refactor TokenBuffer for reduc cloningEdwin Cheng2021-01-041-5/+5
|/
* Revert "Proper handling $crate and local_inner_macros"Jonas Schievink2021-01-032-130/+32
|
* Fixed nested eager macro bugEdwin Cheng2021-01-031-0/+6
|
* Merge #7133bors[bot]2021-01-022-32/+130
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | 7133: Proper handling $crate and local_inner_macros r=jonas-schievink a=edwin0cheng This PR introduces `HygineFrames` to store the macro definition/call site hierarchy in hyginee and when resolving `local_inner_macros` and `$crate`, we use the token to look up the corresponding frame and return the correct value. See also: https://rustc-dev-guide.rust-lang.org/macro-expansion.html#hygiene-and-hierarchies fixe #6890 and #6788 r? @jonas-schievink Co-authored-by: Edwin Cheng <[email protected]>
| * Use arena instead of vecEdwin Cheng2021-01-021-22/+16
| |
| * Introduce HygieneFrames for proper token hygineeEdwin Cheng2021-01-022-32/+136
| |
* | Fix infer error of macro invocation in array exprEdwin Cheng2021-01-021-1/+1
|/
* Fix `==` in in format causes mismatched-arg-countEdwin Cheng2020-12-311-1/+2
|
* Pass crate environment to proc macrosJonas Schievink2020-12-272-4/+7
|
* Store invocation site for eager macrosJonas Schievink2020-12-224-28/+27
|
* More accurate `#[derive]` parsingJonas Schievink2020-12-191-0/+1
| | | | This now allows full paths to the derive macro
* Implement `RawAttr::filter`Jonas Schievink2020-12-181-0/+1
|
* Node-ify lifetimesLukas Wirth2020-12-161-3/+2
|
* Make macro def krate mandatoryJonas Schievink2020-12-154-24/+36
| | | | Refactors builtin derive support to go through proper name resolution
* Basic support for decl macros 2.0Jonas Schievink2020-12-153-11/+20
|
* Move to upstream `macro_rules!` modelJonas Schievink2020-12-152-7/+11
|
* Merge #6886bors[bot]2020-12-151-2/+2
|\ | | | | | | | | | | | | | | 6886: Expand statements for macros in lowering r=matklad a=edwin0cheng Fixes #6811 Co-authored-by: Edwin Cheng <[email protected]>
| * Remove obsolete commentEdwin Cheng2020-12-151-1/+0
| |
| * Expand statements for mbe in loweringEdwin Cheng2020-12-151-1/+2
| |
* | Resolve `macro-error` diagnostics on asm & llvm_asmlf-2020-12-152-0/+17
| | | | | | | | | | | | | | | | | | We currently stub these out as returning unit. This fixes spurious RA diagnostics in the following: ```rust unsafe { asm!(""); llvm_asm!(""); } ```
* | Implement `module_path!()`Jonas Schievink2020-12-142-0/+11
|/
* Add Lifetimes to the HIRLukas Wirth2020-12-111-1/+6
|
* Use decimal notationJonas Schievink2020-12-101-1/+1
|
* Double the macro token limitJonas Schievink2020-12-101-1/+1
|
* Improve macro limit error and move to constJonas Schievink2020-12-101-3/+9
|
* format_args: handle key-value argumentsJonas Schievink2020-12-101-0/+6
|
* Introduce anchored_pathAleksey Kladov2020-12-092-5/+6
| | | | | They allow to represent paths like `#[path = "C:\path.rs"] mod foo;` in a lossless cross-platform & network-transparent way.
* Fix `concat!` with integer literalsJonas Schievink2020-12-081-8/+34
|
* Fix logic for determining macro callsJonas Schievink2020-12-081-9/+7
| | | | | | I believe this currently goes back all the way to the initial user-written call, but that seems better than the current broken behavior.
* Make `original_range` a method on `InFile<&SyntaxNode>`Jonas Schievink2020-12-081-3/+69
|
* Use the right `def_crate` for builtin macrosJonas Schievink2020-12-071-1/+1
|
* Remove resolved FIXMEJonas Schievink2020-12-071-1/+0
|
* Make `compile_error!` message match upstream rustcJonas Schievink2020-12-031-4/+1
| | | | It only consists of the argument passed to it
* Fix proc macro token mappingJonas Schievink2020-12-031-6/+16
|
* Rename `error_sink` to `diagnostic_sink`Jonas Schievink2020-12-031-11/+12
|
* Make `compile_error!` lazy and emit a diagnosticJonas Schievink2020-12-032-21/+28
|
* Give better diagnostic if `OUT_DIR` is unsetJonas Schievink2020-12-031-9/+17
|
* Propagate eager expansion errorsJonas Schievink2020-12-031-16/+99
|
* builtin_macro: move to `mbe::ExpandResult`Jonas Schievink2020-11-303-52/+81
|
* Merge #6659bors[bot]2020-11-281-2/+7
|\ | | | | | | | | | | | | | | | | 6659: Explain how we get precise spans for diagnostics. r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * Explain how we get precise spans for diagnostics.Aleksey Kladov2020-11-281-2/+7
| |
* | Merge #6645bors[bot]2020-11-283-3/+10
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6645: Publish diagnostics for macro expansion errors r=matklad a=jonas-schievink This adds 2 new diagnostics, emitted during name resolution: * `unresolved-proc-macro`, a weak warning that is emitted when a proc macro is supposed to be expanded, but was not provided by the build system. This usually means that proc macro support is turned off, but may also indicate setup issues when using rust-project.json. Being a weak warning, this should help set expectations when users see it, while not being too obstructive. We do not yet emit this for attribute macros though, just custom derives and `!` macros. * `macro-error`, which is emitted when any macro (procedural or `macro_rules!`) fails to expand due to some error. This is an error-level diagnostic, but currently still marked as experimental, because there might be spurious errors and this hasn't been tested too well. This does not yet emit diagnostics when expansion in item bodies fails, just for module-level macros. Known bug: The "proc macro not found" diagnostic points at the whole item for custom derives, it should just point at the macro's name in the `#[derive]` list, but I haven't found an easy way to do that. Screenshots: ![screenshot-2020-11-26-19:54:14](https://user-images.githubusercontent.com/1786438/100385782-f8bc2300-3023-11eb-9f27-e8f8ce9d6114.png) ![screenshot-2020-11-26-19:55:39](https://user-images.githubusercontent.com/1786438/100385784-f954b980-3023-11eb-9617-ac2eb0a0a9dc.png) Co-authored-by: Jonas Schievink <[email protected]>
| * Publish diagnostics for macro expansion errorsJonas Schievink2020-11-272-2/+9
| |
| * Add dedicated error for "proc macro not found"Jonas Schievink2020-11-271-1/+1
| |
* | Add/Fix macro expansion profilingJonas Schievink2020-11-271-2/+4
|/
* Use `ExpandResult` instead of `MacroResult`Jonas Schievink2020-11-262-52/+30
| | | | `MacroResult` is redundant
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-04 23:11:21 +0100