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.
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
Allow
--noCheck
to be commandLine option #58839Allow
--noCheck
to be commandLine option #58839Changes from 2 commits
5360b7b
5a84e20
c99bbb7
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Isn't it funky that a
noCheck
with-b
fetches different diagnostics than anoCheck
normally does? This is going to skip all the program construction errors thatnoCheck
would normally still report, no?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.
No. If typechecking is skipped the semantic and program diagnostics are skipped for that file too.. (Look at getBindAndCheckDiagnostics as well as getProgramDiagnostics in program)
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.
Oh, so this early bail here just skips the per-file iteration that'll internally bail on every individual file anyway; got it. It's not really clear that that's guaranteed to be the case.
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.
Isn't this exactly derived from the options? Like, isn't this just
options.noCheck
? Eveywhere I'm looking in this PR, this is either set ifoptions.noCheck
in the buildinfo is present, or unset if it isn't. I guessNonIncrementalBuildInfo
doesn't haveoptions
stored, but honestly, we should probably just always store them all.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.
No its not same as options.noCheck since it takes into account run with
--noCheck
,one without noCheck
and then--noCheck
without any updates in between does not update tsbuildInfo to mark it as pending. So its really if we havent done semanticdiagnostics calculationThere 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.
Right, it just seems like that's the same check we do for differing diagnostics-affecting options anyway? Like this is kinda redundant? (Though technically isn't since it's not using that mechanism with this PR.)
You run once without
<flag>
set, those options get cached into the.buildinfo
, then you do a run with<flag>
set - we compare the old<flag>
value (nonextant) with the new<flag>
value (present), and if<flag>
affects diagnostics, mark the build as needing a.buildinfo
update, minimally, and some subset of diagnostics and emit updated (as appropriate for the flag). At least for--incremental
. AddingnoCheck
would, then, trigger a typecheck, yes, but it'd be a basically free no-op typecheck (since the flag's function is to skip it). Removing the flag then, would, naturally, also trigger a new typecheck (and you'd get the errors back). Just seems weird we wouldn't reuse that logic for non-incremental, and instead special-case the option like this. Doesn't seem like it's actually skipping anything beyond a few function calls that'd skip their work internally with the flag set anyway, and is duplicating what already happens insidecreateBuilderProgramState
so long as the options from the old non-incremental build are actually serialized - which is why it seems so much like we're just hoisting the option out of the options list and into the root buildinfo.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’s because we don’t want to cached diagnostics that happened as part of checking when running with no check..
This helps with keeping the cache .. if you see the diff of second commit you should see that we are now able to retain diagnostics of unchanged files
we do exactly same thing as part of pending emit so we don’t have to emit already emitted files
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 think I get what we're doing here that's special - we're trying to reuse the
.buildinfo
from an old non-noCheck
build for another non-noCheck
without anoCheck
build in the middle clobbering it.That feels kinda weird, since it's basically like we're ignoring the
noCheck
build even happened and not updating the state, but I kinda get why you'd want that - so long as the state on disk is from the non-noCheck
build, you can start anoCheck
(for emit) and non-noCheck
(for checking) build in parallel off it.Personally, I assumed you'd want separate
.buildinfo
s for you non-noCheck
andnoCheck
build parts if you were trying to ensure they didn't clobber one another as you parallelized things. This kinda feels like it's trying to enable running the two builds with different options collaboratively off of a single.buildinfo
(since if thenoCheck
runs first, it'll leave the diagnostics part to the next build, while if thenoEmit
part runs first, it'll leave the emit part for the next build to fill in), which feels kinda odd. Both orders work in serial under this scheme, but if you actually parallelize it, one very likely could clobber the other's.buildinfo
output regardless. So I guess it's kinda neat that we can do this, but I'm not sure why we'd need to. If you are running them in serial, the options themselves are going to skip the relevant work, so skipping them at the orchestrator level is a bit redundant and just lets you run them in arbitrary order repeatedly without being penalized with a rebuild when you toggle emit/check on and then off again, but in parallel, you need separate buildinfos to prevent race conditions between the processes anyway, which were never going to trigger a rebuild unless there was an actual substantive change in the first place.I guess the TL;DR is:
Do we actually care if
reuses diagnostics from the first
--noEmit
run on the second--noEmit
line? These kind of partial output builds are only useful in parallel, and in parallel, you need separate.buildinfo
s for safety anyway. I'd expect we'd wanna enable and recommend something likeinstead, since that'll work even if you spawn the differently-option'd
tsc -b
s in parallel.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.
We do care about that and there is buildInfo fidelity built into it. Eg currenly we do support
tsc -b --noEmit
followed bytsc -b
so it doesnt typecheck again.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.
We are not doing this for parallel builds but subsequent builds. Eg imagine running tsc -b --noCheck -w while debugging and once done last running
tsc -b
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 guess it's fine to have this support, I'm just not sure it's gonna help many people in ways that aren't gonna lead them to a pit of failure. Like you see the sequential builds with different options smartly don't trigger rebuilds, so then naturally if you're a
watch
user you spawn one window withtsc -b --noCheck -w
and one withtsc -b --noEmit -w
as your super simple easy top-level parallelization, and that bricks the state, since the two builds will repeatedly clobber one another, rather than cooperate to build a single more complete state like the sequential builds do.