Handle parentless nodes in isParameterPropertyDeclaration#33321
Conversation
|
CC @rbuckton and @weswigham, whose PR I'm shamelessly copying here :-) Also fixes angular/tsickle#1065. |
d3d2895 to
f272ec2
Compare
|
@DanielRosenwasser you proooobably want to accept this and merge into a 3.6 patch release, assuming there will be one. |
|
@weswigham / @DanielRosenwasser what's the next step here, do I need to do something? |
|
Sorry, thought this was merged because I was on mobile. Can you fix conflicts and create a separate PR to release-3.6? |
Fixes microsoft#33295. This follows a similar pattern as in microsoft#20314 by requiring an explicit `parent` parameter. Where possible, it uses the appopriate variable at the call sites. In several locations there is no context available though (e.g. inspecting `valueDeclarations`) and we access `.parent` as the code previously did. From a cursory inspection this seems correct, these callpaths originate in phases where there must be a `parent` (i.e. in checker, binder, etc). Change-Id: I28e4726777b57237bec776e4001e9e69ac591b11
cee129d to
e8be5e8
Compare
|
It looks like you've sent a pull request to update our 'lib' files. These files aren't meant to be edited by hand, as they consist of last-known good states of the compiler and are generated from 'src'. Unless this is necessary, consider closing the pull request and sending a separate PR to update 'src'. |
|
@DanielRosenwasser done, this is now a single commit on top of |
Fixes #33295.
This follows a similar pattern as in #20314 by requiring an explicit
parentparameter. Where possible, it uses the appopriate variable atthe call sites.
In several locations there is no context available though (e.g.
inspecting
valueDeclarations) and we access.parentas the codepreviously did. From a cursory inspection this seems correct, these
callpaths originate in phases where there must be a
parent(i.e. inchecker, binder, etc).
Change-Id: I28e4726777b57237bec776e4001e9e69ac591b11