Our project model code is rather complicated -- the logic for lowering
from `cargo metadata` to `CrateGraph` is fiddly and special-case. So
far, we survived without testing this at all, but this increasingly
seems like a poor option.
So this PR introduces a simple tests just to detect the most obvious
failures. The idea here is that, although we rely on external processes
(cargo & rustc), we are actually using their stable interfaces, so we
might just mock out the outputs.
Long term, I would like to try to virtualize IO here, so as to do such
mocking in a more principled way, but lets start simple.
Should we forgo the mocking and just call `cargo metadata` directly
perhaps? Touch question -- I personally feel that fast, in-process tests
are more important in this case than any extra assurance we get from
running the real thing.
Super-long term, we would probably want to extend our heavy tests to
cover more use-cases, but we should figure a way to do that without
slowing the tests down for everyone.
Perhaps we need two-tiered bors system, where we pull from `master` into
`release` branch only when an additional set of tests passes?
9614: Parse input expressions for dbg! invocations in remove_dbg r=Veykril a=Veykril
Instead of inspecting the input tokentree manually, parse the input as `,` delimited expressions instead and act on that. This simplifies the assist quite a bit.
Fixes#8455
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9600: fix: Single-line and nested blocks in the `unwrap_block` assist r=Veykril a=patrick-gu
Fixes#8411
Rework the system for stripping whitespace and braces in the unwrap_block assist to allow correct unwrapping of blocks such as:
```rust
{ $0 0 }
```
into
```rust
0
```
and nested blocks, such as:
```rust
$0{
{
3
}
}
```
into
```rust
{
3
}
```
This is done by creating the `update_expr_string_with_pat` function (along with `update_expr_string` and `update_expr_string_without_newline`), which strips whitespace and braces in a way that ensures that only whitespace and a maximum of one brace are removed from the start and end of the expression string.
I have also created several tests to ensure that this functionality works correctly.
Co-authored-by: patrick-gu <55641350+patrick-gu@users.noreply.github.com>
