Every declaration a template is stored in a data slot in the runtime. The
indices of these slots are passed to the declaration instructions in the
creation mode. In the update mode, several instructions (like `reference()` for
local references) also use the slot indices to reference declared items.
This commit introduces `phaseSlotAllocation()` to the template pipeline, which
allocates slots for declarations which need them, and propagates those slot
indices to other instructions which need to reference declared items via their
slot indices. To perform this association, the `XrefId` of the declared items
is used to link declarations with usages.
Slot allocation is abstracted from operations by the way of a new concept in the
pipeline: traits. A trait is a "mixin" on an operation, expression, or both that
allows phases to process any operation/expression which implements the trait
without needing specific logic for each concrete implementing type. Two traits
are introduced to support slot allocation: the `ConsumesSlotOpTrait` for
declarations which require a slot to be allocated, and the
`UsesSlotIndexExprTrait` for expressions which reference a declaration by its
slot index.
PR Close#48580
This commit serializes the attributes on element-like structures in the template
and converts them to constant arrays, which it lifts into the `consts` array for
the entire component compilation.
PR Close#48580
As an optimization, the runtime provides an `element()` instruction to use in
place of `elementStart()` and `elementEnd()` when there are no instructions
between them. This commit merges `ElementStart` and `ElementEnd` IR operations
into `Element` operations in that special case.
PR Close#48580
Local references declared on elements need to be represented in element/template
instructions via an index into the `consts` array. This commit adds the
`phaseLocalRefs()` phase to lift local reference declarations into the `consts`
array accordingly.
PR Close#48580
`phaseResolveContexts()` resolves `ir.ContextExpr` expressions within views.
Each `ir.ContextExpr` represents a reference to a particular view context. For
the context of the view being compiled, this is available in the view's template
function `ctx` parameter. For parent views, this is available in context
variables which were added previously.
`phaseResolveContexts()` replaces these `ir.ContextExpr` operations with
resolved references to the requested views.
PR Close#48580
This commit introduces `phaseResolveNames()` to the template pipeline. This
phase processes any `ir.LexicalReadExpr`s, which represent unresolved
identifiers from the user's expressions in the template, and attempts to match
them to concepts in the lexical scope of the template (such as local refs) or
to a property read of a component or embedded view context.
PR Close#48580
This commit implements the first "phase" of the template pipeline. Phases are
individual steps in compilation that perform a transformation of the IR in order
to move closer to generating runtime code for the template.
This first phase is `phaseGenerateVariables()`. This phase introduces variable
definition operations into the IR to define variables in each view. These
variables either represent internal operations (saving/restoring the view
context for listeners, for example) or variables created from user-defined names
such as local references or template context properties.
Every view has all possibly-referenced variables generated, regardless of
whether they're actually referenced by other operations. A future phase will
optimize the variables in each view, inlining those which are only read once and
removing those which are not referenced at all.
PR Close#48580
This commit implements `ingest()`, which converts a parsed template AST into
template pipeline IR. This is the first step of template compilation.
PR Close#48580
This commit adds the IR operations and expressions required to "ingest" a
template into the template pipeline. They form the starting point for template
compilation.
Ingestion is implemented in a following commit.
PR Close#48580
This commit adds support for custom derived `o.Expression` types in the template
pipeline. A base class is added with one current implementor
(`ir.LexicalReadExpr`). `ir.Expression`s encode semantic operations within
expression ASTs of IR operations.
PR Close#48580
This commit introduces the "template pipeline", a new compilation flow for
template compilation. This new flow is intended to eventually replace the
`TemplateDefinitionBuilder`. For now, it's being implemented in parallel with
the existing system with the goal of eventually passing all of the existing
compliance tests.
The new pipeline is based on an "intermediate representation" of a template -
operations which semantically encode what needs to happen at runtime to render
and change-detect the template. Using an IR allows for different concerns of
template compilation to be processed independently, which solves the biggest
problem with `TemplateDefinitionBuilder` today (the lack of separation of
concerns).
This commit introduces the IR concept of an operation and related typings, as
well as the structures used to represent templates and views during compilation.
Future commits will expand on this foundation as work on the pipeline proceeds.
PR Close#48580
This commit updates the minimum supported Node version across packages from 16.13.0 -> 16.14.0 to ensure compatibility with dependencies.
PR Close#49771
The concept of "internal" and "adjacent" type expression used to be necessary to support
ngcc, as it had to process downleveled class declarations using an IIFE, where the class
name within the IIFE could be different from the outer class name. With the removal of
ngcc we no longer need to make this distinction, so this commit removes these concepts
entirely.
PR Close#49136
Currently we are unsafely unquoting CSS values which in some cases causes valid values to become invalid and invalid values to become valid.
Example:
```html
<div style="width:"1px;""></div>
```
In the above case, `width` has an invalid value of `"1px"`, however the compiler will transform it to `1px` which makes it valid.
On the other hand, in the below case
```html
<div style="content:"foo""></div>
```
`content` has a valid value of `"foo"`, but since the compiler unwraps it to `foo` it becomes invalid. For correctness, we should not remove quotes.
```js
const div = document.createElement('div');
div.style.width='"1px"';
div.style.content='foo';
div.style.width; // ''
div.style.content; // ''
div.style.width='1px';
div.style.content='"foo"';
div.style.width; // '1px'
div.style.content; // '"foo"'
```
More information about values can be found https://www.w3.org/TR/CSS21/syndata.html#value-def-identifier
PR Close#49460
`entryComponents` have been deprecated since version 9, because with Ivy they weren't necessary. These changes remove any remaining references.
BREAKING CHANGE:
* `entryComponents` has been deleted from the `@NgModule` and `@Component` public APIs. Any usages can be removed since they weren't doing anyting.
* `ANALYZE_FOR_ENTRY_COMPONENTS` injection token has been deleted. Any references can be removed.
PR Close#49484
This commit updates parts of the FW to be ES2022 complaint.
These changes are needed to fix the following problems problems with using properties before they are initialized.
Example
```ts
class Foo {
bar = this.buz;
constructor(private buz: unknown){}
}
```
PR Close#49559
This commit updates parts of the FW to be ES2022 complaint.
These changes are needed to fix the following problems problems with using properties before they are initialized.
Example
```ts
class Foo {
bar = this.buz;
constructor(private buz: unknown){}
}
```
PR Close#49332
Adds support for marking a directive input as required. During template type checking, the compiler will verify that all required inputs have been specified and will raise a diagnostic if one or more are missing. Some specifics:
* Inputs are marked as required by passing an object literal with a `required: true` property to the `Input` decorator or into the `inputs` array.
* Required inputs imply that the directive can't work without them. This is why there's a new check that enforces that all required inputs of a host directive are exposed on the host.
* Required input diagnostics are reported through the `OutOfBandDiagnosticRecorder`, rather than generating a new structure in the TCB, because it allows us to provide a better error message.
* Currently required inputs are only supported during AOT compilation, because knowing which bindings are present during JIT can be tricky and may lead to increased bundle sizes.
Fixes#37706.
PR Close#49468
This reverts commit 13dd614cd1.
This breaks a g3 Typescript compilation tests where diagnostics are
expected for a missing input in the component.
PR Close#49467
Adds support for marking a directive input as required. During template type checking, the compiler will verify that all required inputs have been specified and will raise a diagnostic if one or more are missing. Some specifics:
* Inputs are marked as required by passing an object literal with a `required: true` property to the `Input` decorator or into the `inputs` array.
* Required inputs imply that the directive can't work without them. This is why there's a new check that enforces that all required inputs of a host directive are exposed on the host.
* Required input diagnostics are reported through the `OutOfBandDiagnosticRecorder`, rather than generating a new structure in the TCB, because it allows us to provide a better error message.
* Currently required inputs are only supported during AOT compilation, because knowing which bindings are present during JIT can be tricky and may lead to increased bundle sizes.
Fixes#37706.
PR Close#49453
This reverts commit 1a6ca68154.
This breaks tests in google3 which might be depending on private APIs. We
need to update these tests before we can land this PR.
PR Close#49449
Adds support for marking a directive input as required. During template type checking, the compiler will verify that all required inputs have been specified and will raise a diagnostic if one or more are missing. Some specifics:
* Inputs are marked as required by passing an object literal with a `required: true` property to the `Input` decorator or into the `inputs` array.
* Required inputs imply that the directive can't work without them. This is why there's a new check that enforces that all required inputs of a host directive are exposed on the host.
* Required input diagnostics are reported through the `OutOfBandDiagnosticRecorder`, rather than generating a new structure in the TCB, because it allows us to provide a better error message.
* Currently required inputs are only supported during AOT compilation, because knowing which bindings are present during JIT can be tricky and may lead to increased bundle sizes.
Fixes#37706.
PR Close#49304
BREAKING CHANGE: Node.js v14 support has been removed
Node.js v14 is planned to be End-of-Life on 2023-04-30. Angular will stop supporting Node.js v14 in Angular v16. Angular v16 will continue to officially support Node.js versions v16 and v18.
PR Close#49255
`strictStyling` was an option provided by Polymer but it's not needed by Angular. This commit removes the dead code and updates related comments.
PR Close#48824
Fixes that the expression converter was producing code that throws a runtime error if a non-null assertion is used as a part of a safe read, write or call.
Fixes#48742.
PR Close#48801
In Css, selectors with escaped characters require a space after if the following character is a hex character. ie: .\fc ber which matches class="über"
These escaped selectors happen for example when esbuild run with `optimization.minify`
fixes#48524
PR Close#48558
Reworks some of the existing compiler APIs to make them easier to use in a schematic and exposes a few new ones to surface information we already had. High-level list of changes:
* `getPotentialImportsFor` now requires a class reference, instead of a `PotentialDirective | PotentialPipe`.
* New `getNgModuleMetadata` method has been added to the type checker.
* New `getPipeMetadata` method has been added to the type checker.
* New `getUsedDirectives` method has been added to the type checker.
* New `getUsedPipes` method has been added to the type checker.
* The `decorator` property was exposed on the `TypeCheckableDirectiveMeta`. The property was already present at runtime, but it wasn't specified on the interface.
PR Close#48730
apply different quality of life improvements to the shadow
css unit tests:
- refactor the tests so that they are nicely divided in multiple files
in a logical manner instead of having most of them all in a single big file
- remove the css normalization logic inconsistently used throughout the tests, which
causes tests to be inconsistent and it also introduced unintuitive checks
- provide a shared shim utility function (instead of re-defining it
multiple times)
- add a `toEqualCss` matcher that can be used in the tests in order to
match css strings without caring about spacing and indentation
PR Close#48443
Allows for self-closing tags to be used for non-native tag names, e.g. `<foo [input]="bar"></foo>` can now be written as `<foo [input]="bar"/>`. Native tag names still have to have closing tags.
Fixes#39525.
PR Close#48535
Since we generate a `.mjs` file as entry-point for jasmine tests,
a couple of issues prevented the transitive dependencies from
bootstrap targets to be brought in (causing resolution errors):
1. The `_files` (previously `_esm2015`) targets are no longer needed,
and they also miss all the information on runfiles.
2. The aspect for computing linker mappings does not respect the
`bootstrap` attribute from the `spec_entrypoint` so we manually
add the extract ESM output targets (this rule works with the aspect
and forwards linker mappings).
PR Close#48521
For every `ts_library` target we expose a shorthand that grants
access to the JS files because `DefaultInfo` of a ts library
only exposes the `.d.ts` files.
We rename this away from `es2015` since in practice it's a much
higher target these days. Additionally we no longer use the devmode
output but rather use the prodmode output which has the explicit
`.mjs` output- compatible with ESM.
PR Close#48521
Replace custom `flatten` and `map` with native `flatMap` usage.
Benchmark:
| Test case name | Result |
|---------------- |-------------------------------------------------------- |
| flatten & map | flatten & map x 1,182 ops/sec ±2.18% (63 runs sampled) |
| flatMap | flatMap x 6,011 ops/sec ±0.91% (35 runs sampled) |
The fact that `flatMap` is faster is also highlighted in https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/flatMap
PR Close#48378
When using the legacy digest algorithm for i18n messages, the output hexadecimal
string now leverages a number's `toString()` function in addition to the `padStart`
string function to generate the result. This removes the need for several helper
functions which involved a series of iteration and bitwise operations to previously
generate the same output.
PR Close#48362
improve the emulated shadowDom implementation so that it can correctly
scope selectors present inside the @container at-rule (recently added
to the css specs)
resolves#48264
PR Close#48353
The native UTF-8 encoder (`TextEncoder`) provides its output as a `Uint8Array`
which is a specialized `TypedArray` for storing byte values. To remove the need
to copy and transform this data multiple times, a `DataView` is used to allow
for low-level access to the data in a variety of bit-widths and endianness.
The `DataView` class is natively available and supported by all browsers and
Node.js versions support by the framework (https://caniuse.com/mdn-javascript_builtins_dataview).
PR Close#48256
Instead of relying on a custom implementation of a UTF-8 text encoder that needs to
be maintained by the Angular team, the i18n message digesting process now uses the
native `TextEncoder` class. This class is available for use in all browsers and Node.js
versions supported by the Angular framework (https://caniuse.com/textencoder). The
custom encoder is still used by the compiler's source map generator and cannot yet be
fully removed.
PR Close#48256
This commit updates the logic related to the attribute and property binding rules for <iframe> elements. There is a set of <iframe> attributes that may affect the behavior of an iframe and this change enforces that these attributes are only applied as static attributes, making sure that they are taken into account while creating an <iframe>.
If Angular detects that some of the security-sensitive attributes are applied as an attribute or property binding, it throws an error message, which contains the name of an attribute that is causing the problem and the name of a Component where an iframe is located.
BREAKING CHANGE:
Existing iframe usages may have security-sensitive attributes applied as an attribute or property binding in a template or via host bindings in a directive. Such usages would require an update to ensure compliance with the new stricter rules around iframe bindings.
PR Close#47964
This reverts commit 2d08965b1a.
The reason for revert is that we've identified some issues with implementation. The issues will get addressed soon and the fix would be re-submitted.
PR Close#47959
Alex Rickabaugh