getConstraintDeclaration gets the first declaration with a constraint…

[weswigham]

…, rather than just the first declaration

Fixes #33395

@HerringtonDarkholme if you're still watching, what was the original justification for this to be order dependent, anyway? You just commented that it was and it was just.... accepted. It leads to some odd and hard to understand behavior, as in #33395.

[HerringtonDarkholme]

Thanks for letting me know! My OSS participation is bogged by day job and other stuffs in real life. But it's so nice to be mentioned here again!

The typical usage for skipping constraint check is that library author used to release a definition where an interface has no constraint, and later the author changed to impose constraint on type parameter. So library user won't break existing interface merging in which no constraint presents.

I remember I don't want to deal with order. Also, interface merging is used by user to augment library definition. In user side it is more likely to relax constraint than adding constraints. It is unlikely a more generic function will be "augmented" to accept fewer type parameter.

Lodash usage from #33395 (comment) isn't considered that time. This change should also allow changing interface from having constraint to no constraint.

[weswigham]

This change should also allow changing interface from having constraint to no constraint.

Not quite - this change make sure such that if any declaration we found was constrained, the type parameter is seen as constrained. You can't erase the constraint (though if a definition is valid for a constraint-less type it's... usually... valid for a type with a constraint)

[DanielRosenwasser]

@typescript-bot cherry-pick this to release-3.6

[typescript-bot]

Hey @DanielRosenwasser, I've opened #33512 for you.