-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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
Ensure rest type for source parameter is readonly in relations #53258
Conversation
@typescript-bot test this |
Heya @jakebailey, I've started to run the abridged perf test suite on this PR at 5f7155d. You can monitor the build here. Update: The results are in! |
Heya @jakebailey, I've started to run the diff-based top-repos suite on this PR at 5f7155d. You can monitor the build here. Update: The results are in! |
Heya @jakebailey, I've started to run the diff-based user code test suite on this PR at 5f7155d. You can monitor the build here. Update: The results are in! |
Heya @jakebailey, I've started to run the extended test suite on this PR at 5f7155d. You can monitor the build here. |
Heya @jakebailey, I've started to run the parallelized Definitely Typed test suite on this PR at 5f7155d. You can monitor the build here. Update: The results are in! |
Heya @jakebailey, I've started to run the tarball bundle task on this PR at 5f7155d. You can monitor the build here. |
Hey @jakebailey, I've packed this into an installable tgz. You can install it for testing by referencing it in your
and then running There is also a playground for this build and an npm module you can use via |
@jakebailey Here are the results of running the user test suite comparing Everything looks good! |
@jakebailey Here they are:Comparison Report - main..53258
System
Hosts
Scenarios
Developer Information: |
Hey @jakebailey, it looks like the DT test run failed. Please check the log for more details. |
@jakebailey Here are the results of running the top-repos suite comparing Everything looks good! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this doesn't change applyToParameterTypes
, this doesn't change inference, so won't be observable to a Parameters
conditional call - you'll only see the difference in relationship error messages bewteen signatures. And maybe that's OK. It's s little weird to say that variadic rests are sometimes-readonly-sometimes-not, but... function parameters are pretty wonky on the edges as-is.
Yeah, this is just a case where inference is already right (the insides don't change). Would my alternative suggestion of stripping |
In general, I'm also having trouble seeing where anyone would ever want the result of |
Actually, I'm even more weirded out, because in my example above
So, shouldn't we be stripping readonly in every case from rest arrays? That seems like the right fix... |
I mean, maybe I guess this fix is okay just to get rid of the spurious relation error, and something that addresses my followup comments can come later? |
@typescript-bot run dt |
Heya @jakebailey, I've started to run the parallelized Definitely Typed test suite on this PR at 5f7155d. You can monitor the build here. Update: The results are in! |
Hey @jakebailey, it looks like the DT test run failed. Please check the log for more details. |
Seems reasonable. |
Followup is here: #53398 |
Breaks ckeditor__ckeditor5-upload on DT. Didn't notice it until today because the overnight tests were blocked by the --legacy-peer-deps problem. Filed #53459 with a 5-line, 2-type repro. |
My fault for not retrying DT until I saw the results... |
Fixes #53255
See also DefinitelyTyped/DefinitelyTyped#64739
Given:
We used to say:
Here, the "source" type is
[a: 1 | 2, b: "1" | "2"]
, but that can't be assigned to the target as the target is readonly. But, these are the rest arguments, so there's no way for this function to observe the read-only ness of the parameter. (Note: these are parameters, so directionality is swapped.)I'm not sure if this is a perfect fix, but one way to "solve" this is to just ensure the tuple/array we cook up for the source is readonly, that way it's always compatible. This fixes the issue, but does change some error messages because they do observe the intermediary type here.
Maybe the "better" thing to do here would be to strip readonly-ness from both
sourceType
andtargetType
if they were produced viagetRestTypeAtPosition
? I haven't exactly found "the way" to do that yet, e.g. no helper named "remove readonly from tuple or array".