| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
5746: Structured search replace now handles UFCS calls to trait methods r=matklad a=davidlattimore
Co-authored-by: David Lattimore <[email protected]>
|
| | |
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
5732: Consider only IdentPats for param name hints r=matklad a=SomeoneToIgnore
Closes https://github.com/rust-analyzer/rust-analyzer/issues/4960
Avoid displaying any param name hints like
<img width="590" alt="image" src="https://user-images.githubusercontent.com/2690773/90071461-47a4ad80-dcfe-11ea-9330-fb4f4e2d1b71.png">
Those hints seem to occupy plenty of space for no apparent benefit, with their destructured content not used in the code with the function hints.
I'm not entirely sure if we should show something else than `IdentPat`s, since I don't understand some of the `Pat` variant meanings:
https://github.com/rust-analyzer/rust-analyzer/blob/a1c187eef3ba08076aedb5154929f7eda8d1b424/crates/syntax/src/ast/generated/nodes.rs#L1336-L1352
Co-authored-by: Kirill Bulatov <[email protected]>
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
5744: Rename ra_project_model -> project_model r=matklad a=pksunkara
Co-authored-by: Pavan Kumar Sunkara <[email protected]>
|
| | | |
|
| | | |
|
|/ / |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
5637: SSR: Matching trait associated constants, types and functions r=matklad a=davidlattimore
This fixes matching of things like `HashMap::default()` by resolving `HashMap` instead of `default` (which resolves to `Default::default`).
Same for associated constants and types that are part of a trait implementation.
However, we still don't support matching calls to trait methods.
Co-authored-by: David Lattimore <[email protected]>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This fixes matching of things like `HashMap::default()` by resolving
`HashMap` instead of `default` (which resolves to `Default::default`).
Same for associated constants and types that are part of a trait
implementation.
However, we still don't support matching calls to trait methods.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
5553: Add fix ranges for diagnostics r=matklad a=SomeoneToIgnore
A follow-up of https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Fwg-rls-2.2E0/topic/Less.20red.20in.20the.20code
Now diagnostics can apply fixes in a range that's different from the range used to highlight the diagnostics.
Previous logic did not consider the fix range, having both ranges equal, which could cause a lot of red noise in the editor.
Now, the fix range gets used with the fix, the diagnostics range is used for everything else which allows to improve the error highlighting.
before:
<img width="191" alt="image" src="https://user-images.githubusercontent.com/2690773/88590727-df9a6a00-d063-11ea-97ed-9809c1c5e6e6.png">
after:
<img width="222" alt="image" src="https://user-images.githubusercontent.com/2690773/88590734-e1fcc400-d063-11ea-9b7c-25701cbd5352.png">
`MissingFields` and `MissingPatFields` diagnostics now have the fix range as `ast::RecordFieldList` of the expression with an error (as it was before this PR), and the diagnostics range as a `ast::Path` of the expression, if it's present (do you have any example of `ast::Expr::RecordLit` that has no path btw?).
The rest of the diagnostics have both ranges equal, same as it was before this PR.
Co-authored-by: Kirill Bulatov <[email protected]>
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
4743: Add tracking of packed repr, use it to highlight unsafe refs r=matklad a=Nashenas88
Taking a reference to a misaligned field on a packed struct is an
unsafe operation. Highlight that behavior. Currently, the misaligned
part isn't tracked, so this highlight is a bit too aggressive.
Fixes #4600
Co-authored-by: Paul Daniel Faria <[email protected]>
Co-authored-by: Paul Daniel Faria <[email protected]>
Co-authored-by: Paul Daniel Faria <[email protected]>
|
| | | | |
|
| | | | |
|