This commit adds the `signals: boolean` property to the internal
directive/component metadata. This does not add it to the public API
yet, as the feature has no internal support other than compiler
detection.
PR Close#49981
This commit adds a phase to the template pipeline to merge `nextContext()`
instructions that follow each other without context reads in between. That
is, the sequence:
```typescript
nextContext();
var v1 = nextContext();
```
becomes:
```typescript
var v1 = nextContext(2);
```
PR Close#49797
This commit modifies the `ListenerOp` operation to capture the context
needed to generate the "correct" (per `TemplateDefinitionBuilder`) function
name for the handler function for the listener.
PR Close#49797
The `resetView` instruction in the template pipeline had a copy-paste error
where it was emitting a call to `reference` instead. This commit fixes the
issue.
PR Close#49797
This commit adds a chaining phase which post-processes reified template
pipeline operations, and collapses chainable instructions into chained
calls. Performing chaining as a post-processing step after reification
allows the specifically selected instruction variants to be known when
considering chaining two operations.
PR Close#49797
This commit adds a variable optimization pass to the template pipeline. The
pipeline generates all variables which might be referenced within a given
view's template function, regardless of whether other operations will read
those values.
The variable optimizer post-processes the IR and performs several variable-
related optimizations:
* It transforms variable declarations to side effectful expressions when the
variable is not used, but its initializer has global effects which other
operations rely upon.
* It removes variable declarations if those variables are not referenced and
either they do not have global effects, or nothing relies on them.
* It inlines variable declarations when those variables are only used once
and the inlining is semantically safe.
PR Close#49797
This commit teaches the template pipeline how to generate `textInterpolate`
when there's a single expression with no surrounding static text.
PR Close#49797
This commit reverses the generate template functions when adding them to the
constant pool in the template pipeline. This seems to better match the
ordering in which `TemplateDefinitionBuilder` generates template functions.
Further study is needed to determine if this is exactly accurate.
PR Close#49797
`advance()` was not emitted correctly by the template pipeline. There were
two problems:
* it was not handled in `transformExpressionsInOp()`.
* it was not added to the list correctly in `phaseGenerateAdvance()`.
This commit addresses both problems.
PR Close#49797
This commit fixes a broken assertion in the template pipeline concerning the
ownership of nodes in `insertBefore`, as well as adjusts a few other
assertions.
PR Close#49797
The template pipeline previously included an error when a static attribute
binding was found on an `<ng-template>`, under the assumption that this case
didn't happen in reality. It turns out that it does, so this commit removes
the error in favor of a comment to investigate the case further.
PR Close#49797
The template pipeline previously reified the parameters to `template()`
incorrectly. This commit adjusts the output to correctly reference the
attributes of the `template()` call.
PR Close#49797
This commit introduces a flag which is tracked while visiting expression
nodes in the template pipeline. This flag can be used to differentiate when
in an immediate evaluation context vs. a closure, which is useful for
certain operations.
PR Close#49797
The `TemplateDefinitionBuilder` has a specific pattern it uses for template
function names for embedded view template functions. This commit changes the
template pipeline to use the same format, allowing the generated code to
match between them.
PR Close#49797
The `TemplateDefinitionBuilder` uses the same name for the same semantic
variables across different views declared in a component. This commit
refactors the template pipeline's concept of `ir.SemanticVariable` to share
instances across all `ViewCompilation`s. This allows the `name` of the
variable to be stored on the `ir.SemanticVariable` instance instead of on
the `ir.VariableOp` (which makes sense as variables are often named based on
the `ir.SemanticVariable` anyway).
PR Close#49797
The template pipeline was previously reading the context of the wrong view,
resulting in incorrect generated code. Previously only `ctx` was being used,
since the context read was always that of the current view being compiled,
even for variables which exist on the contexts of parent views.
PR Close#49797
The template pipeline was emitting fields on the component definition in a
different order than the `TemplateDefinitionBuilder`, which causes test
failures. Additionally, the `consts` field was being emitted even if it was
empty.
PR Close#49797
Fixes that the compiler was matching directives based on `attr` bindings which doesn't correspond to the runtime behavior. This wasn't a problem until now because the matched directives would basically be a noop, but they can cause issues with required inputs.
PR Close#49713
This commit adds a Bazel flag which controls a constant in the compiler code.
When this flag (`--//packages/compiler:use_template_pipeline`) is specified, the
prototype template pipeline code is enabled.
This is not used in any production workflows and only works in the local Angular
repository. It will be used to develop the template pipeline against the
existing compliance tests.
PR Close#48580
This commit adds `transformTemplate` and `emitTemplateFn()` to the template
pipeline. These operations respectively apply all template compilation phases
in the right order, and then generate a final template function AST from the
template IR.
PR Close#48580
This commit introduces `phaseReify()` which performs "reification" of IR
operations. This converts previously semantic operations (e.g. `ir.Element`)
into generated instruction calls (`element(...)`). At the end of reification,
all operations have been converted into `ir.StatementOp`s, and the IR AST should
be suitable for emitting as generated code.
Note that after reification, more transformations may still be applied. For
example, instruction chaining will be performed post-reification, since it
depends on the exact selected instructions for each operation.
PR Close#48580
This commit introduces a new pipeline phase `phaseNaming()`, which tags
operations that generate function and variable declarations with generated names
to use when emitting those operations.
Currently this phase is using placeholder names. Eventually, we will want to
align its output with the current `TemplateDefinitionBuilder` names, in order to
pass the existing tests.
PR Close#48580
When executing the template update pass, the runtime keeps an internal
declaration slot pointer for which declaration (element, template, etc) is
the current subject of any binding or interpolation instructions. In between
update operations which reference different declarations, this pointer needs to
be adjusted, which is the job of the `advance()` instruction.
This commit introduces `phaseGenerateAdvance()` which inserts `advance()`
operations wherever necessary to satisfy this runtime requirement.
PR Close#48580
Operations and expressions in component update blocks can make use of variable
slots for storing data between executions (for example, the previous values of
expressions to use in change detection comparisons). The runtime must be told
how many variable slots to allocate for each view in a component declaration.
This commit adds a `phaseVarCounting()` phase to count the number of variables
used in different operations and expressions in a view. It makes uses of a new
marker trait `ConsumesVarsTrait` to determine which operations & expressions to
consider.
PR Close#48580
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
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
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
