- Notifications
You must be signed in to change notification settings - Fork1.7k
JS: Disable type extraction#19640
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Open
asgerf wants to merge28 commits intogithub:mainChoose a base branch
base:main
Could not load branches
Branch not found:{{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline, and old review comments may become outdated.
Open
Uh oh!
There was an error while loading.Please reload this page.
Conversation
This file contains hidden or 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
| name = spec.getExportedName() and | ||
| result = spec.getLocal() | ||
| ) | ||
| or |
Check warning
Code scanning / CodeQL
Dead code Warning
This code is never used, and it's not publicly exported.
| name = sig.getName() | ||
| ) | ||
| private class MethodCallSig extends Function { | ||
| private MethodSignature signature; |
Check notice
Code scanning / CodeQL
Field only used in CharPred Note
Field is only used in CharPred.
Comment on lines +10 to +12
| /** | ||
| * Interface for accessing name-resolution info about type names. | ||
| */ |
Check warning
Code scanning / CodeQL
Class QLDoc style. Warning
The QLDoc for a class should start with 'A', 'An', or 'The'.
Comment on lines +142 to +144
| /** | ||
| * Interface for accessing name-resolution info about expressions. | ||
| */ |
Check warning
Code scanning / CodeQL
Class QLDoc style. Warning
The QLDoc for a class should start with 'A', 'An', or 'The'.
9521fbb to2035925CompareThis query depended on the cons-hashing performed by type extraction to determine if two types are the same.This is not trivial to restore, but not important enough to reimplement right now, so for now just simplifying the query's ability to recognise that two types are the same.
This was used in the very old dist-compare tool, but has no use anymore
3a1fae6 to1729f7aCompareThis check existed on the code path for full type extraction, but not for plain single-file extraction.
The 'extractTypeScriptFiles' override did not incorporate the file type and one of our unit tests was expecting this. The test was previously passing for the wrong reasons.
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
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.
Uh oh!
There was an error while loading.Please reload this page.
Disabling type extraction
We used to rely on the TypeScript compiler's type checker for getting type information during extraction. As of this PR, we only use the TypeScript compiler for parsing, and instead use CodeQL logic to obtain the needed type information ourselves.
Why?
Faster extraction: We're seeing 20-80% faster extraction times for TypeScript code bases. The wins here tend to outweigh the added cost on the QL side.
Incremental extraction: Type extraction was incompatible with "overlay mode". With this change, TypeScript files can be extracted in isolation from each other, meaning we only have to parse the files that have changed when building an overlay database.
Robustness: TypeScript extraction rarely fails, but when it does, it is usually because of type extraction. At least three public issues (1,2,3) and several internal ones are ultimately about type extraction problems. Several issues with type extraction have surfaced and been fixed over the years, but there's been a tendency for the "fixes" to be workarounds for problems that we don't have enough control over from the extractor.
Deprecations and breaking changes
This PR deprecates
Typeand other APIs relating to extracted types, and introduces a simple interface for interacting with the new QL-based name/type resolution.Queries relying on
Typeand friends should still compile (with deprecation warnings) but won't have the same results sinceTypeis now empty. The change notes therefore lists this as a breaking change. We try to avoid breaking changes when at all possible, but there is no viable mechanism for avoiding it in this case.Call graph changes
When I made the original call graph estimates in the previous PR, I had unfortunately not disabled the influence of type extraction completely, meaning we lose more call edges than originally estimated.
This PR adds a few more fixes to recover some of them, but as seen in theevaluation we still lose 25k call edges. However, this only results in 1 lost alert, which was a FP. I have some follow-up work with generics that recovers about a third of the call edges. Despite the lost call edges, I'd like to move ahead with this PR as the pros clearly outweigh the cons at this point, and it means we can unblock other works that depend on it.