Compiler portion for supporting content queries in signal components.
This is based on the preparation work, for detecting such queries. See
previous commits.
New implementation of type-checking for signal inputs. Much simpler, and
without causing signficant type check block changes that would require
more changes to the language service completion logic / or rewrites of
more than 50+ handwritten code output tests for type check blocks.
See previous commits for other explored solutions.
NOTE: This is very experimental and manual type check block code is not
updated. All of this complexity arises from the fact of attempting to
support bindings where they go to the same directive with multiple
inputs of the same name.
Potentially we can deprecate this behavior for input signal based
components and avoid this complexity. Alternative solution is to simply
repeat expression diagnostics if a binding goes to two same fields.
Previously the compiler output AST did not support using
`o.BinaryExpression` for assignments (as TypeScript does). Instead
`o.WriteVarExpr` is defined, which only allows writing to string named
variables.
There was an interesting issue that surfaced in the type checking
tests. Previously an input was type-checked using an expression like:
```ts
myDir.input = myrDir.input2 = userExpr
```
Note how the user expression was only specified once. With signals for
type-checking we cannot do this because both inputs cannot use the same
expression unless we extract it into a separate variable. This is what
this commit implemements.
```ts
const x1 = userExpr;
toWriteableSignal(myDir.input).set(x1);
toWriteableSignal(myDir.input2).set(x2);
```
Note: Even if no input is bound, due to e.g. the `inputs` decorator
field being used and no statically analyzable class member being
discoverable- the user expression should be *evaluated*. This was
something we broke with the initial signal input prototyping.
Compliance tests do not depend on the real typings for
`@angular/core`, but rather a fake core package is used.
We want to be able to write compliance tests using signals, so we should
add some rough types to the fake core package. This will also be useful
in `fake_core` for type checking tests.
A minimal change to full compilation mode to work in local mode. Now compiler can compile components without ctor injections, though the compiled code missing the following items which will be added in subsequent commits:
* it does not produce `dependencies` for component definition.
* it fails if component has ctor injection
PR Close#50545
The compiler will only include analysis and compile phases in local mode. Also a new `compileLocal` method is added to the annotation handler for local compilation.
This commit makes no change to the full/partial compilation code paths.
PR Close#50545
An internal compiler option named `supportJitMode` is now available for use by the Angular CLI.
This option currently controls the emit of NgModule selector scope information. This emitted
information is only needed in AOT mode when an application also uses JIT. However, AOT mode
combined with JIT mode is not currently supported nor will work in the Angular CLI. With
the Angular CLI, JIT mode is only supported if the entire application is built in JIT mode.
Without this option, the CLI needs to manually perform a code transform to remove the information
and also replicate TypeScript's import eliding. This is can be a complicated operation and must
be continually kept up to date with any changes to both the Angular compiler and TypeScript.
The introduction of this new option alleviates these concerns while also removing several build
time actions that would otherwise need to be performed on every application build.
PR Close#51007
This commit adds the ability to generate attribute instructions as a result of property bindings such as `[attr.foo]='bar'` or `attr.foo='{{bar}}'`. "Singleton" interpolations, such as the previous example, will also be transformed into a simple `attribute` instruction.
PR Close#50818
The option 'local compile' is added for the test cases, and the locally compiled file for an input `abc.ts` is compared by default with the file `abc.local.js`. This allows to use the same input `abc.ts` for both full compilation (compared with `abc.js`) and local compilation (compared with `abc.local.js`). An example is provided in the next commit when compliance tests are added for the NgModule local compilation.
PR Close#50577
The new interface is discrete-unioned with the existing interface to cover the cases for local and global (i.e., full and partial) compilation modes.
This change of interface required some adjustmeents cross repo which explains the changes made to other files.
PR Close#50577
All attempts related to obtaining R3Reference for bootstrap, imports, exports and declarations are cut in local compilation mode.
This will allow the analysis to pass without any error diagnostics, but the result is a quite empty meta info. Next commits will add data to the meta so that the NgModule can be compiled more accurately.
PR Close#50577
The expression `a()?.b` should expand into `(tmp = a()) === null ? null : tmp.b`, in order to avoid calling the function `a()` twice.
This commit modifies the null-safe-expansion algorithm to emit temporary assignments, and provides the reification code to actually generate the declarations, assignments, and reads.
Note also that, with our bottom-up algorithm, there are some tricky cases when a function call exists inside an indexed access, such as `f1()?.[f2()?.a]?.b`. We add some special logic to avoid generating a double-assignment to the temporary storing the result of `f2()`.
Finally, there are opportunities to reuse the same temporary in expressions like `a?.[f()]?.[f()]`. We save this for the next commit.
PR Close#50688
An internal compiler option named `supportTestBed` is now available for use by the
Angular CLI. This option currently controls the extraction and emit of Angular class
metadata. This emitted information is only needed in AOT mode when using certain
TestBed APIs. However, AOT mode is currently not available for unit testing within
the Angular CLI. As a result, the metadata is not used within CLI generation applications
and in particular production applications. Without this option, the CLI needs to
manually perform a code transform to remove the metadata and also replicate TypeScript's
import eliding. This is can be a complicated operation and must be continually kept
up to date with any changes to both the Angular compiler and TypeScript. The introduction
of this new option alleviates these concerns.
PR Close#50604
A larger investigation on why this is flaky is needed. Currently the
test is flaky with around 77% sucess rate and negatively impacts team
productivity. Subjectively, as reported by team members this it's much
more flaky than a success rate of 77%.
PR Close#50718
If a library is compiling with Angular v16.1.0, the library will break
for users that are still on Angular v16.0.x. This happens because the
`DirectiveDeclaration` or `ComponentDeclaration` types are not expecting
an extra field for `signals` metadata. This field was only added to the
generic types in `16.1.0`- so compilations fail with errors like this:
```
Error: node_modules/@angular/material/icon/index.d.ts:204:18 -
error TS2707: Generic type 'ɵɵComponentDeclaration' requires between 7 and 9 type arguments.
```
To fix this, we quickly roll back the code for inserting this metadata
field. That way, libraries remain compatible with all v16.x framework
versions.
We continue to include the `signals` metadata if `signals: true` is set.
This is not public API anyway right now- so cannot happen- but imagine
we expose some signal APIs in e.g. 16.2.x, then we'd need this metadata
and can reasonably expect signal-component library users to use a more
recent framework core version.
PR Close#50714
If the compiler CLI is running through closure compiler, the trait
decorator handlers are converted from classes to functions as ES5
is picked as default output target for the bundled version.
The problem is that currently all trait handlers end up having the
same `name`. i.e. an empty string, and therefore adopting previous
traits from a previous build iteration result in the incorrect handler
being used for e.g. registrering, compiling etc- causing
ambiguous/confusing errors down the line in other parts.
We can look into changing the output target in the future, but even
then we are safer using an actual literal due to property renaming.
```$$closure$$NgModuleDecoratorHandler = function() {}`.
It is is questionable if we should just simply NOT run the compiler
through JSCompiler.
PR Close#50673
Angular's null-safe access operators differ from Javascript's built-in semantics, in that they short-circuit to `null` instead of `undefined`. This necessitates providing a custom transformation, instead of relying on Typescript or Javascript itseld.
The old TemplateDefinitionBuilder uses a top-down approach based on the Visitor pattern, in which it recursively extracts the left-most safe access, and hoists it to a null check at the top. See `expression_converter.ts` for details.
In this commit, we replace that approach with a new bottom-up algorithm, as part of the template pipeline. This requires an intermediate expression type to represent the not-yet-expanded ternary operators, and is split into its own pass.
Null-safe function calls are not yet implemented, since they will rely on a future temporary variable allocation pass.
Co-authored-by: Alex Rickabaugh <alxhub@users.noreply.github.com>
PR Close#50594
Refactor attribute and property binding ingestion and add an attribute extraction phase
Co-authored-by: Alex Rickabaugh <alxhub@users.noreply.github.com>
Co-authored-by: Dylan Hunn <dylhunn@users.noreply.github.com>
Only add the value to the ElementAttributes map for style and attribute kinds
Other kinds should not have their value represented in the consts array
Add missing attribute ingesiton for templates
Unify how template and element bindings are ingested
This resolves the issue of missing listener attributes on templates. In
order to avoid emitting extraneous instructions, listener ops on
templates are stripped in the attribute extraction phase instead.
Handle different binding types separately in ingest
Cleanup code and comments
Disable test that fails on new explicit error.
Previously the test was passing because ingestPropertyBinding treated
attribute bindings as normal bindings which happened to be ok for the
particular test. Now there's an explicit error that attrbiute bindings
aren't yet handled which causes the test to fail
Address feeback
PR Close#50664
Add a flag to disable specific tests when testing the template pipeline
Mark the currently failing tests
Add the template pipeline tests to CI
Update package.json
Co-authored-by: Paul Gschwendtner <paulgschwendtner@gmail.com>
PR Close#50582
Paul Gschwendtner