-
Notifications
You must be signed in to change notification settings - Fork 12.8k
Fix incorrect flags in modifierFlagsCache #56198
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
Conversation
Looks like you're introducing a change to the public API surface area. If this includes breaking changes, please document them on our wiki's API Breaking Changes page. Also, please make sure @DanielRosenwasser and @RyanCavanaugh are aware of the changes, just as a heads up. |
@typescript-bot perf test |
Heya @rbuckton, I've started to run the regular perf test suite on this PR at 428d327. You can monitor the build here. Update: The results are in! |
@typescript-bot run dt |
Heya @rbuckton, I've started to run the parallelized Definitely Typed test suite on this PR at 428d327. You can monitor the build here. Update: The results are in! |
Heya @rbuckton, I've started to run the diff-based user code test suite on this PR at 428d327. You can monitor the build here. Update: The results are in! |
@rbuckton Here are the results of running the user test suite comparing There were infrastructure failures potentially unrelated to your change:
Otherwise... Everything looks good! |
@rbuckton 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: |
Hey @rbuckton, the results of running the DT tests are ready. Branch only errors:Package: es-abstract
Package: es-to-primitive
|
(from the original issue)
Turns out there was a bug in |
:( I was hoping the perf cost would be negligible, but that doesn't seem to be the case. |
Where does the slowdown come from? A bit hard to tell at a glance. Are we calling One interesting bit is that the |
I'm guessing the issue may be all of the additional conditional branches that have to be hit in a hot code path. I'm reworking it to avoid the branches. |
It's also being too aggressive in collecting JSDoc modifiers in a TS file. |
@typescript-bot perf test |
Heya @rbuckton, I've started to run the regular perf test suite on this PR at f4253de. You can monitor the build here. Update: The results are in! |
@rbuckton 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: |
much better |
This seems good to me, though is it intended that DT still fail? It seems odd that we'd hard error on a JSDoc comment in TS code like this. |
@typescript-bot run dt |
Heya @rbuckton, I've started to run the parallelized Definitely Typed test suite on this PR at 4774cec. You can monitor the build here. Update: The results are in! |
That failure may be related to the change in the first approach, I need to retest to see if it still occurs in the new approach. |
Hey @rbuckton, the results of running the DT tests are ready. |
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.
LGTM, I don't think this is breaking given nobody should be depending on the exact values anyway.
I'm half worried that this PR appears to entirely fill up the entirety ModifierFlags
's bitwise space, but I'm not sure how we could do this different other than to have another flag prop or something.
There are still quite a few bits remaining, and we don't add new modifiers all that often. I'm trying to conserve memory as much as possible here, so I'd rather wait to expand into a second property when it becomes absolutely necessary. |
Due to the overlap between syntactic and JSDoc modifiers, there exists a case where what we report as cached syntactic modifiers can change in a JS file. To avoid this conflict, this PR modifies the caching behavior for modifier flags to give JSDoc modifiers their own cache value when they overlap with a syntactic modifier. The cache-only modifiers are then converted back to what we normally produce for those modifiers so as not to break existing callers.
Fixes #42189