feat(language-service): [Ivy] getSemanticDiagnostics for external templates - #39065

For example, could we clear the modifiedTemplates here and return the previous contents? (If the compiler only needs the same changes once)

I think it's not a good idea to clear the modified templates here, because

1. we are relying on the compiler to only call this method once
   This assumption is fragile. Within the compiler it's perfectly fine for it to call this method multiple times, and it'd be surprising to them if the results of the first call is different from the second call
2. the behavior would not be consistent within the same compiler run
   This is a method defined by the compiler, and we need to adhere to the behavior they expect, not the behavior we provide.
   

   angular/packages/compiler-cli/src/ngtsc/core/api/src/interfaces.ts

   Lines 47 to 51 in bc69182

   	/**
   	* Get the absolute paths to the changed files that triggered the current compilation
   	* or `undefined` if this is not an incremental build.
   	*/
   	getModifiedResourceFiles?(): Set<string>|undefined;

   
   I gave this some more thought, and realize that we could clear the modified template after the compiler has read the updated version. The pro is that it'll always be consistent, i.e. once the compiler reads the template, it's no longer marked as modified. The con is that there's no explicit way for language service to make sure the template update is cleared after every request. I think pro > con in this case, because it's very unlikely that the compiler would not read a template that's been marked as modified.
   With this, I deleted the clearTemplateUpdates() method.

One more note: let's say the compiler asks for all the modified resources (getModifiedResourceFiles), then reads one modified resource, then asks for the modified resources again. In this case, with what you have described, the second set of modified resources would be one less than the first, so the expectation that first call = second call in the same run is lost. Is this something we need to be concerned about?

I think the behavior is still consistent in this case, because once the compiler reads a template, it already has the latest state of the file, so the file is no longer considered "modified".
That said, I agree this is not the best design. I think the initial design with clearTemplateUpdates() is the most straightforward solution with no surprise. Would you prefer that over the current solution?

Why don't we just recreate the program adapter each time we create a compiler?

The adapter is stateful because it needs to keep track of the template versions.
We could make it stateless, but in that case, the language service class itself will have to keep track of the template versions. I think the responsibility of tracking versions should fall under the adapter, not the language service.

Oh youre right I forgot about the versioning. Okay I am fine either way, sorry this was such a long discussion. Maybe later on we can figure out some nicer abstractions, even on the compiler side.

It's good, your comments make me think more about the architecture, and I agree there's an opportunity here to reuse some of TS logic to keep track of changed files, instead of us doing our custom checking.
Could you please approve this PR?

Of course :)

Of course :)