test(compiler): add expression absolute span tests for `TemplateAst`s (#33253)
Previously, we had tested that expressions parsed in a Render3 AST
had correctly-defined absolute spans (spans relative to the entire
template, not the local expression). Sometimes we use Template ASTs
rather than Render3 ASTs, and it's desirable to test for correct
expression spans in the template parser as well.
Adding these tests resolved one bug, similar to the one fixed in
fd4fed14d8935866fe16d30648d115f3ebb5fd43, where expressions in the value
of a template attribute were not given an absolute span corresponding to
the start of the attribute name rather than the start of the attribute
value.
The diff on this commit is large, partially because it involves some
structural changes of the template parser testing layout. In particular,
the following is done:
1. Move `createMeta*`-like functions from `template_parser_spec.ts` to
be exported from a new test utility file.
2. Create an `ExpressionSourceHumanizer`, similar to the one created in
b04488d692ca11c83444da56f51d53c3ac868243, to allow convenient testing
of expressions' locations.
3. Create `template_parser_absolute_span_spec.ts`, testing the spans of
expressions parsed by the template parser. This is very similar to
the `r3_ast_absolute_span_spec`.
PR Close #33253
2019-10-18 10:51:20 -04:00
|
|
|
/**
|
|
|
|
* @license
|
|
|
|
* Copyright Google Inc. All Rights Reserved.
|
|
|
|
*
|
|
|
|
* Use of this source code is governed by an MIT-style license that can be
|
|
|
|
* found in the LICENSE file at https://angular.io/license
|
|
|
|
*/
|
2020-04-08 13:14:18 -04:00
|
|
|
import {CompileDirectiveMetadata, CompileEntryComponentMetadata, CompileProviderMetadata, CompileQueryMetadata, CompileStylesheetMetadata, CompileTemplateMetadata, CompileTypeMetadata, preserveWhitespacesDefault, ProxyClass, StaticSymbol} from '@angular/compiler';
|
test(compiler): add expression absolute span tests for `TemplateAst`s (#33253)
Previously, we had tested that expressions parsed in a Render3 AST
had correctly-defined absolute spans (spans relative to the entire
template, not the local expression). Sometimes we use Template ASTs
rather than Render3 ASTs, and it's desirable to test for correct
expression spans in the template parser as well.
Adding these tests resolved one bug, similar to the one fixed in
fd4fed14d8935866fe16d30648d115f3ebb5fd43, where expressions in the value
of a template attribute were not given an absolute span corresponding to
the start of the attribute name rather than the start of the attribute
value.
The diff on this commit is large, partially because it involves some
structural changes of the template parser testing layout. In particular,
the following is done:
1. Move `createMeta*`-like functions from `template_parser_spec.ts` to
be exported from a new test utility file.
2. Create an `ExpressionSourceHumanizer`, similar to the one created in
b04488d692ca11c83444da56f51d53c3ac868243, to allow convenient testing
of expressions' locations.
3. Create `template_parser_absolute_span_spec.ts`, testing the spans of
expressions parsed by the template parser. This is very similar to
the `r3_ast_absolute_span_spec`.
PR Close #33253
2019-10-18 10:51:20 -04:00
|
|
|
import {ChangeDetectionStrategy, RendererType2, ViewEncapsulation} from '@angular/core';
|
2020-04-08 13:14:18 -04:00
|
|
|
|
test(compiler): add expression absolute span tests for `TemplateAst`s (#33253)
Previously, we had tested that expressions parsed in a Render3 AST
had correctly-defined absolute spans (spans relative to the entire
template, not the local expression). Sometimes we use Template ASTs
rather than Render3 ASTs, and it's desirable to test for correct
expression spans in the template parser as well.
Adding these tests resolved one bug, similar to the one fixed in
fd4fed14d8935866fe16d30648d115f3ebb5fd43, where expressions in the value
of a template attribute were not given an absolute span corresponding to
the start of the attribute name rather than the start of the attribute
value.
The diff on this commit is large, partially because it involves some
structural changes of the template parser testing layout. In particular,
the following is done:
1. Move `createMeta*`-like functions from `template_parser_spec.ts` to
be exported from a new test utility file.
2. Create an `ExpressionSourceHumanizer`, similar to the one created in
b04488d692ca11c83444da56f51d53c3ac868243, to allow convenient testing
of expressions' locations.
3. Create `template_parser_absolute_span_spec.ts`, testing the spans of
expressions parsed by the template parser. This is very similar to
the `r3_ast_absolute_span_spec`.
PR Close #33253
2019-10-18 10:51:20 -04:00
|
|
|
import {noUndefined} from '../../../src/util';
|
|
|
|
|
|
|
|
export function createTypeMeta({reference, diDeps}: {reference: any, diDeps?: any[]}):
|
|
|
|
CompileTypeMetadata {
|
|
|
|
return {reference: reference, diDeps: diDeps || [], lifecycleHooks: []};
|
|
|
|
}
|
|
|
|
|
2020-04-08 13:14:18 -04:00
|
|
|
export function compileDirectiveMetadataCreate({
|
|
|
|
isHost,
|
|
|
|
type,
|
|
|
|
isComponent,
|
|
|
|
selector,
|
|
|
|
exportAs,
|
|
|
|
inputs,
|
|
|
|
outputs,
|
|
|
|
host,
|
|
|
|
providers,
|
|
|
|
viewProviders,
|
|
|
|
queries,
|
|
|
|
guards,
|
|
|
|
viewQueries,
|
|
|
|
entryComponents,
|
|
|
|
template,
|
|
|
|
componentViewType,
|
|
|
|
rendererType
|
|
|
|
}: Partial<Parameters<typeof CompileDirectiveMetadata.create>[0]>) {
|
test(compiler): add expression absolute span tests for `TemplateAst`s (#33253)
Previously, we had tested that expressions parsed in a Render3 AST
had correctly-defined absolute spans (spans relative to the entire
template, not the local expression). Sometimes we use Template ASTs
rather than Render3 ASTs, and it's desirable to test for correct
expression spans in the template parser as well.
Adding these tests resolved one bug, similar to the one fixed in
fd4fed14d8935866fe16d30648d115f3ebb5fd43, where expressions in the value
of a template attribute were not given an absolute span corresponding to
the start of the attribute name rather than the start of the attribute
value.
The diff on this commit is large, partially because it involves some
structural changes of the template parser testing layout. In particular,
the following is done:
1. Move `createMeta*`-like functions from `template_parser_spec.ts` to
be exported from a new test utility file.
2. Create an `ExpressionSourceHumanizer`, similar to the one created in
b04488d692ca11c83444da56f51d53c3ac868243, to allow convenient testing
of expressions' locations.
3. Create `template_parser_absolute_span_spec.ts`, testing the spans of
expressions parsed by the template parser. This is very similar to
the `r3_ast_absolute_span_spec`.
PR Close #33253
2019-10-18 10:51:20 -04:00
|
|
|
return CompileDirectiveMetadata.create({
|
|
|
|
isHost: !!isHost,
|
2020-04-08 13:14:18 -04:00
|
|
|
type: noUndefined(type)!,
|
test(compiler): add expression absolute span tests for `TemplateAst`s (#33253)
Previously, we had tested that expressions parsed in a Render3 AST
had correctly-defined absolute spans (spans relative to the entire
template, not the local expression). Sometimes we use Template ASTs
rather than Render3 ASTs, and it's desirable to test for correct
expression spans in the template parser as well.
Adding these tests resolved one bug, similar to the one fixed in
fd4fed14d8935866fe16d30648d115f3ebb5fd43, where expressions in the value
of a template attribute were not given an absolute span corresponding to
the start of the attribute name rather than the start of the attribute
value.
The diff on this commit is large, partially because it involves some
structural changes of the template parser testing layout. In particular,
the following is done:
1. Move `createMeta*`-like functions from `template_parser_spec.ts` to
be exported from a new test utility file.
2. Create an `ExpressionSourceHumanizer`, similar to the one created in
b04488d692ca11c83444da56f51d53c3ac868243, to allow convenient testing
of expressions' locations.
3. Create `template_parser_absolute_span_spec.ts`, testing the spans of
expressions parsed by the template parser. This is very similar to
the `r3_ast_absolute_span_spec`.
PR Close #33253
2019-10-18 10:51:20 -04:00
|
|
|
isComponent: !!isComponent,
|
|
|
|
selector: noUndefined(selector),
|
|
|
|
exportAs: noUndefined(exportAs),
|
|
|
|
changeDetection: null,
|
|
|
|
inputs: inputs || [],
|
|
|
|
outputs: outputs || [],
|
|
|
|
host: host || {},
|
|
|
|
providers: providers || [],
|
|
|
|
viewProviders: viewProviders || [],
|
|
|
|
queries: queries || [],
|
|
|
|
guards: guards || {},
|
|
|
|
viewQueries: viewQueries || [],
|
|
|
|
entryComponents: entryComponents || [],
|
2020-04-08 13:14:18 -04:00
|
|
|
template: noUndefined(template)!,
|
test(compiler): add expression absolute span tests for `TemplateAst`s (#33253)
Previously, we had tested that expressions parsed in a Render3 AST
had correctly-defined absolute spans (spans relative to the entire
template, not the local expression). Sometimes we use Template ASTs
rather than Render3 ASTs, and it's desirable to test for correct
expression spans in the template parser as well.
Adding these tests resolved one bug, similar to the one fixed in
fd4fed14d8935866fe16d30648d115f3ebb5fd43, where expressions in the value
of a template attribute were not given an absolute span corresponding to
the start of the attribute name rather than the start of the attribute
value.
The diff on this commit is large, partially because it involves some
structural changes of the template parser testing layout. In particular,
the following is done:
1. Move `createMeta*`-like functions from `template_parser_spec.ts` to
be exported from a new test utility file.
2. Create an `ExpressionSourceHumanizer`, similar to the one created in
b04488d692ca11c83444da56f51d53c3ac868243, to allow convenient testing
of expressions' locations.
3. Create `template_parser_absolute_span_spec.ts`, testing the spans of
expressions parsed by the template parser. This is very similar to
the `r3_ast_absolute_span_spec`.
PR Close #33253
2019-10-18 10:51:20 -04:00
|
|
|
componentViewType: noUndefined(componentViewType),
|
|
|
|
rendererType: noUndefined(rendererType),
|
|
|
|
componentFactory: null,
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2020-04-08 13:14:18 -04:00
|
|
|
export function compileTemplateMetadata({
|
|
|
|
encapsulation,
|
|
|
|
template,
|
|
|
|
templateUrl,
|
|
|
|
styles,
|
|
|
|
styleUrls,
|
|
|
|
externalStylesheets,
|
|
|
|
animations,
|
|
|
|
ngContentSelectors,
|
|
|
|
interpolation,
|
|
|
|
isInline,
|
|
|
|
preserveWhitespaces
|
|
|
|
}: Partial<CompileTemplateMetadata>): CompileTemplateMetadata {
|
test(compiler): add expression absolute span tests for `TemplateAst`s (#33253)
Previously, we had tested that expressions parsed in a Render3 AST
had correctly-defined absolute spans (spans relative to the entire
template, not the local expression). Sometimes we use Template ASTs
rather than Render3 ASTs, and it's desirable to test for correct
expression spans in the template parser as well.
Adding these tests resolved one bug, similar to the one fixed in
fd4fed14d8935866fe16d30648d115f3ebb5fd43, where expressions in the value
of a template attribute were not given an absolute span corresponding to
the start of the attribute name rather than the start of the attribute
value.
The diff on this commit is large, partially because it involves some
structural changes of the template parser testing layout. In particular,
the following is done:
1. Move `createMeta*`-like functions from `template_parser_spec.ts` to
be exported from a new test utility file.
2. Create an `ExpressionSourceHumanizer`, similar to the one created in
b04488d692ca11c83444da56f51d53c3ac868243, to allow convenient testing
of expressions' locations.
3. Create `template_parser_absolute_span_spec.ts`, testing the spans of
expressions parsed by the template parser. This is very similar to
the `r3_ast_absolute_span_spec`.
PR Close #33253
2019-10-18 10:51:20 -04:00
|
|
|
return new CompileTemplateMetadata({
|
|
|
|
encapsulation: noUndefined(encapsulation),
|
|
|
|
template: noUndefined(template),
|
|
|
|
templateUrl: noUndefined(templateUrl),
|
|
|
|
htmlAst: null,
|
|
|
|
styles: styles || [],
|
|
|
|
styleUrls: styleUrls || [],
|
|
|
|
externalStylesheets: externalStylesheets || [],
|
|
|
|
animations: animations || [],
|
|
|
|
ngContentSelectors: ngContentSelectors || [],
|
|
|
|
interpolation: noUndefined(interpolation),
|
|
|
|
isInline: !!isInline,
|
|
|
|
preserveWhitespaces: preserveWhitespacesDefault(noUndefined(preserveWhitespaces)),
|
|
|
|
});
|
|
|
|
}
|