INSP: Implement unreachable code detection

[artemmukhin]

This PR introduces Unreachable code inspection to detect and remove unreachable code.

Note that now it might produce some false-positive warnings due to #6749 and #6797, so probably it's better to try fixing these issues before merging this.

Some implementation details:

• Based on the control-flow graph which is already used for several inspections (move analysis, liveness analysis)
• Found unreachable elements are cached by org.rust.lang.core.types.ExtensionsKt#CONTROL_FLOW_KEY as well as the graph itself
• Does not highlight each unreachable element separately, but merges their text ranges instead in order to highlight the widest range

Part of #1612.

changelog: Add Unreachable code inspection and quick-fix

[artemmukhin]

Note, although no regressions are found with CI (because the regression tests only search for error annotations, not warnings), there are some false positive warnings in real projects, mostly due to #6749, as I mentioned in the PR description.

Here is what I found:

• cargo: no false-positive warnings
• diesel: 1 file affected due to unsupported #[allow(warnings)] attribute Compiler lints support #5888
• tokio: 3 files affected due to Incorrectly inferred never type of match expression with diverging arm #6749, 1 file affected due to an unevaluated cfg option
• rust-analyzer: 4 files affected due to Incorrectly inferred never type of match expression with diverging arm #6749

As we just briefly investigated with @vlad20012, CoerceMany should be implemented in order to fix #6749. Currently, IJ Rust uses a simplified and rough approach to handle this (see RsTypeInferenceWalker#getMoreCompleteType). So #6749 is probably not very easy to fix right now, and I don't know a good and simple workaround to avoid analyzing such problematic match expressions since many of them are expanded from macros.

However, I think we can merge this inspection because the number of false positives is not so much. @Undin WDYT?

[Undin]

However, I think we can merge this inspection because the number of false positives is not so much. @Undin WDYT?

As we've discussed in person - let's try to fix type inference first not to introduce new false positive annotations for users. Looks like we can come up with at least some hack to make type inference work in described cases.
As an alternative solution, I may suggest merging the inspection right now but disabled by default. And enable it when type inference will be fixed. It may help to avoid merge conflicts

[Undin]

@ortem BTW tests fail

[Undin]

@ortem #6749 is fixed so I suppose we can merge this PR

[artemmukhin]

@Undin I'd like not to merge this PR right now because some false-positive warnings remained, with #6749 fixed:

• cargo: no false-positive warnings
• diesel: 1 file affected due to unsupported #[allow(warnings)] attribute Compiler lints support #5888
• tokio: 2 files are still affected due to tokio::select! macro, 1 file affected due to an unevaluated cfg option
• rust-analyzer: no false-positive warnings

So the most interesting case is tokio. I've found a problem with the processing of break expanded from a macro:

macro_rules! break_macro {
    () => { break };
}

fn main() {
    loop {
        break_macro!();
    }
    1; // false-positive "unreachable"
}

I'm investigating the problem. If I don't find a solution soon then I'll disable the inspection by default and merge this PR.

[artemmukhin]

I opened an issue for this case: #7016.
Now it is fixed and there are no false positives with tokio::select! macro in tokio. So this can be merged I suppose.

[Undin]

@ortem don't insist but I'd personally prefer to create a separate PR for #7016. For example, it's convenient for changelog creation

[artemmukhin]

bors r=dima74

[bors]

This PR was included in a batch that timed out, it will be automatically retried

[bors]

Build succeeded:

• check