feat: render docs from aliased type when type has no docs
Trying to close#18344
- [x] ~Find the docs by traversing upwards if the type itself has none but aliasing for another type that might have.~
- [x] Show docs from aliased type.
- [x] Showing description that we are displaying documentation for different definition in hover box.
feat: better completions for extern blcoks
This PR refactors `add_keywords` (making it much clearer!) and enhances completion for `extern` blocks.
It is recommended to reviewing the changes in order of the commits:
- The first commit (f3c4dde0a4) doesn’t change any logic but refactors parts of the `add_keywords` function and adds detailed comments.
- The second commit (5dcc1ab649) improves completion for `extern` kw and extern blocks.
Add wrap/unwrap return type in Option
I pretty much just copied over the code and tests for wrapping/unwrapping return types in `Result` and then did a bunch of find and replace changes.
I handled unwrapping statements returning `None` by just replacing `None` with the unit type, but I'm open to suggestions for more intuitive behavior here.
And few more fixups.
I was worried this will lead to more memory usage since `ExprOrPatId` is double the size of `ExprId`, but this does not regress `analysis-stats .`. If this turns out to be a problem, we can easily use the high bit to encode this information.
Instead of lowering them to `<expr> = <expr>`, then hacking on-demand to resolve them, we lower them to `<pat> = <expr>`, and use the pattern infrastructure to handle them. It turns out, destructuring assignments are surprisingly similar to pattern bindings, and so only minor modifications are needed.
This fixes few bugs that arose because of the non-uniform handling (for example, MIR lowering not handling slice and record patterns, and closure capture calculation not handling destructuring assignments at all), and furthermore, guarantees we won't have such bugs in the future, since the programmer will always have to explicitly handle `Expr::Assignment`.
Tests don't pass yet; that's because the generated patterns do not exist in the source map. The next commit will fix that.
Because our lint infra *can* handle allows from within macro expansions!
(Also, what did this reason have to do with something that is a hard error and not a lint? I'm puzzled).
I wonder how many such diagnostics we have...
Maybe that also mean we can change `unused_mut` to no-longer-experimental? But this is a change I'm afraid to do without checking.
compiler: Adopt rust-analyzer impls for `LayoutCalculatorError`
We're about to massively churn the internals of `rustc_abi`. To minimize the immediate and future impact on rust-analyzer, as a subtree that depends on this crate, grow some API on `LayoutCalculatorError` that reflects their uses of it. This way we can nest the type in theirs, and they can just call functions on it without having to inspect and flatten-out its innards.
LSP says about Position::character
> If the character value is greater than the line length it defaults back to the line length.
but from_proto::offset() doesn't implement this.
A client might for example request code actions for a whole line by sending
Position::character=99999. I don't think there is ever a reason (besides laziness) why the
client can't specify the line length instead but I guess we should not crash but follow protocol.
Technically it should be a warning, not an error but warning is not shown by default so keep
it at error I guess.
Fixes#18240
