Analyzer does not consistently consider invocations on `Never` to have type `Never`.

[stereotype441]

The NNBD spec says:

Calling a method (including an operator) or getter on a receiver of static type Never is treated by static analysis as producing a result of type Never. Tearing off a method from a receiver of static type Never produces a value of type Never. Applying an expression of type Never in the function position of a function call produces a result of type Never.

Assuming "operator" means "user-definable operator" (i.e. not &&, ||, or ??), then as far as I can tell, the CFE implements this faithfully.

The analyzer is inconsistent, though:

• expr1 operator expr2, where expr1 has static type Never, has static type Never, as specified.
• expr(args), where expr has static type Never, has static type Never, as specified.
• expr.identifier(args), where expr has static type Never, has static type Never, as specified.
• identifier1.identifier2, where identifier1 has static type Never, has static type Never, as specified.
• expr.identifier, where expr is an expression having static type Never, but is not a simple identifier, behaves as follows:
  • If identifier is hashCode, toString, runtimeType, or noSuchMethod, the type is the same as it would be if the receiver type were Object (e.g. (throw '').toString has type String Function()).
  • Otherwise, the type is InvalidType, but no error is issued.
• In an extension whose on type is Never, identifier and identifier(args) are treated the same as they would be treated if the on type were Object.

[stereotype441]

I'm working on some refactoring that would benefit from fixing this, so I'll work on a fix. Note that the fix will be a non-breaking change, since it will bring the analyzer into alignment with the CFE.

[lrhn]

Assuming "operator" means "user-definable operator"

It does here since it refers to "method (including an operator)" so it's about operators which are also instance methods.
Probably except == which always has type bool.

(Although it could safely apply to the rest too, if the first operand has type Never, the entire expression could soundly have type Never.)

Every place where a non-Never, non-dynamic invocation would use the member signature of the member on the receiver type to infer the result type, an invocation on Never has result type Never, no bounds for type arguments and no context type or required type for arguments.

"Tearing off a method from a receiver of static type Never produces a value of type Never. "

That's a little misleading. It's an unspecified member access. It's impossible to say whether a member access on Never targets a getter or a method. In fact, it's definitely neither.

Anyway, seems like the analyzer refused a little more of the behavior of dynamic.
The only real problem with that is inconsistency, it'll never cause a runtime problem (he says confidently).