Skip to content
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

Make never rest type top-like #35438

Merged
merged 4 commits into from Mar 30, 2020

Conversation

jack-williams
Copy link
Collaborator

@jack-williams jack-williams commented Dec 2, 2019

Not an actual fix as the issue is still under discussion. Figured I’d put up and implementation though.

Fixes #33495

@jack-williams
Copy link
Collaborator Author

@typescript-bot test this
@typescript-bot user test this

@typescript-bot
Copy link
Collaborator

typescript-bot commented Dec 2, 2019

Heya @jack-williams, I've started to run the extended test suite on this PR at 76bc82b. You can monitor the build here. It should now contribute to this PR's status checks.

@typescript-bot
Copy link
Collaborator

typescript-bot commented Dec 2, 2019

Heya @jack-williams, I've started to run the parallelized community code test suite on this PR at 76bc82b. You can monitor the build here. It should now contribute to this PR's status checks.

@typescript-bot
Copy link
Collaborator

The user suite test run you requested has finished and failed. I've opened a PR with the baseline diff from master.

@weswigham weswigham closed this Dec 2, 2019
@weswigham weswigham reopened this Dec 2, 2019
Copy link
Member

@weswigham weswigham left a comment

Choose a reason for hiding this comment

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

Makes a lot of sense to me - making never behave as any already did here seems to work. Can we also see a test for the nested case, eg

function assignmentWithComplexRest2<T extends any[]>() {
    const fn1: (cb: (x: string, ...rest: T) => void) => void = (cb) => {};
    const fn2: (cb: (...args: never) => void) => void = fn1;
}

which should error, I believe?

@jack-williams
Copy link
Collaborator Author

which should error, I believe?

Yep, added!

@sandersn sandersn added this to Curio in Pall Mall Jan 30, 2020
@sandersn sandersn added the For Backlog Bug PRs that fix a backlog bug label Feb 3, 2020
@sandersn sandersn added Experiment A fork with an experimental idea which might not make it into master and removed For Backlog Bug PRs that fix a backlog bug labels Mar 9, 2020
@sandersn sandersn added this to Not started in PR Backlog via automation Mar 9, 2020
@sandersn sandersn removed this from Curio in Pall Mall Mar 9, 2020
@sandersn sandersn moved this from Not started to Needs review in PR Backlog Mar 9, 2020
@sandersn sandersn added For Uncommitted Bug PR for untriaged, rejected, closed or missing bug and removed Experiment A fork with an experimental idea which might not make it into master labels Mar 9, 2020
PR Backlog automation moved this from Needs review to Needs merge Mar 30, 2020
@jack-williams
Copy link
Collaborator Author

Thanks for powering through all these PR's @sandersn and @weswigham!

@weswigham weswigham merged commit 0e15b9f into microsoft:master Mar 30, 2020
PR Backlog automation moved this from Needs merge to Done Mar 30, 2020
@andrewbranch
Copy link
Member

Was it known that this makes (...args: never) => unknown callable? #48840

@jack-williams
Copy link
Collaborator Author

jack-williams commented Apr 26, 2022

Short answer: no. That function type should not be callable.

Longer answer: After looking through this again last night and trying to fix it, I do vaguely remember looking at that behaviour before. I think the code to trigger the error was move involved and touched a couple of the signature checking functions. I guess I never got around to resolving that and when the PR was revived, I had forgotten.

I started working on a fix yesterday. Haven't run it through perf and regression test. I do not think it is a big change. Also happy for someone to pick it up.

@andrewbranch
Copy link
Member

Thanks @jack-williams, wasn’t expecting you to pick up a fix, just searching for info, but appreciate it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
For Uncommitted Bug PR for untriaged, rejected, closed or missing bug
Projects
PR Backlog
  
Done
Development

Successfully merging this pull request may close these issues.

never rest type not assignable to complex rest type
5 participants