Give more helpful error when trying to set default values on an interface. #5736
Conversation
Give more helpful error when trying to set default values on an interface
|
Hi @delta-nry, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution! TTYL, MSBOT; |
DanielRosenwasser
changed the title
|
Hey @delta-nry - thanks for the PR. I notice that there's no test case affected - can you add a few tests as per our contribution guidelines? |
|
Thanks for the quick reply @DanielRosenwasser. As I am part of a group of students from the University of British Columbia, I am waiting for my partners to implement the test case(s) you requested. Thus, we may get back to you sometime within two weeks. Thank you for your patience on resolving this PR. |
|
No worries, just keep us posted since GitHub doesn't send updates for new commits. |
|
@delta-nry, Thanks for signing the contribution license agreement so quickly! Actual humans will now validate the agreement and then evaluate the PR. |
|
I have implemented the required tests. In the interest of full disclosure, I am the sole person who implemented these tests and none of the content of these tests are original works of my partners. Thank you for your patience regarding this issue. |
|
|
||
| // Although object type properties cannot not have initializers, we attempt to parse an initializer | ||
| // so we can report that an object type property cannot have an initializer. | ||
| if (token === SyntaxKind.EqualsToken && lookAhead(() => parseNonParameterInitializer()) !== undefined) { |
There was a problem hiding this comment.
You can just pass parseNonParameterInitializer to lookahead. Testing truthiness is fine here, and you'll avoid allocating a closure.
There was a problem hiding this comment.
I would not do it this way. I would just parse out an initializer for these properties. Then, in the checker, detect that and report a nice error there.
We do not want random errors being produced the parser like this.
The benefit of this is that now our tree is well formed. And you can do things like format the tree nicely and have the rest of our features not barf when this is encountered.
There was a problem hiding this comment.
So to summarize @delta-nry, just add an optional initializer onto each PropertySignature and perform a grammar check in checker.ts on each property. Report the error on the initializer or the node itself.
|
@CyrusNajmabadi can you take a quick look? |
|
|
||
| ==== tests/cases/compiler/errorOnInitializerInObjectType.ts (2 errors) ==== | ||
| interface Foo { | ||
| bar: number = 5; |
There was a problem hiding this comment.
I'm surprised that we don't go off the rails here since you're not advancing the parser at all (i.e. you use lookAhead, not tryParse).
There was a problem hiding this comment.
Actually, this is because the parser tries to be smart and avoids reporting more errors at the same start position. I'm not sure if that's the right thing to do because instead of gracefully parsing the invalid initializer, the parser can start going haywire down the line. Maybe tryParse would be better? What do you think @CyrusNajmabadi?
There was a problem hiding this comment.
We should just allow initializers. This is a pretty reasonable thing for a user to type, so the tree shoudl just be flexible enough to represent it. We can hten have a simple grammar check in the type checker that reports that thsi isn't legal.
| @@ -16085,6 +16095,18 @@ namespace ts { | |||
| } | |||
| } | |||
|
|
|||
| if (node.type) { | |||
There was a problem hiding this comment.
You should be performing this check in any type literal, not just those in variable like declarations.
I think you should just move the check into checkGrammarProperty, and discriminate on whether you have a PropertySignature with an initializer.
|
@delta-nry, I left some feedback. Basically, you should perform the grammar check in |
| !!! error TS1005: '=' expected. | ||
| ~~~ | ||
| !!! error TS2304: Cannot find name 'bar'. | ||
| ~ |
There was a problem hiding this comment.
I'm not sure if we should accept these errors, as the '=' expected message implies that initializers are allowed in this case. Maybe we should spin this off into a new issue. @DanielRosenwasser @CyrusNajmabadi, what are your thoughts on this?
There was a problem hiding this comment.
It should be sufficient if you make it so that you only try to parse an initializer if the current token is a =.
|
@DanielRosenwasser, @CyrusNajmabadi how do these fixes look? |
| "category": "Error", | ||
| "code": 1246 | ||
| }, | ||
| "An object type literal property cannot have an initializer.": { |
There was a problem hiding this comment.
Sorry I didn't notice it earlier, but this should be "A type literal property"
|
I think this is great - just address the last comments I left and we should be good to merge. 😃 |
|
💯 |
Give more helpful error when trying to set default values on an interface.
Fixes #5173 - Give more helpful error when trying to set default values on an interface.