8467: Adds impl Deref assist r=jhgg a=jhgg
This PR adds a new `generate_deref` assist that automatically generates a deref impl for a given struct field.
Check out this gif:
--
I have a few Q's:
- [x] Should I write more tests, if so, what precisely should I test for?
- [x] I have an inline question on line 65, can someone provide guidance? :)
- [x] I can implement this for `ast::TupleField` too. But should it be a separate assist fn, or should I try and jam both into the `generate_deref`?
- [x] I want to follow this up with an assist on `impl $0Deref for T {` which would automatically generate a `DerefMut` impl that mirrors the Deref as well, however, I could probably use some pointers on how to do that, since I'll have to reach into the ast of `fn deref` to grab the field that it's referencing for the `DerefMut` impl.
Co-authored-by: jake <jh@discordapp.com>
8560: Escape characters in doc comments in macros correctly r=jonas-schievink a=ChayimFriedman2
Previously they were escaped twice, both by `.escape_default()` and the debug view of strings (`{:?}`). This leads to things like newlines or tabs in documentation comments being `\\n`, but we unescape literals only once, ending up with `\n`.
This was hard to spot because CMark unescaped them (at least for `'` and `"`), but it did not do so in code blocks.
This also was the root cause of #7781. This issue was solved by using `.escape_debug()` instead of `.escape_default()`, but the real issue remained.
We can bring the `.escape_default()` back by now, however I didn't do it because it is probably slower than `.escape_debug()` (more work to do), and also in order to change the code the least.
Example (the keyword and primitive docs are `include!()`d at https://doc.rust-lang.org/src/std/lib.rs.html#570-578, and thus originate from macro):
Before:
After:
Co-authored-by: Chayim Refael Friedman <chayimfr@gmail.com>
Previously they were escaped twice, both by `.escape_default()` and the debug view of strings (`{:?}`). This leads to things like newlines or tabs in documentation comments being `\\n`, but we unescape literals only once, ending up with `\n`.
This was hard to spot because CMark unescaped them (at least for `'` and `"`), but it did not do so in code blocks.
This also was the root cause of #7781. This issue was solved by using `.escape_debug()` instead of `.escape_default()`, but the real issue remained.
We can bring the `.escape_default()` back by now, however I didn't do it because it is probably slower than `.escape_debug()` (more work to do), and also in order to change the code the least.
8510: Move cursor position when using item movers r=jonas-schievink a=jonas-schievink
This updates the cursor position when moving items around to stay in the same location within the moved node.
I changed the `moveItem` response to `SnippetTextEdit[]`, since that made more sense to me (the file was ignored by the client anyways, since the edits always apply to the current document). It also matches `onEnter`, which seems logical to me, but please let me know if this doesn't make sense.
There's still a bug in the client-side snippet code that will cause the cursor position to be slightly off when moving parameters in the same line (presumably we don't track the column correctly after deleting `$0`). Not really sure how to fix that immediately, but this PR should already be an improvement despite that bug.
8533: Fix typo in style guide r=jonas-schievink a=jonas-schievink
Fixes bold text rendering
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
8432: decl_check: consider outer scopes' allows r=jonas-schievink a=lf-
Fix#8417. Also makes it less noisy about no_mangle annotated stuff the
user can do nothing about.
Note: this still is broken with bitfield! macros. A repro in an ignore
test is included here. I believe this bug is elsewhere, and I don't
think I can work around it here.
I would like help filing the remaining bug, as it does actually affect
users, but I don't know how to describe the behaviour (or even if it
is unintended).
Co-authored-by: Jade <software@lfcode.ca>
8354: Distinguishing between different operators in semantic highlighting r=matklad a=chetankhilosiya
Co-authored-by: Chetan Khilosiya <chetan.khilosiya@gmail.com>
8415: Fix faulty assertion when extracting function with macro call r=matklad a=brandondong
**Reproduction:**
```rust
fn main() {
let n = 1;
let k = n * n;
dbg!(n);
}
```
1. Select the second and third lines of the main function. Use the "Extract into function" code assist.
2. Panic occurs in debug, error is logged in release: "[ERROR ide_assists::handlers::extract_function] assertion failed: matches!(path, ast :: Expr :: PathExpr(_))".
3. Function generates successfully on release where the panic was bypassed.
```rust
fn fun_name(n: i32) {
let k = n * n;
dbg!(n);
}
```
**Cause:**
- The generated function will take `n` as a parameter. The extraction logic needs to search the usages of `n` to determine whether it is used mutably or not. The helper `path_element_of_reference` is called for each usage but the second usage is a macro call and fails the `Expr::PathExpr(_)` match assertion.
- The caller of `path_element_of_reference` does implicitly assume it to be a `Expr::PathExpr(_)` in how it looks at its parent node for determining whether it is used mutably. This logic will not work for macros.
- I'm not sure if there are any other cases besides macros where it could be something other than a `Expr::PathExpr(_)`. I tried various examples and could not find any.
**Fix:**
- Update assertion to include the macro case.
- Add a FIXME to properly handle checking if a macro usage requires mutable access. For now, return false instead of running the existing logic that is tailored for `Expr::PathExpr(_)`'s.
Co-authored-by: Brandon <brandondong604@hotmail.com>
