| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
|\ \ \ \ \ \
| |_|_|/ / /
|/| | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
8462: Expand macros at type position r=jonas-schievink a=cynecx
Co-authored-by: cynecx <[email protected]>
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
8574: Check for rust doc code attributes like rustdoc does r=Veykril a=Veykril
bors r+
Co-authored-by: Lukas Wirth <[email protected]>
|
| | | | | | | |
|
| | | | | | | |
|
|\ \ \ \ \ \ \
| |/ / / / / /
|/| | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
8565: Fill match arms assist: add remaining arms for tuple of enums r=iDawer a=iDawer
Fix for #8493
However, the assist is still flaky and does not use `hir_ty::diagnostics::match_check`
Co-authored-by: Dawer <[email protected]>
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
|\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
8540: Prevent being able to rename items that are not part of the workspace r=Veykril a=Veykril
This change causes renames that happen on items coming from crates outside the workspace to fail. I believe this should be the right approach, but usage of cargo's workspace might not be entirely correct for preventing these kinds of refactoring from touching things they shouldn't. I'm not entirely sure?
cc #6623, this is one of the bigger footguns when it comes to refactoring, especially in combination with import aliases people tend to rename items coming from a crates dependency which this prevents.
Co-authored-by: Lukas Wirth <[email protected]>
|
| | | | | | | | |
|
| | | | | | | | |
|
|\ \ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
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:
![2021-04-11_00-33-33](https://user-images.githubusercontent.com/5489149/114296006-b38e1000-9a5d-11eb-9112-807c01b8fd0a.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 <[email protected]>
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| |_|_|_|_|_|/ /
|/| | | | | | | |
|
|\ \ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
8564: Expand `global_asm!` to nothing r=jonas-schievink a=jonas-schievink
fixes https://github.com/rust-analyzer/rust-analyzer/issues/8563
bors r+
Co-authored-by: Jonas Schievink <[email protected]>
|
| | | | | | | | | |
|
|\ \ \ \ \ \ \ \ \
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
8561: Accept `E<error_number>` notation in doctests r=Veykril a=ChayimFriedman2
````
```compile_fail,E0000
```
````
The code was stolen from rustdoc at https://github.com/rust-lang/rust/blob/392ba2ba1a7d6c542d2459fb8133bebf62a4a423/src/librustdoc/html/markdown.rs#L866-L867
Co-authored-by: Chayim Refael Friedman <[email protected]>
|
| |/ / / / / / / /
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
```compile_fail,E0000
```
The code was stolen from rustdoc at https://github.com/rust-lang/rust/blob/392ba2ba1a7d6c542d2459fb8133bebf62a4a423/src/librustdoc/html/markdown.rs#L866-L867
|
|\ \ \ \ \ \ \ \ \
| |/ / / / / / / /
|/| | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
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:
![image](https://user-images.githubusercontent.com/24700207/115130096-40544300-9ff5-11eb-847b-969e7034e8a4.png)
After:
![image](https://user-images.githubusercontent.com/24700207/115130143-9cb76280-9ff5-11eb-9281-323746089440.png)
Co-authored-by: Chayim Refael Friedman <[email protected]>
|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
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.
|
| | | | | | | | | |
|
| |_|_|_|/ / / /
|/| | | | | | | |
|
| | | | | | | |
| | | | | | | |
| | | | | | | | |
The different pre versions include breaking changes, which cause build failures for the users.
|
| | | | | | | | |
|
| | | | | | | | |
|
|\ \ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
8546: Return CallInfo for unclosed call expressions r=Veykril a=Veykril
Closes #8522
bors r+
Co-authored-by: Lukas Wirth <[email protected]>
|
| | |_|/ / / / /
| |/| | | | | | |
|
|\ \ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
8542: Include path in `unresolved-macro-call` diagnostic r=matklad a=jonas-schievink
Co-authored-by: Jonas Schievink <[email protected]>
|
| |/ / / / / / / |
|
|\ \ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
8539: fix: Do not propose inherent traits in flyimports and import assists r=flodiebold a=SomeoneToIgnore
Closes https://github.com/rust-analyzer/rust-analyzer/issues/8520
I've went with a separate method approach, since the [highlighted code](https://github.com/rust-analyzer/rust-analyzer/issues/8520#issuecomment-819856337) has not`Type` and uses `Ty` to get his data, but the code I had to change has no access to `Ty` and has `Type` only.
Co-authored-by: Kirill Bulatov <[email protected]>
|
| |/ / / / / / / |
|
| |_|_|/ / / /
|/| | | | | | |
|
|\ \ \ \ \ \ \
| |/ / / / / /
|/| | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
8543: Assist fix: Fill match arms for a tuple of a single enum. r=Veykril a=iDawer
This is rather a small fix addressing an issue mentioned in https://github.com/rust-analyzer/rust-analyzer/issues/8493#issuecomment-818770670
Co-authored-by: Dawer <[email protected]>
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|