Fix broken module resolution after large/rapid edits in nodenext

[andrewbranch]

Fixes #46396

When updating a SourceFile, the incremental parser copies the old SourceFile’s impliedNodeFormat to the new one. Reusing module resolution from the old Program later expects that field to already be set on the updated SourceFile. However, the incremental parser is skipped when the language service gets overwhelmed by changes—specifically, when there are 8 or more changes logged against the snapshot before the language service asks for an updated SourceFile, or when the length of a text change is greater than 256 characters. In these cases, the SourceFile is re-parsed from scratch, and so it lacks its impliedNodeFormat field.

[andrewbranch]

A question now is whether to remove the field copying from the incremental parser. These should be redundant for all our own uses, but it’s possible someone could use the incremental parser standalone. Doing it there is valid, but copying those kinds of fields is not generally the job of the incremental parser 🤷

[andrewbranch]

@weswigham thanks for the review—any opinion on whether the incremental parser should still copy that field? I’m fairly happy to err on the side of leaving it there, as I don’t think it’s hurting anything.

[weswigham]

The incremental parser copies/reparses things like the comment directive list onto the new source file - I think it's fine for it to also copy the impliedNodeFormat field. The parser can't add it on it's own because you need either a module resolution host or an old source file to get the information, so it's kinda the first place that information is available during an incremental reparse.

[DanielRosenwasser]

So is it wrong to do it in program.ts? Do we need both? I'm mostly asking for my own understanding.

[weswigham]

I don't think there's a right or wrong place - this field has some pretty unique requirements among SourceFile members because of everything that goes into calculating its initial value - we just set it whenever we can.