-
Notifications
You must be signed in to change notification settings - Fork 12.6k
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
Add related error spans for getter/setters with different types #25002
Comments
Hello guys, if you could point me in the correct direction (where do I find the error messages) I will take a look at it. EDIT: If I got it right it revolves around src/compiler/diagnosticMessages.json - there you have a bunch of JS objects like
The build will generate the appropriate JS in for example tsc.js? |
The issue in the OP is about adding additional information to the error message. We have recently allowed an error message to include child messages (to add clarifications), we call these related spans. See #25359 for a similar change. |
Thank you for your reply. I built the compiler and tried the following with your code snippet from above: 4 return 100; test_accessors.ts:6:26 - error TS1005: '{' expected. 6 set foo(value: string):{} I can't get error Thank you and regards |
Try this instead: let x = {
get foo(): number { return 100; },
set foo(value: string) { }
} |
That did it! I am getting closer - could you please tell me, how to create a "blank" node? The current result looks like this (please ignore the unrelated error message about generators - this was solely for testing). Where would I create the message for the related span?
|
not sure why you are getting the error |
This was just a random error message I picked to test the behavior of my changes. |
Ahh.. take a look at #25377 then. |
To add a new error message, you need to edit https://github.com/Microsoft/TypeScript/blob/master/src/compiler/diagnosticMessages.json |
The rest of the output can stay like this? This very format? Also it seems the error handler is invoked twice, while the former aims for the getter (inteded) and the latter aims for the setter, but uses the getter error message. I will check it out ASAP. |
I'd appreciate feedback if everything went fine, please. |
Open to ideas here that have some concrete improvement |
There is no restriction on |
setters and getters MAY HAVE different types get zIndex(): string
set zIndex(value: string | number | null | undefined) Another example: class MY_URL {
get query(): Record<string, string>
set query(value: string | Record<string, string | number | null |undefined>);
}
const url = new MY_URL();
url.query = "foo=1&bar=2" // string setter
url.query = {foo: 1, bar: "2"} // Record<string, ...> setter
assert("1" === url.query.foo && "2" === url.query.bar) |
To me its a reasonable limitation that getter/setter should not have different type but this should imo. be handled by a linter rather than the compiler. What I have been thinking is that this might be related to the writeonly proposal #21759. Maybe having a type declaration such as the following could help to get a mental model for how getters/setters have different types: interface IMY_URL {
readonly query: Record<string, string>
writeonly query: string | Record <string, string | number | null | undefined>
} Another real-life example I have for this is the sketch api which does C mappings and has properties that can be set with partial objects but the getters will return filled-out instances. |
@martinheidegger that limitation is not per ECMA standards and only serves as additional gatekeeping. |
I completely agree with @acagastya and @sirian. Different setters/getters are very useful when doing normalization. /cc @sindresorhus |
Now that we support multiple related spans for errors (#10489, #22789, #24548), we'd like to improve an existing error message.
Currently, we provide a diagnostic for a pair of
get
/set
accessor's types not matching:Code:
Current error:
We'd like to give a better error message. For example:
Primary span:
Related span:
The text was updated successfully, but these errors were encountered: