Skip to content

Fix #15200: Query for semantic errors on .js files with '@ts-check' with no config file#15260

Merged
mhegazy merged 5 commits into
masterfrom
Fix15200
Apr 20, 2017
Merged

Fix #15200: Query for semantic errors on .js files with '@ts-check' with no config file#15260
mhegazy merged 5 commits into
masterfrom
Fix15200

Conversation

@mhegazy
Copy link
Copy Markdown
Contributor

@mhegazy mhegazy commented Apr 18, 2017

tsserver checks before calling getSemanticDiagnostics if this is a JS-only project first to avoid paying the cost of a semantic check on .d.ts files and second to avoid reporting errors that users do not care about (e.f. in .d.ts files auto-injected by ATA).

The check does not make sense in the presence of // @ts-check since every .js file now is a fair target for calling getSemanitcDiagnostics.

This change has two parts:

  • Make the check on the tsserver work on the file-level instead of the project level, only skipping checking on .d.ts files but not .js files
  • For configured projects, defer to the program.getSemanticDiagnostics instead of cutting it too early in the server, and instead make sure the program does not return bind diagnostics for .d.ts files if check diagnostics are not reported (i.e. --skipLibCheck or --skipDefaultLibCheck are set).

Fixes #15200

@billti can you please review this change. this touches on a change you have added recently.

Comment thread src/compiler/program.ts
return runWithCancellationToken(() => {
// If skipLibCheck is enabled, skip reporting errors if file is a declaration file.
// If skipDefaultLibCheck is enabled, skip reporting errors if file contains a
// '/// <reference no-default-lib="true"/>' directive.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

This comment isn't making much sense to me as written. If you have no-default-lib set to true, then I assume there is no default lib to check - in which case, what difference does skipDefaultLibCheck make?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

no-default-lib is just a triple-slash directive. it can exist any where.
We have two flags, for historic reasons:

  1. skipDefaultLibCheck, only skips the checking of files that have /// <reference no-default-lib="true"/> in them. This flag is now deprecated, but we still honor it.
  2. skipLibCheck, skips checking of all .d.ts files

Comment thread src/server/session.ts
const scriptInfo = project.getScriptInfoForNormalizedPath(file);
return scriptInfo && !scriptInfo.isJavaScript();
}
return false;
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

So this always returns false for configured projects (as the above if is only entered for inferred/external projects)?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

yes. program.getSemanticDiagnostics should do the right thing for configured projects.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

OK. Again, maybe clarify in comments in the function then. It seems this only returns true for a narrow subset of files that may actually have semantic checking skipped eventually.

Comment thread src/server/session.ts Outdated
// For inferred (e.g. miscellaneous context in VS) and external projects (e.g. VS .csproj project) with only JS files
// semantic errors in .d.ts files (e.g. ones added by automatic type acquisition) are not interesting.
// We want to avoid the cost of querying for these errors all together, even if 'skipLibCheck' is not set.
// We still want to check .js files (e.g. '// @ts-check' or '--checkJs' is set).
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

This code always returns false for JavaScript files (due to && !scriptInfo.isJavaScript()), so the comment about @ts-check / --checkJs is confusing. Where do these come into play then, if not taked into account in this method?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

we do not know here (in the server) if the .js file should be checked or not. we know that later on by inspecting the SourceFile object in the program. so what we are doing here is we are deferring the check to program.getSemanticDiagnostics

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Maybe a comment to that effect in this function then? It's confusing to have a function called shouldSkipSemanticCheck that takes a file, that doesn't actually check if it should skip the semantic check for that file 😕

Comment thread src/compiler/program.ts
// If skipLibCheck is enabled, skip reporting errors if file is a declaration file.
// If skipDefaultLibCheck is enabled, skip reporting errors if file contains a
// '/// <reference no-default-lib="true"/>' directive.
if (options.skipLibCheck && sourceFile.isDeclarationFile || options.skipDefaultLibCheck && sourceFile.hasNoDefaultLib) {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Why do we have this check in two places ? I see similar check in checkSourceFileWorker in checker.ts. Do we need to remove that check?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

yes, will get that fixed.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I remember now why i did not do that, we call TypeChecker.getDiagnostics from the tests directly.

@mhegazy mhegazy merged commit 24814ec into master Apr 20, 2017
@mhegazy mhegazy deleted the Fix15200 branch April 20, 2017 20:46
@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.

4 participants