Commit Graph

290 Commits

Author SHA1 Message Date
Kara Erickson 214ae0ea4c test(compiler): update examples and compiler tests (#30626)
PR Close #30626
2019-05-23 10:31:32 -07:00
Alan Agius 077809398c test: fix compiler tests in windows ci (#30482)
This is a tentative fix for the error `Cannot write file '/node_modules/@angular/core/core.ngfactory.d.ts' because it would overwrite input file.` that is showing in codefresh windows ci.

PR Close #30482
2019-05-16 09:43:01 -07:00
Alan Agius f9404d9e7c refactor: remove unused local imports and use spread instead of slice (#30482)
This is a purly estatic change and a minor cleanup

PR Close #30482
2019-05-16 09:43:01 -07:00
Alan Agius b766987b98 build: remove extra unused deps for `compiler:test` (#30482)
It's unnecessary for a jasmine_node_test rule to depend on a TypeScript library. This dependency is already satisfied via the 'data' and also having it in 'deps' causes CI flakiness on Windows

PR Close #30482
2019-05-16 09:43:01 -07:00
Ben Lesh 452f121486 fix: ensure strict mode when evaluating in JIT (#30122)
PR Close #30122
2019-05-08 14:34:10 -07:00
Alan 1660b34e2d test: fix several bazel compiler-cli tests in windows (#30189)
```
//packages/compiler-cli/integrationtest:integrationtest
//packages/compiler-cli/test/compliance:compliance
```

Partially addresses #29785

PR Close #30189
2019-05-07 10:21:36 -07:00
Pete Bacon Darwin 304a12f027 feat(compiler): support skipping leading trivia in template source-maps (#30095)
Leading trivia, such as whitespace or comments, is
confusing for developers looking at source-mapped
templates, since they expect the source-map segment
to start after the trivia.

This commit adds skipping trivial characters to the lexer;
and then implements that in the template parser.

PR Close #30095
2019-04-25 12:36:54 -07:00
Keen Yee Liau 28fd5ab12b fix(compiler): Fix compiler crash due to isSkipSelf of null (#30075)
PR Closes https://github.com/angular/angular/issues/27125

PR Close #30075
2019-04-24 17:06:53 -07:00
Alex Rickabaugh bea85ffe9c fix(ivy): match microsyntax template directives correctly (#29698)
Previously, Template.templateAttrs was introduced to capture attribute
bindings which originated from microsyntax (e.g. bindings in *ngFor="...").
This means that a Template node can have two different structures, depending
on whether it originated from microsyntax or from a literal <ng-template>.

In the literal case, the node behaves much like an Element node, it has
attributes, inputs, and outputs which determine which directives apply.
In the microsyntax case, though, only the templateAttrs should be used
to determine which directives apply.

Previously, both the t2_binder and the TemplateDefinitionBuilder were using
the wrong set of attributes to match directives - combining the attributes,
inputs, outputs, and templateAttrs of the Template node regardless of its
origin. In the TDB's case this wasn't a problem, since the TDB collects a
global Set of directives used in the template, so it didn't matter whether
the directive was also recognized on the <ng-template>. t2_binder's API
distinguishes between directives on specific nodes, though, so it's more
sensitive to mismatching.

In particular, this showed up as an assertion failure in template type-
checking in certain cases, when a directive was accidentally matched on
a microsyntax template element and also had a binding which referenced a
variable declared in the microsyntax. This resulted in the type-checker
attempting to generate a reference to a variable that didn't exist in that
scope.

The fix is to distinguish between the two cases and select the appropriate
set of attributes to match on accordingly.

Testing strategy: tested in the t2_binder tests.

PR Close #29698
2019-04-19 11:15:25 -07:00
Pete Bacon Darwin 6feef368f6 test(ivy): add tests for component factory projectable node corner cases (#27791)
In some cases ivy expects projectable nodes to be passed in a different order
to ViewEngine. Specifically, ivy expects the catch-all ("*") to be at index
0, whereas ViewEngine expects it to be at its position at which it was parsed
in the template.

This commit adds one test that breaks under ivy and others that just describe
more accurately what happens in corner cases.

PR Close #27791
2019-03-25 13:47:48 -07:00
Pawel Kozlowski dafbbf8b64 fix(core): parse incorrect ML open tag as text (#29328)
This PR alligns markup language lexer with the previous behaviour in version 7.x:
https://stackblitz.com/edit/angular-iancj2

While this behaviour is not perfect (we should be giving users an error message
here about invalid HTML instead of assuming text node) this is probably best we
can do without more substential re-write of lexing / parsing infrastructure.

This PR just fixes #29231 and restores VE behaviour - a more elaborate fix will
be done in a separate PR as it requries non-trivial rewrites.

PR Close #29328
2019-03-19 23:23:31 -04:00
Matias Niemelä a3ec058f6b revert: fix(core): parse incorrect ML open tag as text (#29328) 2019-03-19 11:12:32 -07:00
Pawel Kozlowski 4605df83e1 fix(core): parse incorrect ML open tag as text (#29328)
This PR alligns markup language lexer with the previous behaviour in version 7.x:
https://stackblitz.com/edit/angular-iancj2

While this behaviour is not perfect (we should be giving users an error message
here about invalid HTML instead of assuming text node) this is probably best we
can do without more substential re-write of lexing / parsing infrastructure.

This PR just fixes #29231 and restores VE behaviour - a more elaborate fix will
be done in a separate PR as it requries non-trivial rewrites.

PR Close #29328
2019-03-19 13:30:20 -04:00
Pawel Kozlowski f2dc32e5c7 fix(core): don't wrap `<tr>` and `<col>` elements into a required parent (#29219)
BREAKING CHANGE:

Certain elements (like `<tr>` or `<col>`) require parent elements to be of a certain type by the HTML specification
(ex. <tr> can only be inside <tbody> / <thead>). Before this change Angular template parser was auto-correcting
"invalid" HTML using the following rules:
- `<tr>` would be wrapped in `<tbody>` if not inside `<tbody>`, `<tfoot>` or `<thead>`;
- `<col>` would be wrapped in `<colgroup>` if not inside `<colgroup>`.

This meachanism of automatic wrapping / auto-correcting was problematic for several reasons:
- it is non-obvious and arbitrary (ex. there are more HTML elements that has rules for parent type);
- it is incorrect for cases where `<tr>` / `<col>` are at the root of a component's content, ex.:

```html
<projecting-tr-inside-tbody>
  <tr>...</tr>
</projecting-tr-inside-tbody>
```

In the above example the `<projecting-tr-inside-tbody>` component culd be "surprised" to see additional
`<tbody>` elements inserted by Angular HTML parser.

PR Close #29219
2019-03-14 03:07:01 -04:00
Paul Gschwendtner 6085f335e8 fix(ivy): platform module bootstrap does not resolve resources (#29083)
Currently with ViewEngine, if someone runs the platform's
`bootstrapModule` method in order to boostrap a module in
JIT mode, external component resources are properly resolved
*automatically*.

Currently with Ivy, the developer would need to manually call
`resolveComponentResources` in order to asynchronously fetch
the determined external component resources. In order to make
this backwards compatible with ViewEngine, and also since
platforms can already specify a `ResourceLoader` compiler
provider, we need to automatically resolve all external
component resources on module bootstrap.

--

Since the `ResourceLoader` is part of the `@angular/compiler`,
because ViewEngine performed the factory creation in the compiler,
we can't access the `ResourceLoader` token from within core.

In order to workaround this without introducing a breaking change,
we just proxy the `ResourceLoader` token to `core` through the
compiler facade. In the future, we should be able to move the
`ResourceLoader` to core when ViewEngine code no longer exists in
the `@angular/compiler`.

PR Close #29083
2019-03-12 11:50:06 -07:00
Alan b012ab210b test: add interm fix for test that rely on an index.d.ts file (#28884)
At the moment, certain tests relies on resolving the module with an index.d.ts, this root cause might be some implementations are missing from the mocks.

Similar to: 58b4045359

PR Close #28884
2019-03-08 12:36:55 -08:00
Pete Bacon Darwin f535f31d78 fix(ivy): match attribute selectors for content projection with inline-templates (#29041)
The content projection mechanism is static, in that it only looks at the static
template nodes before directives are matched and change detection is run.
When you have a selector-based content projection the selection is based
on nodes that are available in the template.

For example:

```
<ng-content selector="[some-attr]"></ng-content>
```

would match

```
<div some-attr="..."></div>
```

If you have an inline-template in your projected nodes. For example:

```
<div *ngIf="..." some-attr="..."></div>
```

This gets pre-parsed and converted to a canonical form.

For example:

```
<ng-template [ngIf]="...">
  <div some-attr=".."></div>
</ng-template>
```

Note that only structural attributes (e.g. `*ngIf`) stay with the `<ng-template>`
node. The other attributes move to the contained element inside the template.

When this happens in ivy, the ng-template content is removed
from the component template function and is compiled into its own
template function. But this means that the information about the
attributes that were on the content are lost and the projection
selection mechanism is unable to match the original
`<div *ngIf="..." some-attr>`.

This commit adds support for this in ivy. Attributes are separated into three
groups (Bindings, Templates and "other"). For inline-templates the Bindings
and "other" types are hoisted back from the contained node to the `template()`
instruction, so that they can be used in content projection matching.

PR Close #29041
2019-03-07 11:27:36 -08:00
Greg Magolan ea09430039 build: rules_nodejs 0.26.0 & use @npm instead of @ngdeps now that downstream angular build uses angular bundles (#28871)
PR Close #28871
2019-02-28 12:06:36 -08:00
Pete Bacon Darwin f7c867ebc2 fix(ivy): correctly tokenize escaped characters in templates (#28978)
Previously the start of a character indicated by an escape sequence
was being incorrectly computed by the lexer, which caused tokens
to include the start of the escaped character sequence in the
preceding token. In particular this affected the name extracted
from opening tags if the name was terminated by an escape sequence.
For example, `<t\n>` would have the name `t\` rather than `t`.

This fix refactors the lexer to use a "cursor" object to iterate over
the characters in the template source. There are two cursor implementations,
one expects a simple string, the other expects a string that contains
JavaScript escape sequences that need to be unescaped.

PR Close #28978
2019-02-28 02:44:19 -08:00
Pete Bacon Darwin 76979e12c9 refactor(compiler): remove not-null operator hack from lexer (#28978)
The parts of a token are supposed to be an array of not-null strings,
but we were using `null` for tags that had no prefix. This has been
fixed to use the empty string in such cases, which allows the `null !`
hack to be removed.

PR Close #28978
2019-02-28 02:44:19 -08:00
Andrew Kushnir 40833ba54b fix(ivy): process property bindings in i18n blocks similar to non-i18n bindings (#28969)
Prior to this change i18n block bindings were converted to Expressions right away (once we first access them), when in non-i18n cases we processed them differently: the actual conversion happens at instructions generation. Because of this discrepancy, the output for bindings in i18n blocks was generated incorrectly (with invalid indicies in pipeBindN fns and invalid references to non-existent local variables). Now the bindings processing is unified and i18nExp instructions should contain right bind expressions.

PR Close #28969
2019-02-27 11:56:12 -08:00
Kristiyan Kostadinov 93a7836f7a fix(ivy): incorrectly remapping certain properties that refer inputs (#28765)
During build time we remap particular property bindings, because their names don't match their attribute equivalents (e.g. the property for the `for` attribute is called `htmlFor`). This breaks down if the particular element has an input that has the same name, because the property gets mapped to something invalid.

The following changes address the issue by mapping the name during runtime, because that's when directives are resolved and we know all of the inputs that are associated with a particular element.

PR Close #28765
2019-02-21 17:59:50 -08:00
Paul Gschwendtner 91b7152852 feat(compiler-cli): no longer re-export external symbols by default (#28633)
With #28594 we refactored the `@angular/compiler` slightly to
allow opting out from external symbol re-exports which are
enabled by default.

Since symbol re-exports only benefit projects which have a
very strict dependency enforcement, external symbols should
not be re-exported by default as this could grow the size of
factory files and cause unexpected behavior with Angular's
AOT symbol resolving (e.g. see: #25644).

Note that the common strict dependency enforcement for source
files does still work with external symbol re-exports disabled,
but there are also strict dependency checks that enforce strict
module dependencies also for _generated files_ (such as the
ngfactory files). This is how Google3 manages it's dependencies
and therefore external symbol re-exports need to be enabled within
Google3.

Also "ngtsc" also does not provide any way of using external symbol
re-exports, so this means that with this change, NGC can partially
match the behavior of "ngtsc" then (unless explicitly opted-out).

As mentioned before, internally at Google symbol re-exports need to
be still enabled, so the `ng_module` Bazel rule will enable the symbol
re-exports by default when running within Blaze.

Fixes #25644.

PR Close #28633
2019-02-13 09:49:51 -08:00
Pete Bacon Darwin cffd86260a fix(compiler): ensure that event handlers have the correct source spans (#28055)
When template bindings are being parsed the event handlers
were receiving a source span that included the whole attribute.

Now they get a span that is focussed on the handler itself.

PR Close #28055
2019-02-12 20:58:28 -08:00
Pete Bacon Darwin c0dac184cd fix(compiler): markup lexer should not capture quotes in attribute value (#28055)
When tokenizing markup (e.g. HTML) element attributes
can have quoted or unquoted values (e.g. `a=b` or `a="b"`).
The `ATTR_VALUE` tokens were capturing the quotes, which
was inconsistent and also affected source-mapping.

Now the tokenizer captures additional `ATTR_QUOTE` tokens,
which the HTML related parsers understand and factor into their
token parsing.

PR Close #28055
2019-02-12 20:58:27 -08:00
Pete Bacon Darwin 2424184d42 feat(compiler): support tokenizing escaped strings (#28055)
In order to support source mapping of templates, we need
to be able to tokenize the template in its original context.
When the template is defined inline as a JavaScript string
in a TS/JS source file, the tokenizer must be able to handle
string escape sequences, such as `\n` and `\"` as they
appear in the original source file.

This commit teaches the lexer how to unescape these
sequences, but only when the `escapedString` option is
set to true.  Otherwise there is no change to the tokenizing
behaviour.

PR Close #28055
2019-02-12 20:58:27 -08:00
Pete Bacon Darwin eeb560ac88 feat(compiler): support tokenizing a sub-section of an input string (#28055)
The lexer that does the tokenizing can now process only a part the source
string, by passing a `range` property in the `options` argument. The
locations of the nodes that are tokenized will now take into account the
position of the span in the context of the original source string.

This `range` option is, in turn, exposed from the template parser as well.

Being able to process parts of files helps to enable SourceMap support
when compiling inline component templates.

PR Close #28055
2019-02-12 20:58:27 -08:00
Pete Bacon Darwin 673ac2945c refactor(compiler): use `options` argument for parsers (#28055)
This commit consolidates the options that can modify the
parsing of text (e.g. HTML, Angular templates, CSS, i18n)
into an AST for further processing into a single `options`
hash.

This makes the code cleaner and more readable, but also
enables us to support further options to parsing without
triggering wide ranging changes to code that should not
be affected by these new options.  Specifically, it will let
us pass information about the placement of a template
that is being parsed in its containing file, which is essential
for accurate SourceMap processing.

PR Close #28055
2019-02-12 20:58:27 -08:00
Paul Gschwendtner 872a3656fe refactor(compiler): allow disabling external symbol factory reexports (#28594)
Currently external static symbols which are referenced by AOT
compiler generated code, will be re-exported in the corresponding
`.ngfactory` files.

This way of handling the symbol resolution has been introduced in
favor of avoding dynamically generated module dependencies. This
behavior therefore avoids any strict dependency failures.

Read more about a particular scenario here: https://github.com/angular/angular/issues/25644#issuecomment-458354439

Now with `ngtsc`, this behavior has changed since `ngtsc` just
introduces these module dependencies in order to properly reference
the external symbol from its original location (also eliminating the need
for factories). Similarly we should provide a way to use the same
behavior with `ngc` because the downside of using the re-exported symbol
resolution is that user-code transformations (e.g. the `ngInjectableDef`
metadata which is added to the user source code), can resolve external
symbols to previous factory symbol re-exports. This is a critical issue
because it means that the actual JIT code references factory files in order
to access external symbols. This means that the generated output cannot
shipped to NPM without shipping the referenced factory files.

A specific example has been reported here: https://github.com/angular/angular/issues/25644#issue-353554070

PR Close #28594
2019-02-11 17:12:50 +00:00
Miško Hevery 978ffa9d32 refactor(ivy): refactor more files in DI to prepare it for bazel packages (#28098)
PR Close #28098
2019-01-14 09:55:30 -08:00
Matias Niemelä 13eb57a59f fix(ivy): merge static style rendering across elements, directives and components (#27661)
PR Close #27661
2018-12-21 18:14:44 -05:00
Matias Niemelä 3ab25ab078 refactor: fix broken linting rules due to revert 2018-12-19 13:06:43 -08:00
Alex Eagle e8f7241366 build: fix our copy of Array#find typing (#27742)
It should be nullable, matching the lib.es2015.d.ts from TypeScript

PR Close #27742
2018-12-19 15:11:52 -05:00
Alex Eagle 50687e11cf build: fix type-check errors introduced during rules_ts 0.21 (#27586)
PR Close #27586
2018-12-10 16:33:41 -08:00
Andrew Kushnir f0b0d64453 fix(ivy): adding `projectDef` instructions to all templates where <ng-content> is present (FW-745) (#27384)
Prior to this change `projectDef` instructions were placed to root templates only, thus the necessary information (selectors) in nested templates was missing. This update adds the logic to insert `projectDef` instructions to all templates where <ng-content> is present.

PR Close #27384
2018-12-04 19:58:13 -08:00
Andrew Kushnir aedc343003 feat(ivy): updated translation const names (that include message ids) (#27185)
PR Close #27185
2018-11-30 10:00:54 -08:00
Alex Rickabaugh 4effb89ae8 test(ivy): update //packages/compiler tests for Ivy (#27301)
Most of the specs in these tests are not relevant to Ivy:

//packages/compiler/test:test
//packages/compiler/test:test_web_chromium-local

However, a few test pieces of the compiler infrastructure that are used in
Ivy, and new BUILD.bazel files are created to separate them from the above
disabled targets:

//packages/compiler/test/css_parser:css_parser
//packages/compiler/test/css_parser:css_parser_web
//packages/compiler/test/expression_parser:expression_parser
//packages/compiler/test/expression_parser:expression_parser_web
//packages/compiler/test/ml_parser:ml_parser
//packages/compiler/test/ml_parser:ml_parser_web
//packages/compiler/test/selector:selector
//packages/compiler/test/selector:selector_web

PR Close #27301
2018-11-29 21:31:35 -08:00
Andrew Kushnir 92e80af875 feat(ivy): ICU support for Ivy (#26794)
PR Close #26794
2018-11-16 16:09:30 -08:00
Matias Niemelä 095b6e8113 refactor(ivy): abstract all styling-related compiler logic into a shared class (#27043)
PR Close #27043
2018-11-12 15:32:48 -08:00
Misko Hevery 7d2a746090 build: remove ivy JIT mode (#26863)
PR Close #26863
2018-11-02 15:44:05 -07:00
Misko Hevery d042c4afe0 fix(core): Remove static dependency from @angular/core to @angular/compiler (#26734)
PR Close #26734
2018-10-31 14:15:06 -04:00
Igor Minar ee0b857172 build: rename the ivy compile mode 'local' to 'aot' (#26686)
PR Close #26686
2018-10-23 14:14:49 -07:00
Igor Minar 4237c34c78 test(ivy): mark failing test targets with fixme-ivy-jit and fixme-ivy-local tags (#26471)
We are close enough to blacklist a few test targets, rather than whitelist targets to run...

Because bazel rules can be composed of other rules that don't inherit tags automatically,
I had to explicitly mark all of our ts_library and ng_module targes with "ivy-local" and
"ivy-jit" tags so that we can create a query that excludes all fixme- tagged targets even
if those targets are composed of other targets that don't inherit this tag.

This is the updated overview of ivy related bazel tags:

- ivy-only: target that builds or runs only under ivy
- fixme-ivy-jit: target that doesn't yet build or run under ivy with --compile=jit
- fixme-ivy-local: target that doesn't yet build or run under ivy with --compile=local
- no-ivy-jit: target that is not intended to build or run under ivy with --compile=jit
- no-ivy-local: target that is not intended to build or run under ivy with --compile=local

PR Close #26471
2018-10-23 08:57:42 -07:00
Greg Magolan 1f3331f5e6 build(bazel): use fine-grained npm deps (#26111) (#26488)
PR Close #26488
2018-10-19 20:59:29 -07:00
Andrew Kushnir 8a3fd58cad feat(ivy): i18n compiler support for i18nStart and i18nEnd instructions (#26442)
PR Close #26442
2018-10-17 11:03:52 -07:00
Alex Rickabaugh 9ed4e3df60 feat(ivy): introduce a new compiler API for operating on templates (#26203)
This commit introduces the "t2" API, which processes parsed template ASTs
and performs a number of functions such as binding (the process of
semantically interpreting cross-references within the template) and
directive matching. The API is modeled on TypeScript's TypeChecker API,
with oracle methods that give access to collected metadata.

This work is a prerequisite for the upcoming template type-checking
functionality, and will also become the basis for a refactored
TemplateDefinitionBuilder.

PR Close #26203
2018-10-04 10:11:17 -07:00
Greg Magolan b99d7ed5bf build(bazel): update to rules_typescript 0.17.0 & rules_nodejs 0.13.4 (#25920)
PR Close #25920
2018-09-18 13:05:38 -07:00
Alan Agius 5653fada32 feat: add TypeScript 3 support (#25275)
PR Close #25275
2018-08-27 21:07:53 -04:00
Misko Hevery 503905c807 feat(ivy): add `ngcc` ivy switch (#25238)
Provides a runtime and compile time switch for ivy including
`ApplicationRef.bootstrapModule`.

This is done by naming the symbols such that `ngcc` (angular
Compatibility compiler) can rename symbols in such a way that running
`ngcc` command will switch the `@angular/core` module from `legacy` to
`ivy` mode.

This is done as follows:

```
const someToken__PRE_NGCC__ = ‘legacy mode’;
const someToken__POST_NGCC__ = ‘ivy mode’;

export someSymbol = someToken__PRE_NGCC__;
```

The `ngcc` will search for any token which ends with `__PRE_NGCC__`
and replace it with `__POST_NGCC__`. This allows the `@angular/core`
package to be rewritten to ivy mode post `ngcc` execution.

PR Close #25238
2018-08-16 13:51:42 -07:00
Greg Magolan 9605456b66 build: refactor ambient node & jasmine types so they are only included where needed (#25491)
PR Close #25491
2018-08-16 13:46:43 -07:00