-
Notifications
You must be signed in to change notification settings - Fork 12.8k
Filter out classes with private members from the contextual types for object literal nodes #56183
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
base: main
Are you sure you want to change the base?
Filter out classes with private members from the contextual types for object literal nodes #56183
Conversation
… object literal nodes
@@ -5384,7 +5385,7 @@ function getApparentProperties(type: Type, node: ObjectLiteralExpression | JsxAt | |||
} | |||
|
|||
function containsNonPublicProperties(props: Symbol[]) { | |||
return some(props, p => !!(getDeclarationModifierFlagsFromSymbol(p) & ModifierFlags.NonPublicAccessibilityModifier)); | |||
return some(props, p => !!(getDeclarationModifierFlagsFromSymbol(p) & ModifierFlags.NonPublicAccessibilityModifier) || !!p.valueDeclaration && isNamedDeclaration(p.valueDeclaration) && isPrivateIdentifier(p.valueDeclaration.name)); |
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.
likely this alone (or something close to it) would fix the completion problem (private foo
is already filtered out from completions, only #foo
is not) but that wouldn't fix the contextuallyTypedParametersPositionIncludesClassWithPrivateMember
test cases
@typescript-bot test top200 @typescript-bot perf test this @typescript-bot user test tsserver |
Heya @jakebailey, I've started to run the tarball bundle task on this PR at dcff0c7. You can monitor the build here. |
Heya @jakebailey, I've started to run the diff-based user code test suite on this PR at dcff0c7. You can monitor the build here. Update: The results are in! |
Heya @jakebailey, I've started to run the diff-based user code test suite (tsserver) on this PR at dcff0c7. You can monitor the build here. Update: The results are in! |
Heya @jakebailey, I've started to run the diff-based top-repos suite on this PR at dcff0c7. You can monitor the build here. Update: The results are in! |
Heya @jakebailey, I've started to run the diff-based top-repos suite (tsserver) on this PR at dcff0c7. You can monitor the build here. Update: The results are in! |
Heya @jakebailey, I've started to run the regular perf test suite on this PR at dcff0c7. You can monitor the build here. Update: The results are in! |
Heya @jakebailey, I've started to run the parallelized Definitely Typed test suite on this PR at dcff0c7. You can monitor the build here. Update: The results are in! |
Hey @jakebailey, I've packed this into an installable tgz. You can install it for testing by referencing it in your
and then running There is also a playground for this build and an npm module you can use via |
@jakebailey Here they are:
CompilerComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
tsserverComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
StartupComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
Developer Information: |
@jakebailey Here are the results of running the user test suite comparing There were infrastructure failures potentially unrelated to your change:
Otherwise... Everything looks good! |
@jakebailey Here are the results of running the user test suite comparing Everything looks good! |
Hey @jakebailey, the results of running the DT tests are ready. |
@jakebailey Here are the results of running the top-repos suite comparing Something interesting changed - please have a look. DetailsServer exited prematurely with code unknown and signal SIGABRT
Affected reposcalcom/cal.comRaw error text:RepoResults7/calcom.cal.com.rawError.txt in the artifact folder
Last few requests{"seq":808,"type":"request","command":"getOutliningSpans","arguments":{"file":"@PROJECT_ROOT@/apps/swagger/pages/_app.tsx"}}
{"seq":809,"type":"request","command":"updateOpen","arguments":{"changedFiles":[{"fileName":"@PROJECT_ROOT@/apps/swagger/pages/_app.tsx","textChanges":[{"newText":" //comment","start":{"line":1,"offset":42},"end":{"line":1,"offset":42}}]}],"closedFiles":[],"openFiles":[]}}
{"seq":810,"type":"request","command":"updateOpen","arguments":{"changedFiles":[],"closedFiles":["@PROJECT_ROOT@/apps/api/test/lib/middleware/withMiddleware.test.ts"],"openFiles":[]}}
{"seq":811,"type":"request","command":"updateOpen","arguments":{"changedFiles":[],"closedFiles":[],"openFiles":[{"file":"@PROJECT_ROOT@/apps/web/app/layout.tsx","projectRootPath":"@PROJECT_ROOT@"}]}}
Repro steps
|
@jakebailey Here are the results of running the top-repos suite comparing Everything looks good! |
There's a crash above, but not sure if it's due to this PR or not. |
…th-private-members-for-contextual-type
I really doubt that this crash is related to this PR - but who knows? Could you rerun the extended test suite here before I start investigating this? |
@typescript-bot test top200 |
Heya @jakebailey, I've started to run the diff-based top-repos suite on this PR at 34d43f0. You can monitor the build here. Update: The results are in! |
@jakebailey Here are the results of running the top-repos suite comparing Everything looks good! |
tests/cases/compiler/contextuallyTypedParametersPositionIncludesClassWithPrivateMember2.ts
Show resolved
Hide resolved
…th-private-members-for-contextual-type
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'm a little bit suspicious of the fix itself from the PoV of just adding another layer of workers and then filtering, as compared to doing this more deeply in getContextualType
, but I can't quite put my finger on what is better.
it has been a while since I was working on this. I vaguely remember similar concerns that I had. IIRC, I do this filtering here because I can't access the information about being within "literal expression object" context at a deeper level. At the end of the day, the same operation would have to be done deeper - we get a set of values and we need to reject some. So this level works as OK as any other (as long as it doesn't introduce problems, ofc). |
fixes #56177