Avoid inferring return and yield types from unreachable statements #55601
Conversation
typescript-bot
added
the
For Uncommitted Bug
|
The TypeScript team hasn't accepted the linked issue #55437. If you can get it accepted, this PR will have a better chance of being reviewed. |
|
I needed this just the other day. |
|
@typescript-bot test top200 |
|
Heya @jakebailey, I've started to run the diff-based user code test suite on this PR at fa99df8. You can monitor the build here. Update: The results are in! |
|
Heya @jakebailey, I've started to run the regular perf test suite on this PR at fa99df8. You can monitor the build here. Update: The results are in! |
|
Heya @jakebailey, I've started to run the tarball bundle task on this PR at fa99df8. You can monitor the build here. |
|
Heya @jakebailey, I've started to run the diff-based top-repos suite on this PR at fa99df8. You can monitor the build here. Update: The results are in! |
|
Heya @jakebailey, I've started to run the parallelized Definitely Typed test suite on this PR at fa99df8. You can monitor the build here. Update: The results are in! |
|
Hey @jakebailey, I've packed this into an installable tgz. You can install it for testing by referencing it in your and then running There is also a playground for this build and an npm module you can use via |
|
@jakebailey Here are the results of running the user test suite comparing There were infrastructure failures potentially unrelated to your change:
Otherwise... Everything looks good! |
|
@jakebailey Here they are:
CompilerComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
tsserverComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
StartupComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
Developer Information: |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
@jakebailey Here are the results of running the top-repos suite comparing Everything looks good! |
|
Hey @jakebailey, the results of running the DT tests are ready. |
|
This doesn't really work for assertion functions right? Can you add a few tests around that? function throws(): never {
throw new Error();
}
export function foo() {
throws();
return 42;
}
export function bar() {
var x;
x = 1;
if (Math.random()) {
throws();
return x;
}
x = 2;
return x;
} |
|
Should I just codify the current results in the test suite or would you expect those cases to work differently? It would be possible to achieve different results for them, right? I'm not sure if that's totally desirable from your PoV though. |
| @@ -36286,6 +36286,10 @@ export function createTypeChecker(host: TypeCheckerHost): TypeChecker { | |||
| const nextTypes: Type[] = []; | |||
| const isAsync = (getFunctionFlags(func) & FunctionFlags.Async) !== 0; | |||
| forEachYieldExpression(func.body as Block, yieldExpression => { | |||
| const statement = findAncestor(yieldExpression, isStatement)!; | |||
| if (canHaveFlowNode(statement) && !statement.flowNode && !compilerOptions.allowUnreachableCode) { | |||
There was a problem hiding this comment.
Out of curiousity, why flag this on allowUnreachableCode? My impression is that allowUnreachableCode is more like a lint rule that errors on the unreachable code, and not something that should impact type analysis.
There was a problem hiding this comment.
I honestly have no idea cause I've written it half a year ago 😅
If the tests would come roughly unchanged without this condition (which is likely) then maybe I just have tried to be conservative when it comes to the impact of this change. Taking a look at how allowUnreachableCode is defined in the docs now - you are right that this flag should mostly just affect error reporting.
closes #55437