Expand constraint suggestion related span and add quick fix

[weswigham]

This expands the originally very narrow elaboration to be reported any time an unconstrained type parameter is related to something, and adds a quickfix to apply the change.

[RyanCavanaugh]

@typescript-bot pack this

[typescript-bot]

Heya @RyanCavanaugh, I've started to run the tarball bundle task on this PR at 00ef5ae. You can monitor the build here.

[typescript-bot]

Hey @RyanCavanaugh, I've packed this into an installable tgz. You can install it for testing by referencing it in your package.json like so:

{
    "devDependencies": {
        "typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/127860/artifacts?artifactName=tgz&fileId=598827D61D0342AD0F9999019F7660B392F62AE485A78FB74B15AED9C2CF8C1F02&fileName=/typescript-4.8.0-insiders.20220610.tgz"
    }
}

and then running npm install.

---

There is also a playground for this build and an npm module you can use via "typescript": "npm:@typescript-deploys/pr-build@4.8.0-pr-49481-2".;

[RyanCavanaugh]

Most of the breaks I saw looked like this, which currently isn't quickfixable. Can we expand it?

interface Fn<T extends string> {
}

function m<T>(x: Fn<T>) {
}

[weswigham]

Can we expand it?

Sure, should be easy - just another error code in the quickfix hopefully, since it uses a custom head message on the assignability error.

[weswigham]

@RyanCavanaugh done. There are a lot of custom head messages for relation errors, and thus, many error codes we could conceivably add to this quickfix. I don't claim the current list to be exhaustive, just the ones I read in the core reportRelationError function. 😅

[RyanCavanaugh]

@typescript-bot pack this

[typescript-bot]

Heya @RyanCavanaugh, I've started to run the tarball bundle task on this PR at d70dc0a. You can monitor the build here.

[typescript-bot]

Hey @RyanCavanaugh, I've packed this into an installable tgz. You can install it for testing by referencing it in your package.json like so:

{
    "devDependencies": {
        "typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/127897/artifacts?artifactName=tgz&fileId=32B3A22AB17DD45B6358503B57C35FED620753775DE1BF65C16A33E45EAF8FAD02&fileName=/typescript-4.8.0-insiders.20220610.tgz"
    }
}

and then running npm install.

---

There is also a playground for this build and an npm module you can use via "typescript": "npm:@typescript-deploys/pr-build@4.8.0-pr-49481-8".;

[andrewbranch]

(This isn’t the first time it would have been nice to be able to register a codefix against a related error instead of the head message.)

[andrewbranch]

We should keep an eye out for how often the related diagnostic / quick fix is the correct fix in real world code since it seems to be showing up a lot more often.

[weswigham]

We should keep an eye out for how often the related diagnostic / quick fix is the correct fix in real world code since it seems to be showing up a lot more often.

It's any time you assign an unconstrained type parameter to something, so potentially pretty often. Conversely, it's probably got a pretty high success rate, I think. The other way you'd have to take the fix is changing the target type's position to unknown, which seems.... probably not what you wanted if you're using type parameters. I think the misses are moreso places where it suggests a constraint, and then the suggested constraint is insufficient because the source is related to multiple target types (but we don't know that yet because we bail on the first error we find).

[weswigham]

Notably, that failure mode does imply another, narrower, potentially useful quickfix - if a constrained type parameter fails being related to some target type, suggesting the target type be intersected into the constraint of the source type parameter is potentially a good fix. Unfortunately, a large corpus of code with errors isn't exactly something we have to know how useful such a fix would be.