In ES5 the class consists of an outer variable declaration that is
initialised by an IIFE. Inside the IIFE the class is implemented by
an inner function declaration that is returned from the IIFE.
This inner declaration may have a different name to the outer
declaration.
This commit overrides `getInternalNameOfClass()` and
`getAdjacentNameOfClass()` in `Esm5ReflectionHost` with methods that
can find the correct inner declaration name identifier.
PR Close#33533
When compiling an Angular decorator (e.g. Directive), @angular/compiler
generates an 'expression' to be added as a static definition field
on the class, a 'type' which will be added for that field to the .d.ts
file, and a statement adjacent to the class that calls `setClassMetadata()`.
Previously, the same WrappedNodeExpr of the class' ts.Identifier was used
within each of this situations.
In the ngtsc case, this is proper. In the ngcc case, if the class being
compiled is within an ES5 IIFE, the outer name of the class may have
changed. Thus, the class has both an inner and outer name. The outer name
should continue to be used elsewhere in the compiler and in 'type'.
The 'expression' will live within the IIFE, the `internalType` should be used.
The adjacent statement will also live within the IIFE, the `adjacentType` should be used.
This commit introduces `ReflectionHost.getInternalNameOfClass()` and
`ReflectionHost.getAdjacentNameOfClass()`, which the compiler can use to
query for the correct name to use.
PR Close#33533
This commit moves nested i18n section detection to an earlier stage where we convert HTML AST to Ivy AST. This also gives a chance to produce better diagnistic message for nested i18n sections, that also includes a file name and location.
PR Close#33583
This patch introduces a `firstUpdatePass` flag which can be used inside
of instruction code to determine if this is the first time each
instruction is running inside of the update block of a template or
a hostBindings function.
PR Close#31270
We already store a reference to a native host of a component
view so we can drop the getHostNative utility function (that
was getting the same reference from another data structure).
PR Close#33554
In ViewEngine we used to throw an error if we encountered an unknown element while rendering. We have this already for Ivy in AoT, but we didn't in JiT. These changes implement the error for JiT mode.
PR Close#33419
The 4b81bb5c97 patch seemingly broke the
`profile_all.js` file due to the file renaming. This patch restores the
functionality of said script.
PR Close#33494
These exports are no longer used by the CLI since 7.1.0. Since major versions of the CLI are now locked to major versions of the framework, a CLI user will not be able to use FW 9.0+ on an outdated version (<7.1.0) of the CLI that uses these old APIs.
PR Close#33242
During static evaluation of expressions within ngtsc, it may occur that
certain expressions or just parts thereof cannot be statically
interpreted for some reason. The static interpreter keeps track of the
failure reason and the code path that was evaluated by means of
`DynamicValue`, which will allow descriptive errors. In some situations
however, the static interpreter would throw an exception instead,
resulting in a crash of the compilation. Not only does this cause
non-descriptive errors, more importantly does it prevent the evaluated
result from being partial, i.e. parts of the result can be dynamic if
their value does not have to be statically available to the compiler.
This commit refactors the static interpreter to never throw errors for
certain expressions that it cannot evaluate.
Resolves FW-1582
PR Close#33453
Using the async pipe as the very first example makes it very confusing for beginners. Most people believe that | async is required for ngFor. I would remove that part to make the example solely focused on NgFor.
PR Close#33378
Previously the compiler would crash if a pipe was encountered which did not
match any pipe in the scope of a template.
This commit introduces a new diagnostic error for unknown pipes instead.
PR Close#33454
Previously the template binder would crash when encountering an unknown
localref (# reference) such as `<div #ref="foo">` when no directive has
`exportAs: "foo"`.
With this commit, the compiler instead generates a template diagnostic error
informing the user about the invalid reference.
PR Close#33454
- resolves "Invariant violated (initialize): latest hash null has no known manifest"
- Thanks to @gkalpak and @hsta for helping test and investigate this fix
Fixes#25611
PR Close#32525
Before this change instantiating multiple directives on the same
host node would result in repeated RNode retrieval and patching.
This commint re-organises code around directive instance creation
so the host node processing (common to all directives) happens
once and only once.
As the additional benefit the directive instantiation logic gets
centralised in one function (at the expense of patching logic
duplication for root node).
PR Close#33322
Previously declarations that were imported via a namespace import
were given the same `bestGuessOwningModule` as the context
where they were imported to. This causes problems with resolving
`ModuleWithProviders` that have a type that has been imported in
this way, causing errors like:
```
ERROR in Symbol UIRouterModule declared in
.../@uirouter/angular/uiRouterNgModule.d.ts
is not exported from
.../@uirouter/angular/uirouter-angular.d.ts
(import into .../src/app/child.module.ts)
```
This commit modifies the `TypescriptReflectionHost.getDirectImportOfIdentifier()`
method so that it also understands how to attach the correct `viaModule` to
the identifier of the namespace import.
Resolves#32166
PR Close#33495
Currently if one of the project targets could not be analyzed
due to AOT compiler program failures, we gracefully proceed
with the migration. This is expected, but we should not
print a message at the end of the migration that the migration
was _successful_. The migration was only done partially, hence
it's potentially incomplete and we should make it clear that once
the failures are resolved, the migration should be re-run.
PR Close#33315
Also removes `build:remote --spawn_strategy=remote` from .bazelrc. It seems that with Bazel 1.0.0 setting `--incompatible_list_based_execution_strategy_selection=false` no longer works around the issue with npm_package that it did when it was added. The error that was originally observed has returned after updating to Bazel 1.0.0:
```
ERROR: /home/circleci/ng/packages/angular_devkit/build_optimizer/BUILD:66:1: Assembling npm package packages/angular_devkit/build_optimizer/npm_package failed: No usable spawn strategy found for spawn with mnemonic Action. Your --spawn_strategy, --genrule_strategy or --strategy flags are probably too strict. Visit https://github.com/bazelbuild/bazel/issues/7480 for migration advice
```
This commit removes both `—incompatible_list_based_execution_strategy_selection=false` as well as `build:remote --spawn_strategy=remote` which means that Bazel will do the default behavior of picking the first available strategy from the default list, which is `remote,worker,sandboxed,local`. See https://github.com/bazelbuild/bazel/issues/7480 for more details.
Not updating to Bazel 1.1.0 yet due to a docker permissions CI issue that was observed on the angular repo that is unresolved. See https://github.com/angular/angular/pull/33367#issuecomment-547643246.
PR Close#33476
Note: the @angular/bazel schematic now appends the package.json "script" field with 'ngcc --properties es2015 browser module main'. If there is an existing script field with ngcc then the schematic modifies it in place removing `--first-only` and `--create-ivy-entry-points`.
ViewEngine sources under node_modules need to be updated in-place for Bazel as it does not know how to use the `__ivy__` entry points that are created by the non-bazel `ngcc` command that is added to "scripts" :`ngcc --properties es2015 browser module main --first-only --create-ivy-entry-points`.
PR Close#33435
Now that we've replaced `ngBaseDef` with an abstract directive definition, there are a lot more cases where we generate a directive definition without a selector. These changes make it so that we don't generate the `selectors` array if it's going to be empty.
PR Close#33431
The parser was accidentally reading the `target` tag
below the `alt-trans` target and overriding the correct
`target` tag.
(This already worked in `$localize` but a test has been
added to confirm.)
Fixes#33161
PR Close#33450
Prior to this commit, i18n logic which ensures that elements removed in a translation are also removed in DOM, didn't take into account the fact that elements may have local refs. As a result, remove operation failed, since there is no corresponding tNode found. This commit updates the logic to skip all local refs while going though the list of nodes to ensure that DOM matches elements present in translation.
PR Close#33415
Adds a `replacementSpan` field on a completion that will allow typed
text to be replaced with the suggested completion value if a user
selects the completion. Previously, the completion value would simply be
appended to the text already typed. E.g. if we had
```
{{ti}}
```
typed in a template and `title` was recommended as a completion and
selected, the template would become
```
{{tititle}}
```
With `replacementSpan`, the original text `ti` will be replaced for
`title`.
PR Close#33091
With the next version of the CLI we don't need to add logging for the description of the schematic as part of the schematic itself.
This is because now, the CLI will print the description defined in the `migrations.json` file.
See: https://github.com/angular/angular-cli/pull/15951
PR Close#33440
Each of the XML based `TranslationParsers` was providing its own
`MessageSerializer`, but they are all very similar. So these have been
consolidated into a single more generic `MessageSerializer.
As a result of this, the extra layers of folders in the project seemed
unnecessary, so they have been flattened.
PR Close#33444
`bindingIndex` stores the current location of the bindings in the
template function. Because it used to be stored in `LView` that `LView`
was not reentrant. This could happen if a binding was a getter and had
a side-effect of calling `detectChanges()`.
By moving the `bindingIndex` to `LFrame` where all of the global state
is kept in reentrant way we correct the issue.
PR Close#33235
This commit simplifies the logic of `ExpressionVisitor` in
`completions.ts`.
Specifically,
1. helper functions `uniqueByName` and `lowerName` are removed.
2. Clean up the logic in visitElement()
3. Reorder constructor params
4. Add methods `addAttributeValuesToCompletions`,
`addKeysToCompletions`, and `addSymbolsToCompletions`.
PR Close#33391