Skip to content

Conversation

@ahejlsberg
Copy link
Member

This PR tweaks our inference logic to only check type parameter constraints in the final phase of type argument inference (and specifically not in the phase where contextually sensitive arguments are excluded). Checks prior to the final phase otherwise can cause inferences to become fixed when constraints are self-referential.

Fixes #29520.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~
!!! error TS2554: Expected 2 arguments, but got 1.
!!! related TS6210 tests/cases/compiler/spreadOfParamsFromGeneratorMakesRequiredParams.ts:3:5: An argument for 'args' was not provided.
!!! error TS2345: Argument of type '[]' is not assignable to parameter of type 'never'.
Copy link
Member

Choose a reason for hiding this comment

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

So this swapped from an arity error to an assignability error because...? I would have assumed the arity error was preferable here. As written, there's no never or [], so I'm really not sure what I'd need to change to fix this error.

Copy link
Member Author

Choose a reason for hiding this comment

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

The never comes from Parameters<T> when T isn't a function type. Neither error is particularly great, but the new error message is in some sense more correct. And, if you add a second argument in an attempt to fix the old error message, you're just greeted with the new error message.

Copy link
Member

Choose a reason for hiding this comment

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

Ahh.... But a generator is a function type. You call it and get back an iterator, just like how you call an async function and get a promise. This error is straight wrong, then.

@ahejlsberg
Copy link
Member Author

Latest commits switch to a simpler strategy. We now use a new InferenceFlags.NoFixing flag to disable type parameter fixing during the check that validates inferences against the type parameter constraint. This means self-referential constraints use whatever has been inferred so far, but allow further inferences to be made in a later inference phase.

@ahejlsberg
Copy link
Member Author

The baseline change in jsdocTemplateTag3.types is an unrelated issue that so happens to be affected by the deferred type parameter fixing. The cause of this issue is that we aren't correctly reasoning about type parameters declared in JSDoc comments when determining whether a type parameter is possibly referenced in an anonymous object type (the isTypeParameterPossiblyReferenced function). Effectively, we always assume they're possibly referenced, even when we can detect they're not. Because we think they're referenced, they get fixed when we instantiate a anonymous object type in their constraint--but with the change in this PR we disable the fixing. Upshot is that the test now behaves correctly where it wasn't before.

@ahejlsberg ahejlsberg merged commit 8827bed into master Feb 1, 2019
@ahejlsberg ahejlsberg deleted the noConstraintsDuringInference branch February 1, 2019 18:54
@microsoft microsoft locked as resolved and limited conversation to collaborators Oct 21, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Arrow functions treated differently than functions and methods

4 participants