It seems that new jasmine_test runner times out with the larger size shards, by splitting into double the shards the test consistently passes as expected
PR Close#62119
Migrates the partial compliance tests to `rules_js`. Also as part of
this, we re-enable RBE to see if that fixed the issues, or in case
they are already resolved from the RBE side.
PR Close#61865
Implements a compiler transform that attempts to statically analyze variable names and apply them to usages of signal functions like signal, computed, effect, etc.
PR Close#57348
This commit migrates the remaining pieces of `compiler-cli` to
`ts_project`. This involves a few more things during migration:
- the `ng_module` ngc_wrapped rule broke as part of this change, so we
switched it to `ts_project` too. This logic is soon gone anyway.
- we needed an extra pnpm "package.json" for the linker babel test. This test is
loading from the real compiler-cli npm package. Babel needs a real
node module for this, so this solution seems reasonable. It may be
worth exploring in the future to move this test into an integration
test though.
- the older integrationtest in compiler-cli is removed as the coverage
is much better with the compliance test suite and this test.
PR Close#61826
Replaces the `propertyInterpolateX` instructions with calls to `property` and the `interpolate` helper. This allows us to drop the dedicated interpolation instructions and simplify the runtime for future work.
PR Close#61639
Replaces the `classMapInterpolateX` instructions with `classMap` plus a call to `interpolate` in order to simplify the runtime. The only difference between `classMapInterpolateX` and `classMap` was that the former passes `keyValueArraySet` into `checkStylingMap` while the latter passes `classKeyValueArraySet`. This doesn't appear to matter, because the interpolation instructions always have a string value which means that the function is never called.
PR Close#61639
Replaces the `styleMapInterpolateX` instructions with the existing `styleMap` and a passed-in interpolated value in order to simplify the runtime.
PR Close#61639
Replaces the attribute interpolation instructions with `attribute` plus the new `interpolateX` instruction. This allows to reduce our overall instruction footprint.
PR Close#61557
No type-checking is performed in declaration-only emission mode so we
should explicitly disable it in the compliance tests.
This also aligns the compiler configuration with the setup used in
`packages/compiler-cli/test/ngtsc/declaration_only_emission_spec.ts`:
2b3c89dba2/packages/compiler-cli/test/ngtsc/declaration_only_emission_spec.ts (L31).
PR Close#61470
Fixes the `update_all_goldens` script which was throwing, because the query command was also capturing the call into yarn and Bazel which in turn caused it to throw an error. I've also added some validation for the number of targets.
PR Close#61407
In declaration-only emission mode, the compiler extracts the type
declarations (.d.ts) files without full type-checking, which is possible
with sufficient type annotations on exports that can be ensured by the
`isolatedDeclarations` TS compiler option.
This allows us to decouple type declaration emission from the actual
full compilation doing the type-checking, thereby removing the
edge between dependent TS files in the build action graph. In other
words, the compilation of a TS file no longer indirectly depends on the
compilation of all the TS files it imports through its dependency on
their type declarations, because the type declarations themselves no
longer depend on the compilation of their associated TS file.
Without the coupling between type declaration emission and compilation,
compilation time of a TS project is no longer bound dependent on the
depth of the TS dependency tree as we can now build the entire project
with just two entirely parallel phases: 1) emit the type declarations of
all TS files in parallel and 2) compile all TS files in parallel.
Since the Angular compiler adds static metadata fields to components,
directives, modules, pipes and services based on their respective class
annotations, it needs to actively partake in the type declaration
emission in order to provide the types for these static fields in the
declaration.
In this change, we add experimental support for a declaration-only
emission mode based on the local compilation mode, which already
operates without type-checking and access to external type information,
i.e. the same environment as is required for declaration-only emisssion.
Apart from the same restrictions applied in local compilation mode,
there are a few more restrictions imposed on code being compatible with
this initial and experimental implementation:
* No support for `@NgModule`s using external references.
* No support for `hostDirectives` in `@Component`s and `@Directive`s
using external references
* No support for `@Input` annotations with `transform`.
PR Close#61334
The compiler wasn't handling `@let` declarations placed inside i18n blocks. The problem is that `assignI18nSlotDependencies` phase assigns the `target` of i18n ops much earlier than the `@let` optimization. If the `@let` ends up getting optimized because it isn't used in any child views, the pointer in the i18n instruction becomes invalid. This hadn't surfaced so far, because we didn't optimize `declareLet` ops, however once we do, we start hitting assertions that the optimized `declareLet` isn't used anywhere.
These changes resolve the issue by moving the i18n phases after the `@let` optimization.
PR Close#60512
We have some code that avoids `storeLet` calls for declarations only used in the same view, however we didn't previously remove the corresponding `declareLet` calls, because of the following case:
```
@let foo = something$ | async; <!-- First in the template -->
{{foo}}
```
Here we need a `TNode` (created by `declareLet`) in order for DI to work correctly. Since this is only required when using pipes, we can optimize away expressions that do not have pipes.
PR Close#60512
This commit adds the support for the `in` keyword as a relational operator, with the same precedence as the other relational operators (<,>, <=, >=)
BREAKING CHANGE: 'in' in an expression now refers to the operator
PR Close#58432
Renames the `hostProperty` instruction to `domProperty` since it's not really host-specific and we can use it for other DOM-specific operations in the future.
PR Close#60608
The `TemplateLiteralElementExpr` has some logic where it tries to estimate the `rawText` if one isn't provided by looking at the node's source span. The problem with this approach is that we have some long-standing issues with our expression AST parser (see https://github.com/angular/angular/pull/60267#discussion_r1986402524) where it might not produce accurate spans if escape sequences are involved. This in turn can lead to unrecoverable errors, because TypeScript will throw an error if the raw string doesn't match the cooked one when constructing a TypeScript AST node.
These changes remove the logic that depends on the source span and relies purely on the secondary fallback that inserts escaped characters manually.
It's also worth noting that the `rawText` doesn't seem to matter much at this point, because the main usage of it is when downlevelling template literals to ES5 which we no longer support.
Fixes#60528.
PR Close#60529
This adds a new instruction for dealing with creating conditionals. It ensures flags are set on the TNode for later identification during hydration.
PR Close#60425
We've seen these tests regularly, but somewhat rarely to be
stuck/hanging in the remote execution workers. Since the issue was
reproducable locally (via local RBE environment), we can improve
stability for the team until we resolve this with the RBE team.
PR Close#60473
Improves the partial compliance golden generation to not rely on large
files being transmitted via `stdout`. Instead the files are written
directly as it's done in idiomatic Bazel generation actions.
In addition, we add extra stdout logging for the Bazel action, to see if
the process is actually invoked in RBE workers. Right now those are
occassionally stuck, but neither us, nor the RBE team can see anything
running, and they're occasionally stuck for 1hr.
PR Close#60427
Add support for the `void` operator in templates and host bindings.
This is useful when binding a listener that may return `false` and
unintentionally prevent the default event behavior.
Ex:
```
@Directive({
host: { '(mousedown)': 'void handleMousedown()' }
})
```
BREAKING CHANGE: `void` in an expression now refers to the operator
Previously an expression in the template like `{{void}}` referred to a
property on the component class. After this change it now refers to the
`void` operator, which would make the above example invalid. If you have
existing expressions that need to refer to a property named `void`,
change the expression to use `this.void` instead: `{{this.void}}`.
PR Close#59894
Currently when we generate the tracking expression for a `@for` block, we process its expression in the context of the creation block. This is incorrect, because the expression may require ops of its own for cases like nullish coalescing or safe reads. The result is that while we do generate the correct variable, they're added to the creation block rather than the tracking function which causes an error at runtime.
These changes address the issue by keeping track of a separate set of ops for the `track` expression that are prepended to the generated function, similarly to how we handle event listeners.
Fixes#56256.
PR Close#58520
When the compiler analyzes the defer blocks in a component, it generates two sets of dependencies: ones specific for each block and others from all the deferred blocks within the component. The logic that combines all the defer block dependencies wasn't de-duplicating them which resulted in us producing `setClassMetadataAsync` calls where the callback can have multiple parameters with the same name. This was a problem both in full and partial compilation, but the latter was more visible, because Babel throws an error in such cases.
These changes add some logic to de-duplicate the dependencies so that we produce valid code.
Fixes#59922.
PR Close#59926
Some time ago we narrowed down the expressions we support in two-way bindings, because in most cases any apart from property reads doesn't make sense. This ended up preventing users from using `$any` in the binding since it's considered a function call.
These changes update the validation logic to allow `$any`.
Fixes#51165.
PR Close#59362
Fixes an edge case where a control flow node that has non-projectable nodes followed by an element node at the end would cause the entire control flow node to be project. For example if we have a projection target of `Main: <ng-content/> Slot: <ng-content select="[foo]"/>`, inserting a node of `@if (true) {Hello <span foo>world</span>}` would project the entire `Hello world` into the `[foo]` slot.
In the process of working on the issue, I also found that `@let` declarations at the root of the control flow node would prevent content projection as well.
PR Close#58607
By removing the standalone feature, we reduce the amount of code generated for components but at the cost of including the `StandaloneService` in the main bundle even if no standalone components are included in it.
PR Close#58288
