-
Notifications
You must be signed in to change notification settings - Fork 12.8k
Refresh semantic diagnostics when compiler options affecting semantic diagnostics generation changes #26200
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
… diagnostics generation changes Fixes #26195
src/compiler/utilities.ts
Outdated
} | ||
|
||
return changedCompileOptionValueOf(newOptions, oldOptions, [ | ||
"noImplicitReturns", |
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 wonder if, instead of placing the list here, we use our central list of compiler options and mark them all with an internal field called "semantic" or something. I feel like otherwise, we will forget to update this list.
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.
That sounds good, but we still have these strict flags which should check their total value (from individual flag and strict flag) to see if it has really changed so we would need that part either ways.
…ting semanticDiagnostics
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.
Looks ok. esModuleInterop
and allowSyntheticDefaultImports
also need to be flagged, though, since the error they can report is also a semantic one.
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.
One question and one suggestion.
src/compiler/utilities.ts
Outdated
return false; | ||
} | ||
|
||
for (const option of optionDeclarations) { |
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.
return forEach(optionDeclarations, option => return (option.stringFlag && ...
reads a little better to me.
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.
some
over forEach
, probably.
showInSimplifiedHelpView: true, | ||
category: Diagnostics.Additional_Checks, | ||
description: Diagnostics.Report_errors_on_unused_locals, | ||
}, | ||
{ | ||
name: "noUnusedParameters", | ||
type: "boolean", | ||
affectsSemanticDiagnostics: true, |
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.
What determines whether affectsSemanticDiagnostics is true?
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.
The flags is true if changing value of the option, affects the semantic diagnostics reported(more/less) even if there is no change in file content. ( in turn whether to we need to throw away semantic diagnostics from cache(in --w mode) ) Eg. --noUnusedLocals can report more errors when turned on so it will have the flag true
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.
It seems easy to forget to set this when adding a new flag. Would making it required help? It would be annoying then, though.
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.
yeah I don't think we want this required.
Fixes #26195