-
Notifications
You must be signed in to change notification settings - Fork 12.8k
Possible regression in overloads with optional this
types in callbacks
#53080
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
Comments
FYI @Andarist |
@jakebailey thanks for the ping, I'll try to investigate this to understand what has happened here. This regression is definitely surprising since there is no spread involved here. |
@chriskrycho Did you bisect to the PR in particular, or do you only know the nightly revisions? |
I bisected it just now and the culprit is this one: #52387 |
Ah, I only knew nightly revisions—I missed 52387 in my history review (PR history vs. Git history fail), and hadn't yet gotten down to bisecting individual commits. Sorry for the misdirection! |
If you replace I think this is the correct solution here. With this change the -type CheckCandidate = (target: Foo, method: (this: Foo, ...args: any[]) => any, ...args: never): (...args: never) => any
+type CheckCandidate = (target: Foo, method: (this: Foo, ...args: any[]) => any): (...args: any[]) => any And that new one makes more sense here. At this point we already know that there are no extra arguments and when spreading |
Thanks! |
While this got fixed in Ember types... I wonder how many more such reports we will get. Hopefully not many, I think this case was slightly off from the beginning but it was also relatively easy to make such a mistake. The time will tell. |
I agree that the original implementation was wrong, but unfortunately I suspect it’s semi-common, as the contributor who landed it in our types drew heavily on a Stack Overflow answer. I reviewed it when it landed, but did not notice the underlying issue originally or even when re-evaluating it yesterday. It’s quite subtle and it required basically doing the full “type check” pass mentally to see the issue. |
And this is why we're merging all of this ASAP 😄 |
Bug Report
I believe
#52838#52387 is the cause of a “regression” in Ember’s type test suite, but I also am very willing to believe that this is a bug in how Ember’s types are written which this change caught, but I wanted to flag it up.Here's the type test (source):
Here's the set of overloads, including the implementation overload (source):
Prior to this change, this type checked. After this change, it reports:
Prior to this change, it was resolving against the first overload:
I have tried adding an overload which has the same form but does not explicitly include the
this
type on theF
constraint, but at that point I'm in overload-ordering hell.🔎 Search Terms
🕗 Version & Regression Information
This changed between versions
5.1.0-dev.20230301
and5.1.0-dev.20230302
.⏯ Playground Link
Playground link with relevant code
💻 Code
🙁 Actual behavior
Wellllll the overload isn't working anymore.
🙂 Expected behavior
I think I expected this overload to keep working.
The text was updated successfully, but these errors were encountered: