Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

functions returning never are not treated the same as raw throw calls in control-flow analysis #9655

Closed
rkirov opened this issue Jul 12, 2016 · 1 comment
Labels
Design Limitation Constraints of the existing architecture prevent this from being fixed

Comments

@rkirov
Copy link
Contributor

rkirov commented Jul 12, 2016

TypeScript Version: 2.0.0-beta

Code

function fail(): never {
  throw 'error';
}

enum E {
  A,
  B
}
function f(t: E) {
  let s: string;
  switch (t) {
    case E.A:
      s = 'a';
      break;
    case E.B:
      s = 'b';
      break;
    default:
      fail();  // but replacing with "throw 'error"' removes the TS error.
  }
  s += '';
}

Expected behavior:
s += '' is allowed because all terminating (non-throwing) branches assign to s.

In general, I am working under the assumption that calling functions that returning never are equivalent to raw throw calls during control-flow analysis.

Actual behavior:
ERROR(21,3): : Variable 's' is used before being assigned.

@RyanCavanaugh RyanCavanaugh added the Design Limitation Constraints of the existing architecture prevent this from being fixed label Jul 12, 2016
@RyanCavanaugh
Copy link
Member

RyanCavanaugh commented Jul 12, 2016

The limitation here has to do with the way the compiler is designed -- control flow analysis happens before typechecking, but we would need type information (as well as identifier resolution) to determine that the fail() call points to a function that is : never, so the s += ''; node is marked as reachable via a path that doesn't assign to s.

The intended fix is to write return fail(); instead of fail();.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Design Limitation Constraints of the existing architecture prevent this from being fixed
Projects
None yet
Development

No branches or pull requests

3 participants