-
Notifications
You must be signed in to change notification settings - Fork 25.9k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Introduce the TemplateTypeChecker
abstraction in prep for the Ivy Language Service
#38105
Conversation
feea1b2
to
7057f57
Compare
Previously in the template type-checking engine, it was assumed that every input file would have an associated type-checking shim. The type check block code for all components in the input file would be generated into this shim. This is fine for whole-program type checking operations, but to support the language service's requirements for low latency, it would be ideal to be able to check a single component in isolation, especially if the component is declared along with many others in a single file. This commit removes the assumption that the file/shim mapping is 1:1, and introduces the concept of component-to-shim mapping. Any `TypeCheckingProgramStrategy` must provide such a mapping. To achieve this: * type checking record information is now split into file-level data as well as per-shim data. * components are now assigned a stable `TemplateId` which is unique to the file in which they're declared.
f7419e3
to
91fcf67
Compare
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.
LGTM Reviewed-For:dev-infra
Looks good overall for dev-infra, just one comment/request, which isn't really blocking just might be easier long term
91fcf67
to
bd98066
Compare
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.
There are a bunch of valid CI failures. We should probably hold off on public-api reviews until this is stable.
This commit significantly refactors the 'typecheck' package to introduce a new abstraction, the `TemplateTypeChecker`. To achieve this: * a 'typecheck:api' package is introduced, containing common interfaces that consumers of the template type-checking infrastructure can depend on without incurring a dependency on the template type-checking machinery as a whole. * interfaces for `TemplateTypeChecker` and `TypeCheckContext` are introduced which contain the abstract operations supported by the implementation classes `TemplateTypeCheckerImpl` and `TypeCheckContextImpl` respectively. * the `TemplateTypeChecker` interface supports diagnostics on a whole program basis to start with, but the implementation is purposefully designed to support incremental diagnostics at a per-file or per-component level. * `TemplateTypeChecker` supports direct access to the type check block of a component. * the testing utility is refactored to be a lot more useful, and new tests are added for the new abstraction.
The template type-checking engine relies on the abstraction interface `TypeCheckingProgramStrategy` to create updated `ts.Program`s for template type-checking. The basic API is that the type-checking engine requests changes to certain files in the program, and the strategy provides an updated `ts.Program`. Typically, such changes are made to 'ngtypecheck' shim files, but certain conditions can cause template type-checking to require "inline" operations, which change user .ts files instead. The strategy used by 'ngc' (the `ReusedProgramStrategy`) supports these kinds of updates, but other clients such as the language service might not always support modifying user files. To accommodate this, the `TypeCheckingProgramStrategy` interface was modified to include a `supportsInlineOperations` flag. If an implementation specifies `false` for inline support, the template type-checking system will return diagnostics on components which would otherwise require inline operations. Closes angular#38059
…th sensitivity issue This commit disables one TypeChecker test (added as a part of angular#38105) which make assertions about the filename while running on Windows. Such assertions are currently suffering from a case sensitivity issue.
Now that Ivy compiler has a proper `TemplateTypeChecker` interface (see angular#38105) we no longer need to keep the temporary compiler implementation. This commit removes the whole `ivy/compiler` directory and moves two functions `createTypeCheckingProgramStrategy` and `getOrCreateTypeCheckScriptInfo` to the `LanguageService` class. Also re-enable the Ivy LS test since it's no longer blocking development.
Now that Ivy compiler has a proper `TemplateTypeChecker` interface (see angular#38105) we no longer need to keep the temporary compiler implementation. This commit removes the whole `ivy/compiler` directory and moves two functions `createTypeCheckingProgramStrategy` and `getOrCreateTypeCheckScriptInfo` to the `LanguageService` class. Also re-enable the Ivy LS test since it's no longer blocking development.
Now that Ivy compiler has a proper `TemplateTypeChecker` interface (see angular#38105) we no longer need to keep the temporary compiler implementation. This commit removes the whole `ivy/compiler` directory and moves two functions `createTypeCheckingProgramStrategy` and `getOrCreateTypeCheckScriptInfo` to the `LanguageService` class. Also re-enable the Ivy LS test since it's no longer blocking development.
…lar#38105) Previously in the template type-checking engine, it was assumed that every input file would have an associated type-checking shim. The type check block code for all components in the input file would be generated into this shim. This is fine for whole-program type checking operations, but to support the language service's requirements for low latency, it would be ideal to be able to check a single component in isolation, especially if the component is declared along with many others in a single file. This commit removes the assumption that the file/shim mapping is 1:1, and introduces the concept of component-to-shim mapping. Any `TypeCheckingProgramStrategy` must provide such a mapping. To achieve this: * type checking record information is now split into file-level data as well as per-shim data. * components are now assigned a stable `TemplateId` which is unique to the file in which they're declared. PR Close angular#38105
…angular#38105) This commit significantly refactors the 'typecheck' package to introduce a new abstraction, the `TemplateTypeChecker`. To achieve this: * a 'typecheck:api' package is introduced, containing common interfaces that consumers of the template type-checking infrastructure can depend on without incurring a dependency on the template type-checking machinery as a whole. * interfaces for `TemplateTypeChecker` and `TypeCheckContext` are introduced which contain the abstract operations supported by the implementation classes `TemplateTypeCheckerImpl` and `TypeCheckContextImpl` respectively. * the `TemplateTypeChecker` interface supports diagnostics on a whole program basis to start with, but the implementation is purposefully designed to support incremental diagnostics at a per-file or per-component level. * `TemplateTypeChecker` supports direct access to the type check block of a component. * the testing utility is refactored to be a lot more useful, and new tests are added for the new abstraction. PR Close angular#38105
…ng (angular#38105) The template type-checking engine relies on the abstraction interface `TypeCheckingProgramStrategy` to create updated `ts.Program`s for template type-checking. The basic API is that the type-checking engine requests changes to certain files in the program, and the strategy provides an updated `ts.Program`. Typically, such changes are made to 'ngtypecheck' shim files, but certain conditions can cause template type-checking to require "inline" operations, which change user .ts files instead. The strategy used by 'ngc' (the `ReusedProgramStrategy`) supports these kinds of updates, but other clients such as the language service might not always support modifying user files. To accommodate this, the `TypeCheckingProgramStrategy` interface was modified to include a `supportsInlineOperations` flag. If an implementation specifies `false` for inline support, the template type-checking system will return diagnostics on components which would otherwise require inline operations. Closes angular#38059 PR Close angular#38105
…cs (angular#38105) Previously, the `TemplateTypeChecker` abstraction allowed fetching diagnostics for a single file, but under the hood would generate type checking code for the entire program to satisfy the request. With this commit, an `OptimizeFor` hint is passed to `getDiagnosticsForFile` which indicates whether the user intends to request diagnostics for the whole program or is truly interested in just the single file. If the latter, the `TemplateTypeChecker` can perform only the work needed to produce diagnostics for just that file, thus returning answers more efficiently. PR Close angular#38105
angular#38105) This commit adds an `overrideComponentTemplate` operation to the template type-checker. This operation changes the template used during template type-checking operations. Overriding a template causes any previous work for it to be discarded, and the template type-checking engine will regenerate the TCB for that template on the next request. This operation can be used by a consumer such as the language service to get rapid feedback or diagnostics as the user is editing a template file, without the need for a full incremental build iteration. Closes angular#38058 PR Close angular#38105
…ular#38105) Previously, a stable template id was implemented for each component in a file. This commit adds this id to each `TemplateDiagnostic` generated from the template type-checker, so it can potentially be used for filtration. PR Close angular#38105
…ular#38105) This commit adds a method `getDiagnosticsForComponent` to the `TemplateTypeChecker`, which does the minimum amount of work to retrieve diagnostics for a single component. With the normal `ReusedProgramStrategy` this offers virtually no improvement over the standard `getDiagnosticsForFile` operation, but if the `TypeCheckingProgramStrategy` supports separate shims for each component, this operation can yield a faster turnaround for components that are declared in files with many other components. PR Close angular#38105
…th sensitivity issue (angular#38294) This commit disables one TypeChecker test (added as a part of angular#38105) which make assertions about the filename while running on Windows. Such assertions are currently suffering from a case sensitivity issue. PR Close angular#38294
Now that Ivy compiler has a proper `TemplateTypeChecker` interface (see angular#38105) we no longer need to keep the temporary compiler implementation. This commit removes the whole `ivy/compiler` directory and moves two functions `createTypeCheckingProgramStrategy` and `getOrCreateTypeCheckScriptInfo` to the `LanguageService` class. Also re-enable the Ivy LS test since it's no longer blocking development.
Now that Ivy compiler has a proper `TemplateTypeChecker` interface (see angular#38105) we no longer need to keep the temporary compiler implementation. The temporary compiler was created to enable testing infrastructure to be developed for the Ivy language service. This commit removes the whole `ivy/compiler` directory and moves two functions `createTypeCheckingProgramStrategy` and `getOrCreateTypeCheckScriptInfo` to the `LanguageService` class. Also re-enable the Ivy LS test since it's no longer blocking development.
Now that Ivy compiler has a proper `TemplateTypeChecker` interface (see #38105) we no longer need to keep the temporary compiler implementation. The temporary compiler was created to enable testing infrastructure to be developed for the Ivy language service. This commit removes the whole `ivy/compiler` directory and moves two functions `createTypeCheckingProgramStrategy` and `getOrCreateTypeCheckScriptInfo` to the `LanguageService` class. Also re-enable the Ivy LS test since it's no longer blocking development. PR Close #38310
Now that Ivy compiler has a proper `TemplateTypeChecker` interface (see #38105) we no longer need to keep the temporary compiler implementation. The temporary compiler was created to enable testing infrastructure to be developed for the Ivy language service. This commit removes the whole `ivy/compiler` directory and moves two functions `createTypeCheckingProgramStrategy` and `getOrCreateTypeCheckScriptInfo` to the `LanguageService` class. Also re-enable the Ivy LS test since it's no longer blocking development. PR Close #38310
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
…lar#38105) Previously in the template type-checking engine, it was assumed that every input file would have an associated type-checking shim. The type check block code for all components in the input file would be generated into this shim. This is fine for whole-program type checking operations, but to support the language service's requirements for low latency, it would be ideal to be able to check a single component in isolation, especially if the component is declared along with many others in a single file. This commit removes the assumption that the file/shim mapping is 1:1, and introduces the concept of component-to-shim mapping. Any `TypeCheckingProgramStrategy` must provide such a mapping. To achieve this: * type checking record information is now split into file-level data as well as per-shim data. * components are now assigned a stable `TemplateId` which is unique to the file in which they're declared. PR Close angular#38105
…angular#38105) This commit significantly refactors the 'typecheck' package to introduce a new abstraction, the `TemplateTypeChecker`. To achieve this: * a 'typecheck:api' package is introduced, containing common interfaces that consumers of the template type-checking infrastructure can depend on without incurring a dependency on the template type-checking machinery as a whole. * interfaces for `TemplateTypeChecker` and `TypeCheckContext` are introduced which contain the abstract operations supported by the implementation classes `TemplateTypeCheckerImpl` and `TypeCheckContextImpl` respectively. * the `TemplateTypeChecker` interface supports diagnostics on a whole program basis to start with, but the implementation is purposefully designed to support incremental diagnostics at a per-file or per-component level. * `TemplateTypeChecker` supports direct access to the type check block of a component. * the testing utility is refactored to be a lot more useful, and new tests are added for the new abstraction. PR Close angular#38105
…ng (angular#38105) The template type-checking engine relies on the abstraction interface `TypeCheckingProgramStrategy` to create updated `ts.Program`s for template type-checking. The basic API is that the type-checking engine requests changes to certain files in the program, and the strategy provides an updated `ts.Program`. Typically, such changes are made to 'ngtypecheck' shim files, but certain conditions can cause template type-checking to require "inline" operations, which change user .ts files instead. The strategy used by 'ngc' (the `ReusedProgramStrategy`) supports these kinds of updates, but other clients such as the language service might not always support modifying user files. To accommodate this, the `TypeCheckingProgramStrategy` interface was modified to include a `supportsInlineOperations` flag. If an implementation specifies `false` for inline support, the template type-checking system will return diagnostics on components which would otherwise require inline operations. Closes angular#38059 PR Close angular#38105
…cs (angular#38105) Previously, the `TemplateTypeChecker` abstraction allowed fetching diagnostics for a single file, but under the hood would generate type checking code for the entire program to satisfy the request. With this commit, an `OptimizeFor` hint is passed to `getDiagnosticsForFile` which indicates whether the user intends to request diagnostics for the whole program or is truly interested in just the single file. If the latter, the `TemplateTypeChecker` can perform only the work needed to produce diagnostics for just that file, thus returning answers more efficiently. PR Close angular#38105
angular#38105) This commit adds an `overrideComponentTemplate` operation to the template type-checker. This operation changes the template used during template type-checking operations. Overriding a template causes any previous work for it to be discarded, and the template type-checking engine will regenerate the TCB for that template on the next request. This operation can be used by a consumer such as the language service to get rapid feedback or diagnostics as the user is editing a template file, without the need for a full incremental build iteration. Closes angular#38058 PR Close angular#38105
…ular#38105) Previously, a stable template id was implemented for each component in a file. This commit adds this id to each `TemplateDiagnostic` generated from the template type-checker, so it can potentially be used for filtration. PR Close angular#38105
…ular#38105) This commit adds a method `getDiagnosticsForComponent` to the `TemplateTypeChecker`, which does the minimum amount of work to retrieve diagnostics for a single component. With the normal `ReusedProgramStrategy` this offers virtually no improvement over the standard `getDiagnosticsForFile` operation, but if the `TypeCheckingProgramStrategy` supports separate shims for each component, this operation can yield a faster turnaround for components that are declared in files with many other components. PR Close angular#38105
No description provided.