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 <mail4score@gmail.com>
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.
Note that `for` type is rust-analyzer's own invention.
Both the reference and syn allow `for` only for fnptr types, and we
allow them everywhere. This needs to be checked with respect to type
bounds grammar...
The TypeRef name comes from IntelliJ days, where you often have both
type *syntax* as well as *semantical* representation of types in
scope. And naming both Type is confusing.
In rust-analyzer however, we use ast types as `ast::Type`, and have
many more semantic counterparts to ast types, so avoiding name clash
here is just confusing.