| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|\ \ \ \
| |_|_|/
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
8802: Keep comments and attrs when extracting struct from enum variant r=Veykril a=DropDemBits
Fixes #6730
Still unsure if existing visibilities of fields should be forced to pub (which is what was previously done), or if it's okay to keep it in the extracted struct.
Co-authored-by: DropDemBits <[email protected]>
|
| | | | |
|
| |_|/
|/| | |
|
| | | |
|
| | |
| | |
| | |
| | | |
This reverts commit bda68e23328ca62a71da348a13c4d13cc8f991f3.
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
8806: fix: Strip delimiter from fn-like macro invocations r=jonas-schievink a=jonas-schievink
This broke in https://github.com/rust-analyzer/rust-analyzer/pull/8796 (again), the fix is easy though
bors r+
Co-authored-by: Jonas Schievink <[email protected]>
|
| | | | |
|
|/ / / |
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
8398: Fix inference with conditionally compiled tails r=flodiebold a=DJMcNab
Fixes #8378
Co-authored-by: Daniel McNab <[email protected]>
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
Fixes #8378
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
8801: feat: Allow viewing the crate graph in a webview r=jonas-schievink a=jonas-schievink
This uses `dot` to render the crate graph as an SVD file, and displays it in a VS Code panel. For simple crate graphs, it works quite well:
![screenshot-2021-05-11-16:19:32](https://user-images.githubusercontent.com/1786438/117831361-c4a48980-b274-11eb-9276-240cdf6919aa.png)
Unfortunately, on rust-analyzer itself (and most medium-sized dependency graphs), `dot` runs for around a minute and then produces this mess:
![screenshot-2021-05-11-16:41:37](https://user-images.githubusercontent.com/1786438/117834831-c754ae00-b277-11eb-850b-138495dbeba8.png)
Co-authored-by: Jonas Schievink <[email protected]>
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | | |
Co-authored-by: bjorn3 <[email protected]>
|
| | | | | |
|
| | | | | |
|
|\ \ \ \ \
| |/ / / /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
8796: internal: rewrite `#[derive]` removal to be based on AST (take 2) r=jonas-schievink a=jonas-schievink
Second attempt of https://github.com/rust-analyzer/rust-analyzer/pull/8443, this uses syntactical attribute offsets in `hir_expand`, and changes `attr.rs` to make those easy to derive.
This will make it easy to add similar attribute removal for attribute macros, unblocking them.
Co-authored-by: Jonas Schievink <[email protected]>
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
|\ \ \ \ \
| |_|_|_|/
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
8800: feat: Make "pull assignments up" assist work in more cases r=Jesse-Bakker a=Jesse-Bakker
Fixes #8771
Co-authored-by: Jesse Bakker <[email protected]>
|
| | | | | |
|
|\ \ \ \ \
| |_|_|_|/
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
8794: Give MergeBehaviour variants better names r=Veykril a=Veykril
I never really liked the variant names I gave this enum from the beginning and then I found out about rustfmt's `imports_granularity` config:
> imports_granularity
>
> How imports should be grouped into use statements. Imports will be merged or split to the configured level of granularity.
>
> Default value: Preserve
> Possible values: Preserve, Crate, Module, Item
> Stable: No
I personally prefer using `crate` over `full` and `module` over last, they seem more descriptive. Keeping these similar between tooling also seems like a good plus point to me.
We might even wanna take over the entire enum at some point if we have a `format/cleanup imports` assists in the future which would probably want to also have the `preserve` and `item` options.
Co-authored-by: Lukas Wirth <[email protected]>
|
| | | | | |
|
| | |/ /
| |/| | |
|
|/ / / |
|
| | | |
|
| | | |
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
8783: internal: introduce `ast::make::ext` module with common shortcuts r=matklad a=matklad
bors r+
🤖
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
There's a tension between keeping a well-architectured minimal
orthogonal set of constructs, and providing convenience functions.
Relieve this pressure by introducing an dedicated module for
non-orthogonal shortcuts.
This is inspired by the django.shortcuts module which serves a similar
purpose architecturally.
|
|\| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
8782: internal: fix make API r=matklad a=matklad
bors r+
🤖
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | | |
|
|\| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
8781: internal: rewrite **Repalce impl Trait** assist to mutable syntax trees r=matklad a=matklad
bors r+
🤖
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
|\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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]>
|
| | | | |
|
| | | | |
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
8777: Escape characters in builtin macros correctly r=edwin0cheng a=edwin0cheng
Fixes #8749
It is the same bug in #8560 but in our `quote!` macro.
Because the "\" are adding exponentially in #8749 case, so the text is eat up all the memory.
bors r+
Co-authored-by: Edwin Cheng <[email protected]>
|
| |/ / / |
|
|\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
8774: feat: Honor `.cargo/config.toml` r=matklad a=Veykril
![f1Gup1aiAn](https://user-images.githubusercontent.com/3757771/117545448-1dcaae00-b026-11eb-977a-0f35a5e3f2e0.gif)
Implements `cargo/.config` build target and cfg access by using unstable cargo options:
- `cargo config get` to read the target triple out of the config to pass to `cargo metadata` --filter-platform
- `cargo rustc --print` to read out the `rustc_cfgs`, this causes us to honor `rustflags` and the like.
If those commands fail, due to not having a nightly toolchain present for example, they will fall back to invoking rustc directly as we currently do.
I personally think it should be fine to use these unstable options as they are unlikely to change(even if they did it shouldn't be a problem due to the fallback) and don't burden the user if they do not have a nightly toolchain at hand since we fall back to the previous behaviour.
cc #8741
Closes #6604, Closes #5904, Closes #8430, Closes #8480
Co-authored-by: Lukas Wirth <[email protected]>
|
| | | |
| | | |
| | | |
| | | | |
throughs cargo
|
| | | | |
|