Skip to content

No error for setter with self-referential, implicit any argument #48432

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
gabritto opened this issue Mar 26, 2022 · 1 comment · Fixed by #48459
Closed

No error for setter with self-referential, implicit any argument #48432

gabritto opened this issue Mar 26, 2022 · 1 comment · Fixed by #48459
Assignees
Labels
Bug A bug in TypeScript Fix Available A PR has been opened for this issue

Comments

@gabritto
Copy link
Member

Bug Report

A setter can have an argument with a self-referential annotation, and this argument will implicitly have type any, with TS producing no errors for it.

🔎 Search Terms

setter, implicit any

🕗 Version & Regression Information

As far back as 4.3 (when we first let setters/getters in type literals).

⏯ Playground Link

Playground link with relevant code

💻 Code

declare var y: {
    set prop2(arg: typeof y.prop2);
};

🙁 Actual behavior

We don't get any errors, even with noImplicitAny set.
But arg has implicitly type any, because its type annotation refers to the type of the setter itself, and there are no getters.

🙂 Expected behavior

An error on prop2 or arg, at least under noImplicitAny.

@ahejlsberg ahejlsberg added the Bug A bug in TypeScript label Mar 27, 2022
@ahejlsberg ahejlsberg self-assigned this Mar 27, 2022
@ahejlsberg
Copy link
Member

Actually, an error is reported, but the error message is misleading and is reported as a global error because the logic attempts to report on the get accessor, but there isn't one. So, several things are wrong here.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
Bug A bug in TypeScript Fix Available A PR has been opened for this issue
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants