In the `Element` node of a parsed `<svg>` element, the `name` is recorded
as `:svg:svg`. When the Angular Indexer ran over this element, it would
attempt to find this name in the template text and fail, as the namespace
portion of the name was added automatically at parse time and is of course
missing from the original template.
This commit changes the indexer to detect these namespaced elements and only
search for the tag name.
PR Close#44678
When parsing a binding with a comment at the end of the expression, the
parser previously had logic to offset the parsed spans by the length of the
comment. This logic seemed not to serve any useful purpose, and instead
resulted in the corruption of the spans. For example, in the expression
`{{foo // comment}}`, the parser would map the parsed `foo` `PropertyRead`
node at the location of the characters 'ent' from the comment suffix.
This commit removes that logic, correcting the parsed spans of such nodes in
the presence of comments. Removing this logic does not seem to have caused
any tests to fail.
PR Close#44678
Previously, the Angular Indexer made an assumption that in any binding to
a property of an `ImplicitReceiver`, the property name begins at the start
of the binding. This is true for normal reads from `ImplicitReceiver` as
the implicit receiver has no representation in the template.
However, `ThisReceiver` inherits from `ImplicitReceiver` and _does_ have a
template representation. Such a binding looks like `{{this.foo}}`. This
commit corrects the logic of the indexer to use the `nameSpan` of the
property binding instead of its `sourceSpan` to locate the identifier.
PR Close#44678
Refs #42966.
This validates the `tsconfig.json` options for extended template diagnostics. It verifies:
* `strictTemplates` must be enabled if `extendedDiagnostics` have any explicit configuration.
* `extendedDiagnostics.defaultCategory` must be a valid `DiagnosticCategoryLabel`.
* `extendedDiagnostics.checks` keys must all be real diagnostics.
* `extendedDiagnostics.checks` values must all be valid `DiagnosticCategoryLabel`s.
These include new error codes, each of which prints out the exact property that was the issue and what the available options are to fix them.
It does disallow the config:
```json
{
"angularCompilerOptions": {
"strictTemplates": false,
"extendedDiagnostics": {
"defaultCategory": "suppress"
}
}
}
```
Such a configuration is technically valid and could be executed, but will be rejected by this verification logic. There isn't much reason to ever do this, since users could just drop `extendedDiagnostics` altogether and get the intended effect. This is unlikely to be a significant issue for users, so it is considered invalid for now to keep the implementation simple.
PR Close#44391
Refs #42966.
The `defaultCategory` option is used for any extended template diagnostics which do not have any specific category specified for them. It defaults to `warning`, since that is the most common behavior expected for users. This provides an easy way for users to promote all diagnostics to errors or suppress all diagnostics.
PR Close#44391
Refs #42966.
This updates `TemplateContext` to include a new `makeTemplateDiagnostic()` function which automatically uses the correct diagnostic category for that check. This makes sure that each diagnostic is emitted with the correct category. It also implicitly passes some known values like `component` and `code` to make the extended template diagnostics a little simpler. Diagnostics which are suppressed are never instantiated at all, which acts as a slight performance optimization since any emitted diagnostics would be ignored anyways.
Unfortunately, diagnostics still have access to `ctx.templateTypeChecker.makeTemplateDiagnostic()` to manually create diagnostics with a different category. Both banana in box and nullish coalescing checks include tests to make sure they respect a manually configured category. This convention should hopefully give a reasonable certainty that new diagnostics will use the correct reporting function, even if that is not strictly enforced.
PR Close#44391
Refs #42966.
This includes a mapping of extended template diagnostics to their associated diagnostic category. It is generated from the list of diagnostic names, so the list should always be implicitly kept up to date. Usage looks like:
```json
{
"angularCompilerOptions": {
"extendedDiagnostics": {
"checks": {
"invalidBananaInBox": "error",
"nullishCoalescingNotNullable": "suppress"
}
}
}
}
```
PR Close#44391
Refs #42966.
This is a static array of all the 1P extended template diagnostic factories built into the Angular compiler directly. It provides an encapsulated list of all diagnostics rather than requiring users to manually list each one individually.
PR Close#44391
Refs #42966.
This moves extended template check factory invocations into the checker itself, where it can provide a more consistent API contract. Factories are called with compiler options and may return a `TemplateCheck` or `undefined` if the current options do not support that check. This allows `nullishCoalescingNotNullable` to disable itself when `strictNullChecks` is disabled without throwing errors. This gives extended template diagnostics a stronger abstraction model to define their behavior with.
PR Close#44391
Refs #42966.
The enum of extended template diagnostic names allows a global registry of first-party diagnostics with a developer-friendly string name which can be used for configuration. This name is used in the new `TemplateCheckFactory` to bind the name to a particular `ErrorCode` and make both available *before* constructing the actual template check, which is necessary to configure it appropriately.
PR Close#44391
In `language-service`, the `checker.getDirectiveMetadata` doesn't return the animations meta of the `Component`.
but it's useful for animation completion.
PR Close#44630
The changes in 2028c3933f caused method
calls to be emitted using additional parenthesis into the TCB, which in
turn prevented proper type narrowing when the method acts as a type
guard. This commit special-cases method calls from property reads to
avoid the additional parenthesis.
Fixes#44353
PR Close#44447
when reordering a list with animations the list items lose their current
triggers values, that is because the reordering of an item is implemented
as follows (_note:_ the following implementation has been added in PR #23534)
- the item is removed and marked _setForRemoval_
- the item is re-inserted, and the _setForRemoval_ is changed to _setForMove_
- the player set for animating the removal is destroyed when _setForMove_ is detected
the above steps allow the element not to be animated and to keep its styling but the
triggers values get lost since the removal transition/player has already been initialized,
so this change adds a _previousTriggersValues_ map in the _REMOVAL_FLAG_ field in order to
restore the triggers values if/when the removal turns out to be a move, changing the above steps to:
- the item is removed and marked setForRemoval __and its current triggers values are saved as well__
- the item is re-inserted, and the setForRemoval is changed to setForMove
- the player set for animating the removal is destroyed when setForMove is detected __and the
trigger values are re-applied in the engine's statesByElement map__
resolves#29526
PR Close#44578
This was flagged during the code review of #44580. When generating a type check block, we were interpreting any call to `$any` as an `as any` cast, even if it's part of a `PropertyRead` (e.g. `foo.$any(1)`). This is handled correctly in other parts of the compiler, but it looks like it was missed in the type checker.
PR Close#44657
This page exists in the most recent angular.io version (v13 currently), so there's no need to link to an old version. The hash also refers to the title section of the page, which isn't necessary and is now dropped.
PR Close#44649
Dev mode output was switched from ES5 -> ES2015 recently and as a part of those changes, some target names that contained `_es5` postfixes were changes to `_es2015` instead. This commit fixes the issue with one of the recently merged BUILD files that contained the old (`_es5`) postfix.
PR Close#44651
When building a library, the `rootDir` option is configured to ensure
that all source files are present within the entry-point that is being
build. This imposes an extra constraint on the reference emit logic,
which does not allow emitting a reference into a source file outside of
this `rootDir`.
During the generation of type-check blocks we used to make a best-effort
estimation of whether a type reference can be emitted into the
type-check file. This check was relaxed in #42492 to support emitting
more syntax forms and type references, but this change did not consider
the `rootDir` constraint that is present in library builds. As such, the
compiler might conclude that a type reference is eligible for emit into
the type-check file, whereas in practice this would cause a failure.
This commit changes the best-effort estimation into a "preflight"
reference emit that is fully accurate as to whether emitting a type
reference is possible.
Fixes#43624
PR Close#44587
The `NgtscCompilerHost` is implemented using the `FileSystem`
abstraction of the compiler, which is implemented for tests using an
in-memory `MockFileSystem`. If the in-memory filesystem contains
symlinks, then using `NgtscCompilerHost` would not reflect their
resolved real path. Instead, the TypeScript compiler would use its
default implementation based on the real filesystem, which is unaware of
the in-memory `MockFileSystem` setup.
This change does not currently address any issues, but is being fixed
as it prevented a reproduction scenario from behaving correctly.
PR Close#44587
In certain scenarios, the compiler may have crashed with an
`Unable to write a reference` error which would be particularly hard
to diagnose. One of the primary reasons for this failure is when the
`rootDir` option is configured---typically the case for libraries---
and a source file is imported using a relative import from an external
entry-point. This would normally report TS6059 for the invalid relative
import, but the crash prevents this error from being surfaced.
This commit refactors the reference emit logic to result in an explicit
`Failure` state with a reason as to why the failure occurred. This state
is then used to report a `FatalDiagnosticException`, preventing a hard
crash.
Closes#44414
PR Close#44587
This commit performs some refactoring of the AbstractControl-based classes to employ shared `RuntimeError` class and also updates the code to avoid duplication and improve minification.
PR Close#44398
This commit moves some logic to make the location of runtime error codes consistent across packages. Now all error codes are located in `packages/core/src/errors.ts` file.
PR Close#44398
This commit updates the code around the `RuntimeError` class to make it more reusable between packages (currently it's only usable inside the `core` package). Specifically:
- the error formatting logic was updated to handle cases when there is no error message provided
- there is no special Set that contains a set of error codes for which we have guides on angular.io. Instead, this is now encoded into the error code itself (making such codes negative integers). Having a separate Set makes it non-tree-shakable, which we want to avoid.
This change should allow to employ the `RuntimeError` class in other packages to further standardize this subsystem and make the errors thrown by the framework consistent.
As a part of the refactoring, the `common` package code was also updated to follow the same logic as `core`, since the `RuntimeError` class was used there as well.
PR Close#44398
In angular.io links to the AnimationBuilder.build method are broken and do not
point to the api docs page, fix such broken links
Also apply minor wording and related improvements
PR Close#44594
Fixes a couple of tests that have been flaking our test runs. The two tests actually failed consistently when run in isolation, but they passed if at least one test ran before them. My understanding was that they failed, because they were running outside of the `NgZone` which meant that the errors being thrown inside of a `Promise` weren't being flushed.
PR Close#44597
* `forwardRef` does not work with ES2015 and TypeScript's decorator
downlevel emit. This is a known limitation we work around in Angular
applications by either compiling tests with the Angular compiler, or
by running a custom decorator downlevel transform (like in the CLI).
PR Close#44505
Updates the acceptance core tests to work with ES2015 devmode output.
There were two issues surfacing:
* The NodeJS test execution failed because Domino does not handle
destructuring syntax properly. This is because `Node.children` is not
an iterable.
* `forwardRef` does not work with ES2015 and TypeScript's decorator
downlevel emit. This is a known limitation we work around in Angular
applications by either compiling tests with the Angular compiler, or
by running a custom decorator downlevel transform (like in the CLI).
PR Close#44505
To make our test output i.e. devmode output more aligned
with what we produce in the NPM packages, or to be more
aligned with what Angular applications will usually consume,
the devmode output is switched from ES5 to ES2015.
Additionally various tsconfigs (outside of Bazel) have been
updated to match with the other parts of the build. The rules
are:
ES2015 for test configurations, ES2020 for actual code that will
end up being shipped (this includes the IDE-only tsconfigs).
PR Close#44505
This commit refactors the code of the base validators class to make it compatible with the property renaming optimization. Currently the code makes an assumption that the field with a specified name (defined as a string) can be found on an object, but with property renaming optimization this is not correct.
PR Close#44500
The Ivy compiler no longer generates code for type-checking purposes
using the output AST types. Instead, it uses TypeScript AST nodes and
its printer for type-checking. This commit removes the type-related
output nodes.
PR Close#44411
Alex Rickabaugh