Skip to content
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

Fixes the issue with emit where in same file is emitted multiple times #19306

Merged
merged 6 commits into from
Oct 18, 2017

Conversation

sheetalkamat
Copy link
Member

Before this change, all the affected files list was emitted and the file write callback was used to ensure we mark duplicate source files that would result in computing same output file (eg with --out) The issue with this was that writeFileCallback doesn't list .d.ts files as computing to same output files, yet emit with that file as sourceFile emits the same --out file. This means whenever there are multiple d.ts files are present in affected file list, it would result in same file being emitted multiple times.
The problem got worse since builder always created emit output in memory, which means till all the changed files are written to disk those huge strings and other data exists in memory. That means you can run out of memory pretty soon. (Resulting in #19253)

This fix deals with this by:

  • emitChangedFiles in the builder doesn't generate output in memory, instead it takes the writeFileCallback (just like program::emit method)
  • Do not record deleted files in changedFileSet since they are anyways not going to result in any kind of emit
  • With this, now if there there is even a single file in changedFilesSet, and emit is going to use single file to output, just emit it. since with any change in program file (whether it changes shape or not) same file is going to be emitted
  • Do not cache semantic diagnostics when --out or --outFile is specified since we would anyways need to remove the diagnostics for the files that result in this emit
  • Also now store the files that have already computed if the shape was changed. This helps in not returning the file as updated shape multiple times. This is needed to ensure we don't compute same d.ts files again and again to see if signature is updated.
  • For declaration file, use its version as the signature instead of text so that we don't need to compute hash for them.

Apart from this another TODO and to think in future to see if we can ensure that emitter always emits just declaration file without doing any additional diagnostics/no emit checks. This would help in figuring out dependencies correctly. Right now in all these cases (for some reason emit is skipped) shape is assumed to be Skipped.

Fixes #19253

…g in memory output

Also marking few apis introduced during watch improvements changes that are suppose to be internal for now
Also use source file version as the signature of declaration file instead of computing it from text
… since we would anyways get all fresh diagnostics
const cachedDiagnostics = semanticDiagnosticsPerFile.get(path);
// Report the semantic diagnostics from the cache if we already have those diagnostics present
if (cachedDiagnostics) {
cachedDiagnostics;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

did you mean return cachedDiagnostics ?

Copy link
Contributor

@mhegazy mhegazy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One comment about the missing return for diagnostics

@sheetalkamat sheetalkamat merged commit 8fc6518 into master Oct 18, 2017
@sheetalkamat sheetalkamat deleted the doNoWriteFilesMultipleTimes branch October 18, 2017 23:12
@microsoft microsoft locked and limited conversation to collaborators Jun 14, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2.6 takes a very long time to --watch on large projects
2 participants