fix: trailing ':' on empty inactive reasons
## Description
Fixes trailing ':' even when there is no explanation. e.g.
``` sh
code is inactive due to #[cfg] directives:
```
## Issue
Fixes: #12615
feat: implement destructuring assignment
This is an attempt to implement destructuring assignments, or more specifically, type inference for [assignee expressions](https://doc.rust-lang.org/reference/expressions.html#place-expressions-and-value-expressions).
I'm not sure if this is the right approach, so I don't even expect this to be merged (hence the branch name 😉) but rather want to propose one direction we could choose. I don't mind getting merged if this is good enough though!
Some notes on the implementation choices:
- Assignee expressions are **not** desugared on HIR level unlike rustc, but are inferred directly along with other expressions. This matches the processing of other syntaxes that are desugared in rustc but not in r-a. I find this reasonable because r-a only needs to infer types and it's easier to relate AST nodes and HIR nodes, so I followed it.
- Assignee expressions obviously resemble patterns, so type inference for each kind of pattern and its corresponding assignee expressions share a significant amount of logic. I tried to reuse the type inference functions for patterns by introducing `PatLike` trait which generalizes assignee expressions and patterns.
- This is not the most elegant solution I suspect (and I really don't like the name of the trait!), but it's cleaner and the change is smaller than other ways I experimented, like making the functions generic without such trait, or making them take `Either<ExprId, PatId>` in place of `PatId`.
in case this is merged:
Closes#11532Closes#11839Closes#12322
fix: Report proc macro errors in expressions correctly as well
They didn't have a krate before, resulting in the generic "proc macro not found" error.
Also improve error messages a bit more.
fix: Improve proc macro errors a bit
Distinguish between
- there is no build data (for some reason?)
- there is build data, but the cargo package didn't build a proc macro dylib
- there is a proc macro dylib, but it didn't contain the proc macro we expected
- the name did not resolve to any macro (this is now an
unresolved_macro_call even for attributes)
I changed the handling of disabled attribute macro expansion to
immediately ignore the macro and report an unresolved_proc_macro,
because otherwise they would now result in loud unresolved_macro_call
errors. I hope this doesn't break anything.
Also try to improve error ranges for unresolved_macro_call / macro_error
by reusing the code for unresolved_proc_macro. It's not perfect but
probably better than before.
Distinguish between
- there is no build data (for some reason?)
- there is build data, but the cargo package didn't build a proc macro dylib
- there is a proc macro dylib, but it didn't contain the proc macro we expected
- the name did not resolve to any macro (this is now an
unresolved_macro_call even for attributes)
I changed the handling of disabled attribute macro expansion to
immediately ignore the macro and report an unresolved_proc_macro,
because otherwise they would now result in loud unresolved_macro_call
errors. I hope this doesn't break anything.
Also try to improve error ranges for unresolved_macro_call / macro_error
by reusing the code for unresolved_proc_macro. It's not perfect but
probably better than before.
fix: doc_links link type - Determine link type at start (fixes#12601)
fixes#12601
Looked like autolink/inline mismatch happened because end_link_type was parsed from the Text/Code events.
I changed it to be determined from the Start event, which should hopefully remain accurate while staying true to the cases where link type may need to be changed, according to the comment
```
// normally link's type is determined by the type of link tag in the end event,
// however in some cases we want to change the link type, for example,
// `Shortcut` type doesn't make sense for url links
```
Hopefully this is the desired behavior?
fix: Only apply `cfg(test)` for local crates
Don't analyze dependencies with `test`; this should fix various cases where crates use `cfg(not(test))` and so we didn't find things.
"Local" here currently means anything that's not from the registry, so anything inside the workspace, but also path dependencies. So this isn't perfect, and users might still need to use `rust-analyzer.cargo.unsetTest` for these in some cases.
Don't analyze dependencies with `test`; this should fix various cases
where crates use `cfg(not(test))` and so we didn't find things.
"Local" here currently means anything that's not from the registry, so
anything inside the workspace, but also path dependencies. So this isn't
perfect, and users might still need to use
`rust-analyzer.cargo.unsetTest` for these in some cases.
internal: Lift out IdentContext from CompletionContext
Makes things a bit messy overall, but with this I can start cleaning up the render functions properly now.
cc https://github.com/rust-lang/rust-analyzer/issues/12571
