diff options
| author | bors[bot] <26634292+bors[bot]@users.noreply.github.com> | 2021-05-09 15:40:49 +0100 |
|---|---|---|
| committer | GitHub <[email protected]> | 2021-05-09 15:40:49 +0100 |
| commit | 0900beeaa2ca4b9e91d51165545935d4e1db7bb6 (patch) | |
| tree | db1e1461562c7d8a90d816e5a241636f10468cdc /crates/parser/src | |
| parent | 3f01edebecd5a73fc2abab75a8b29b9d64fd9fa0 (diff) | |
| parent | fd5a1d1765801ef3bda447b849951631f61f1d25 (diff) | |
Merge #8776
8776: fix: fix unnecessary recomputations due to macros r=jonas-schievink a=jonas-schievink
This computes a macro's fragment kind eagerly (when the calling file is still available in parsed form) and stores it in the `MacroCallLoc`. This means that during expansion we no longer have to reparse the file containing the macro call, avoiding the unnecessary salsa dependencies (https://github.com/rust-analyzer/rust-analyzer/pull/8746#issuecomment-834776349).
Marking as draft until I manage to find a test for this problem, since for some reason `typing_inside_a_function_should_not_invalidate_expansions` does not catch this (which might indicate that I misunderstand the problem).
I've manually confirmed that this fixes the issue described in https://github.com/rust-analyzer/rust-analyzer/pull/8746#issuecomment-834776349:
```
7ms - parse_query @ FileId(179)
12ms - SourceBinder::to_module_def
12ms - crate_def_map:wait
5ms - item_tree_query (1 calls)
7ms - ???
```
Co-authored-by: Jonas Schievink <[email protected]>
Diffstat (limited to 'crates/parser/src')
0 files changed, 0 insertions, 0 deletions