Dead semicolons ;-)

[eernstg]

Thanks to @modulovalue for noticing this situation in #54271. Consider the following library:

class A {
  var x;
  A() : x = throw 0;
}

The analyzer reports that the semicolon after 0 is dead code. This is presumably a very precise characterization of the situation because the semicolon could be considered to be the body of the constructor, and the body is dead code when an initializer element is known to throw.

However, the advice starts with "Try removing the code", and that won't help much because the resulting code then has a syntax error.

Perhaps we could report just the remaining advice in this case: "Try fixing the code before it so that it can be reached".

[modulovalue]

This can also be observed here:

void foo() {
  if (false) {
    print("0");
  }
}

The whole block is reported as dead code with the error message: Try removing the code, or fixing the code before it so that it can be reached.

However, the advice starts with "Try removing the code", and that won't help much because the resulting code then has a syntax error.

Removing the whole block would also produce a program that has a syntax error.

[srawlins]

Perhaps we could report just the remaining advice in this case: "Try fixing the code before it so that it can be reached".

@eernstg I'm confused; why should we report anything? I think no dead code should be reported in your example. It is a valid program if you follow it with void main() => A();.

[bwilkerson]

... why should we report anything?

I agree. It seems reasonable to not report the body of a constructor if it's empty, even though the body can't be reached, because the body is required to exist. If there were statements inside a block body then I think it would be reasonable to report those statements as being dead code.

Whether we should have some (different) way of reporting that the constructor will never return is an interesting question, but reporting it as dead code seems like the wrong solution.

The whole block is reported as dead code ...

It does seem like we ought to be reporting the content of the block, not the whole block in that case, even though lexically the block is a statement and that whole statement can't be reached. I suspect that most users don't think of those blocks as being statements, just holders for statements.

[eernstg]

... why should we report anything?

Right, I agree on that, too. We don't report anything about a function body that is guaranteed to throw, it is only the case where a non-empty amount of computation is specified, but it is known that it will never be executed. In other words, we only report dead code that does something, even in the case where you could say that a specific portion of dead code does not do anything, but it still has some syntactic representation (like {} or ;).

So the reasonable approach for this situation would presumably be to just stop reporting anything.