forked from angular/angular
-
Notifications
You must be signed in to change notification settings - Fork 0
Create a new pull request by comparing changes across two branches. #516
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
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…37795) In JIT compiled apps, component definitions are compiled upon first access. For a component class `A` that extends component class `B`, the `B` component is also compiled when the `InheritDefinitionFeature` runs during the compilation of `A` before it has finalized. A problem arises when the compilation of `B` would flush the NgModule scoping queue, where the NgModule declaring `A` is still pending. The scope information would be applied to the definition of `A`, but its compilation is still in progress so requesting the component definition would compile `A` again from scratch. This "inner compilation" is correctly assigned the NgModule scope, but once the "outer compilation" of `A` finishes it would overwrite the inner compilation's definition, losing the NgModule scope information. In summary, flushing the NgModule scope queue could trigger a reentrant compilation, where JIT compilation is non-reentrant. To avoid the reentrant compilation, a compilation depth counter is introduced to avoid flushing the NgModule scope during nested compilations. Fixes #37105 PR Close #37795
…g order (#37911) When using the safe navigation operator in a binding expression, a temporary variable may be used for storing the result of a side-effectful call. For example, the following template uses a pipe and a safe property access: ```html <app-person-view [enabled]="enabled" [firstName]="(person$ | async)?.name"></app-person-view> ``` The result of the pipe evaluation is stored in a temporary to be able to check whether it is present. The temporary variable needs to be declared in a separate statement and this would also cause the full expression itself to be pulled out into a separate statement. This would compile into the following pseudo-code instructions: ```js var temp = null; var firstName = (temp = pipe('async', ctx.person$)) == null ? null : temp.name; property('enabled', ctx.enabled)('firstName', firstName); ``` Notice that the pipe evaluation happens before evaluating the `enabled` binding, such that the runtime's internal binding index would correspond with `enabled`, not `firstName`. This introduces a problem when the pipe uses `WrappedValue` to force a change to be detected, as the runtime would then mark the binding slot corresponding with `enabled` as dirty, instead of `firstName`. This results in the `enabled` binding to be updated, triggering setters and affecting how `OnChanges` is called. In the pseudo-code above, the intermediate `firstName` variable is not strictly necessary---it only improved readability a bit---and emitting it inline with the binding itself avoids the out-of-order execution of the pipe: ```js var temp = null; property('enabled', ctx.enabled) ('firstName', (temp = pipe('async', ctx.person$)) == null ? null : temp.name); ``` This commit introduces a new `BindingForm` that results in the above code to be generated and adds compiler and acceptance tests to verify the proper behavior. Fixes #37194 PR Close #37911
…type-only imports (#37912) In TypeScript 3.8 support was added for type-only imports, which only brings in the symbol as a type, not their value. The Angular compiler did not yet take the type-only keyword into account when representing symbols in type positions as value expressions. The class metadata that the compiler emits would include the value expression for its parameter types, generating actual imports as necessary. For type-only imports this should not be done, as it introduces an actual import of the module that was originally just a type-only import. This commit lets the compiler deal with type-only imports specially, preventing a value expression from being created. Fixes #37900 PR Close #37912
#37917) "Quote expressions" are expressions that start with an identifier followed by a comma, allowing arbitrary syntax to follow. These kinds of expressions would throw a an error in the template type checker, which would make them hard to track down. As quote expressions are not generally used at all, the error would typically occur for URLs that would inadvertently occur in a binding: ```html <a [href]="https://example.com"></a> ``` This commit lets such bindings be inferred as the `any` type. Fixes #36568 Resolves FW-2051 PR Close #37917
…h generic types (#38249) Prior to this change, the template type checker would always use a type-constructor to instantiate a directive. This type-constructor call serves two purposes: 1. Infer any generic types for the directive instance from the inputs that are passed in. 2. Type check the inputs that are passed into the directive's inputs. The first purpose is only relevant when the directive actually has any generic types and using a type-constructor for these cases inhibits a type-check performance penalty, as a type-constructor's signature is quite complex and needs to be generated for each directive. This commit refactors the generated type-check blocks to only generate a type-constructor call for directives that have generic types. Type checking of inputs is achieved by generating individual statements for all inputs, using assignments into the directive's fields. Even if a type-constructor is used for type-inference of generic types will the input checking also be achieved using the individual assignment statements. This is done to support the rework of the language service, which will start to extract symbol information from the type-check blocks. As a future optimization, it may be possible to reduce the number of inputs passed into a type-constructor to only those inputs that contribute the the type-inference of the generics. As this is not a necessity at the moment this is left as follow-up work. Closes #38185 PR Close #38249
…ng to restricted input fields (#38249) The compiler does not currently report errors when there's an `@Input()` for a `private`, `protected`, or `readonly` directive/component class member. This change adds an option to enable reporting errors when a template attempts to bind to one of these restricted input fields. PR Close #38249
Currently the Closure-related tests are not tree-shaking the dev-mode-only content, thus payload size checks are failing even if dev-mode-only content is added. The 2e9fdbd commit added some logic to JIT compiler, which is likely triggered the payload size increase. This commit updates the payload size limits for Closure-related test to get master and patch branches back to the "green" state. PR Close #38411
Following the issues highlighted in https://docs.google.com/document/d/1eB6cGCG_2ircfS5GzpDC9dBgikeYYcMxghVH5sDESHw/edit?usp=sharing and discussions held with the TypeScript team. Together with the TypeScript team it was decided that the best course of action is to rollback this feature. In future, it is not excluded that solution style tsconfigs are re-introduced. See: angular/angular-cli#18478 PR Close #38394
Adds an ng-dev formatter option to format all of the staged files. This will can be used to format only the staged files during the pre-commit hook. PR Close #38402
Runs the `ng-dev format changed` command whenever the `git commit` command is run. As all changes which are checked by CI will require this check passing, this change can prevent needless roundtrips to correct lint/formatting errors. This automatic formatting can be bypassed with the `--no-verify` flag on the `git commit` command. PR Close #38402
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
Issue Number: N/A
What is the new behavior?
Does this PR introduce a breaking change?
Other information