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

Improve narrowing of generic types constrained to unknown #60816

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

Andarist
Copy link
Contributor

@typescript-bot typescript-bot added the For Uncommitted Bug PR for untriaged, rejected, closed or missing bug label Dec 19, 2024
@typescript-bot
Copy link
Collaborator

This PR doesn't have any linked issues. Please open an issue that references this PR. From there we can discuss and prioritise.

@@ -30498,6 +30503,7 @@ export function createTypeChecker(host: TypeCheckerHost): TypeChecker {
return type;
}

const originalType = type;
type = getNarrowableTypeForReference(type, node, checkMode);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there are 2 other calls to getNarrowableTypeForReference that are now not accompanied by this recombineUnknownType dance. Before landing this, I should recheck both to see if that's OK.

One of them is in checkReturnExpression - @gabritto do you have an opinion about this? This fix improves this scenario:

// this one doesn't work without this fix
function test1<T extends unknown>(
  x: T,
): T extends {} ? {} : T extends Nullable ? Nullable : never {
  if (x == undefined) {
    return x;
  } else {
    return x;
  }
}

type Nullable = null | undefined;

// this one works
function test2<T extends {} | Nullable>(
  x: T,
): T extends {} ? {} : T extends Nullable ? Nullable : never {
  if (x == undefined) {
    return x;
  } else {
    return x;
  }
}

but since the returned type can't "escape" the return statement, it feels redundant to recombine that unknown type there

Comment on lines -42 to -43
// a2 is not narrowed
a2.x // error, but should be ok
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

those were outdated comments, as we can see here - no errors are reported here (rightfully so). I took the liberty to fix those here

Comment on lines +45 to +48
const y: null | undefined = x; // ok
~
!!! error TS2322: Type 'T' is not assignable to type 'null | undefined'.
!!! related TS2208 narrowUnknownByTypePredicate.ts:37:14: This type parameter might need an `extends null | undefined` constraint.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one really shouldn't error and it should 100% behave like the other case added here. I could work on this further - but like, the simplest potential fix would be to... return unknownType from getBaseConstraintOfType when constraint === noConstraintType. I'll try to do that but I expect that there might be some reason why that isn't unified already like this despite the fact that constraint of an unconstrained type parameter is unknown (in TS files)

x: T,
): T extends Nullable ? Nullable : never {
if (x == undefined) {
return x;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in theory, this shouldn't report an error but this code is just awfully non-sensical, I only have added it as extra precautions against potential crashes (that didn't happen - but somewhat only because some helper is OK with undefined argument)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
For Uncommitted Bug PR for untriaged, rejected, closed or missing bug
Projects
Status: Not started
Development

Successfully merging this pull request may close these issues.

2 participants