-
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
Fixed a crash when inferring return type of an accessor with errors in its return statement #56258
Merged
DanielRosenwasser
merged 1 commit into
microsoft:main
from
Andarist:fix/crash-accessor-serialization
Nov 16, 2023
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
16 changes: 16 additions & 0 deletions
16
tests/baselines/reference/accessorInferredReturnTypeErrorInReturnStatement.errors.txt
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,16 @@ | ||
accessorInferredReturnTypeErrorInReturnStatement.ts(2,7): error TS7023: 'primaryPath' implicitly has return type 'any' because it does not have a return type annotation and is referenced directly or indirectly in one of its return expressions. | ||
accessorInferredReturnTypeErrorInReturnStatement.ts(4,18): error TS2339: Property 'collection' does not exist on type '{ readonly primaryPath: any; }'. | ||
|
||
|
||
==== accessorInferredReturnTypeErrorInReturnStatement.ts (2 errors) ==== | ||
export var basePrototype = { | ||
get primaryPath() { | ||
~~~~~~~~~~~ | ||
!!! error TS7023: 'primaryPath' implicitly has return type 'any' because it does not have a return type annotation and is referenced directly or indirectly in one of its return expressions. | ||
var _this = this; | ||
return _this.collection.schema.primaryPath; | ||
~~~~~~~~~~ | ||
!!! error TS2339: Property 'collection' does not exist on type '{ readonly primaryPath: any; }'. | ||
}, | ||
}; | ||
|
27 changes: 27 additions & 0 deletions
27
tests/baselines/reference/accessorInferredReturnTypeErrorInReturnStatement.js
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,27 @@ | ||
//// [tests/cases/compiler/accessorInferredReturnTypeErrorInReturnStatement.ts] //// | ||
|
||
//// [accessorInferredReturnTypeErrorInReturnStatement.ts] | ||
export var basePrototype = { | ||
get primaryPath() { | ||
var _this = this; | ||
return _this.collection.schema.primaryPath; | ||
}, | ||
}; | ||
|
||
|
||
//// [accessorInferredReturnTypeErrorInReturnStatement.js] | ||
"use strict"; | ||
Object.defineProperty(exports, "__esModule", { value: true }); | ||
exports.basePrototype = void 0; | ||
exports.basePrototype = { | ||
get primaryPath() { | ||
var _this = this; | ||
return _this.collection.schema.primaryPath; | ||
}, | ||
}; | ||
|
||
|
||
//// [accessorInferredReturnTypeErrorInReturnStatement.d.ts] | ||
export declare var basePrototype: { | ||
readonly primaryPath: any; | ||
}; |
19 changes: 19 additions & 0 deletions
19
tests/baselines/reference/accessorInferredReturnTypeErrorInReturnStatement.symbols
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,19 @@ | ||
//// [tests/cases/compiler/accessorInferredReturnTypeErrorInReturnStatement.ts] //// | ||
|
||
=== accessorInferredReturnTypeErrorInReturnStatement.ts === | ||
export var basePrototype = { | ||
>basePrototype : Symbol(basePrototype, Decl(accessorInferredReturnTypeErrorInReturnStatement.ts, 0, 10)) | ||
|
||
get primaryPath() { | ||
>primaryPath : Symbol(primaryPath, Decl(accessorInferredReturnTypeErrorInReturnStatement.ts, 0, 28)) | ||
|
||
var _this = this; | ||
>_this : Symbol(_this, Decl(accessorInferredReturnTypeErrorInReturnStatement.ts, 2, 7)) | ||
>this : Symbol(basePrototype, Decl(accessorInferredReturnTypeErrorInReturnStatement.ts, 0, 26)) | ||
|
||
return _this.collection.schema.primaryPath; | ||
>_this : Symbol(_this, Decl(accessorInferredReturnTypeErrorInReturnStatement.ts, 2, 7)) | ||
|
||
}, | ||
}; | ||
|
26 changes: 26 additions & 0 deletions
26
tests/baselines/reference/accessorInferredReturnTypeErrorInReturnStatement.types
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,26 @@ | ||
//// [tests/cases/compiler/accessorInferredReturnTypeErrorInReturnStatement.ts] //// | ||
|
||
=== accessorInferredReturnTypeErrorInReturnStatement.ts === | ||
export var basePrototype = { | ||
>basePrototype : { readonly primaryPath: any; } | ||
>{ get primaryPath() { var _this = this; return _this.collection.schema.primaryPath; }, } : { readonly primaryPath: any; } | ||
|
||
get primaryPath() { | ||
>primaryPath : any | ||
|
||
var _this = this; | ||
>_this : { readonly primaryPath: any; } | ||
>this : { readonly primaryPath: any; } | ||
|
||
return _this.collection.schema.primaryPath; | ||
>_this.collection.schema.primaryPath : any | ||
>_this.collection.schema : any | ||
>_this.collection : any | ||
>_this : { readonly primaryPath: any; } | ||
>collection : any | ||
>schema : any | ||
>primaryPath : any | ||
|
||
}, | ||
}; | ||
|
9 changes: 9 additions & 0 deletions
9
tests/cases/compiler/accessorInferredReturnTypeErrorInReturnStatement.ts
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,9 @@ | ||
// @strict: true | ||
// @declaration: true | ||
|
||
export var basePrototype = { | ||
get primaryPath() { | ||
var _this = this; | ||
return _this.collection.schema.primaryPath; | ||
}, | ||
}; |
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
I feel like it might be seen as a little bit of an ad-hoc fix. The problem is that a resolved type of a position with a cycle usually is
anyType
but when we are resolving the type initially that type is returned as an error type when the cycle is detected.So there is some small mismatch between the return values of functions like
getTypeOfAccessors
- one that depends on the timing of the call to them. I assume that this is intentional.I noticed that
getWriteTypeOfAccessors
could accidentally-ish return theerrorType
and cache it. So I tried to fix it with:That didn't fix the issue though because when this line (the one that I'm changing here) was hit for the first time we had a situation like this:
So the mismatch was still here - it just happened sooner. Originally, the mismatch could happen later when the property type already had a chance to "settle" as
anyType
but thewriteType
was already cached as theerrorType
.I think this fix is quite fine since
errorType
being returned while resolving the type initially is expected and when that happens we don't quite need to serialize the property as one with divergent accessors. Maybe some further fine-tuning can be done here. I imagine that maybe there is some value in cases that could be serialized as:I don't have a test case for that at hand though. This whole issue that is being fixed by this PR is a regression so it's worth fixing it sooner than later 😉
I also think that maybe the patch that I posted above might still be worth pulling in since caching
errorType
here looks like something that is not intended. I don't have any test case that would prove it though.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.
Maybe my memory is shot, but I kinda thought that we always returned
errorType
whenever a cycle occurred? Maybe that's just in the push/pop resolution world?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.
I don't think there is anything wrong with letting an
errorType
propagate further (or get cached or whatever). It exists to act as anany
and to specially handle more permissively in other cases.(I could be wrong!)
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.
Perhaps this is just somewhat inconsistent across different callers. I see that some similar ones are returning
errorType
just fine. However, for example here the cycle is detected anderrorType
is returned immediately but when we climb up the stack to the first "visitor" of this type thaterrorType
is converted toanyType
here. A similar situation ("converting"errorType
toanyType
) can be seen ingetTypeOfAccessors
here and ingetWriteTypeOfAccessors
here.Ye, it might not be a problem at all. I just tried to follow the pre-existing conventions in other functions.
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.
I'll prepare an experiment later that will just return/cache
errorType
in all of those locations that detect the cycle.