Commit Graph

443 Commits

Author SHA1 Message Date
Pete Bacon Darwin a770aa231d refactor(ivy): move ngcc into a higher level folder (#29092)
PR Close #29092
2019-03-20 14:45:54 -04:00
Greg Magolan 7c4afb0da7 build: enable shard_count for some jasmine tests that have many specs (#29375)
PR Close #29375
2019-03-19 23:39:36 -04:00
Matias Niemelä 8714daf276 fix(ivy): introduce host-specific styling instructions (#29292)
This patch is the first of a few patches which separates the
styling logic between template bindings (e.g. <div [style])
from host bindings (e.g. @HostBinding('style')). This patch
in particular introduces a series of host-specific styling
instructions and changes the existing set of template styling
instructions not to accept directives. The underyling code (which
communicates with the styling algorithm) still works as it did
before.

This PR also separates the styling instruction code into a separate
file and moves over all other instructions into an dedicated
instructions directory.

PR Close #29292
2019-03-19 16:33:39 -04:00
Alex Eagle 86aba1e8f3 build: add moduleName to ngFactory sourcefiles (#29385)
PR Close #29385
2019-03-19 01:10:49 -04:00
Alex Rickabaugh ae4a86e3b5 fix(ivy): don't track identifiers of ffr-resolved references (#29387)
This fix is for a bug in the ngtsc PartialEvaluator, which statically
evaluates expressions.

Sometimes, evaluating a reference requires resolving a function which is
declared in another module, and thus no function body is available. To
support this case, the PartialEvaluator has the concept of a foreign
function resolver.

This allows the interpretation of expressions like:

const router = RouterModule.forRoot([]);

even though the definition of the 'forRoot' function has no body. In
ngtsc today, this will be resolved to a Reference to RouterModule itself,
via the ModuleWithProviders foreign function resolver.

However, the PartialEvaluator also associates any Identifiers in the path
of this resolution with the Reference. This is done so that if the user
writes

const x = imported.y;

'x' can be generated as a local identifier instead of adding an import for
'y'.

This was at the heart of a bug. In the above case with 'router', the
PartialEvaluator added the identifier 'router' to the Reference generated
(through FFR) to RouterModule.

This is not correct. References that result from FFR expressions may not
have the same value at runtime as they do at compile time (indeed, this is
not the case for ModuleWithProviders). The Reference generated via FFR is
"synthetic" in the sense that it's constructed based on a useful
interpretation of the code, not an accurate representation of the runtime
value. Therefore, it may not be legal to refer to the Reference via the
'router' identifier.

This commit adds the ability to mark such a Reference as 'synthetic', which
allows the PartialEvaluator to not add the 'router' identifier down the
line. Tests are included for both the PartialEvaluator itself as well as the
resultant buggy behavior in ngtsc overall.

PR Close #29387
2019-03-19 01:10:17 -04:00
Paul Gschwendtner 105cfaf5e4 fix(compiler-cli): incorrect metadata bundle for multiple unnamed re-exports (#29360)
Currently if an Angular library has multiple unnamed module re-exports, NGC will
generate incorrect metdata if the project is using the flat-module bundle option.

e.g.

_public-api.ts_
```ts
export * from '@mypkg/secondary1';
export * from '@mypkg/secondary2';
```

There are clearly two unnamed re-exports in the `public-api.ts` file. NGC right now
accidentally overwrites all previous re-exports with the last one. Resulting in the
generated metadata only containing a reference to `@mypkg/secondary2`.

This is problematic as it is common for primary library entry-points to have
multiple re-exports (e.g. Material re-exporting all public symbols; or flex-layout
exporting all public symbols from their secondary entry-points).

Currently Angular Material works around this issue by manually creating
a metadata file that declares the re-exports from all unnamed re-exports.

(see: https://github.com/angular/material2/blob/master/tools/package-tools/build-release.ts#L78-L85)

This workaround works fine currently, but is no longer easily integrated when
building the package output with Bazel. In order to be able to build such
libraries with Bazel (Material/flex-layout), we need to make sure that NGC
generates the proper flat-module metadata bundle.

PR Close #29360
2019-03-18 15:08:40 -04:00
Alex Eagle 4d912b6b12 Revert "build: enable shard_count for some jasmine tests that have many specs (#29196)" (#29347)
This reverts commit a5c747f46d.

PR Close #29347
2019-03-15 19:47:00 -04:00
Alex Eagle a5c747f46d build: enable shard_count for some jasmine tests that have many specs (#29196)
This partitions the spects across multiple processes so they run in parallel.

PR Close #29196
2019-03-14 13:14:03 -04:00
Kristiyan Kostadinov 0ffa2f2e73 fix(ivy): unable to inherit view queries into component from directive (#29203)
Fixes components not being able to inherit their view queries from a directive.

This PR resolves FW-1146.

PR Close #29203
2019-03-13 17:12:14 -04:00
Igor Minar 75748d6044 feat: add support for TypeScript 3.3 (and drop older versions) (#29004)
https://blogs.msdn.microsoft.com/typescript/2019/01/31/announcing-typescript-3-3/

BREAKING CHANGE: TypeScript 3.1 and 3.2 are no longer supported.

Please update your TypeScript version to 3.3

PR Close #29004
2019-03-13 10:38:37 -07:00
Alex Rickabaugh 73da2792c9 fix(ivy): properly compile NgModules with forward referenced types (#29198)
Previously, ngtsc would resolve forward references while evaluating the
bootstrap, declaration, imports, and exports fields of NgModule types.
However, when generating the resulting ngModuleDef, the forward nature of
these references was not taken into consideration, and so the generated JS
code would incorrectly reference types not yet declared.

This commit fixes this issue by introducing function closures in the
NgModuleDef type, similarly to how NgComponentDef uses them for forward
declarations of its directives and pipes arrays. ngtsc will then generate
closures when required, and the runtime will unwrap them if present.

PR Close #29198
2019-03-12 18:26:42 -07:00
Alex Rickabaugh ccb70e1c64 fix(ivy): reuse default imports in type-to-value references (#29266)
This fixes an issue with commit b6f6b117. In this commit, default imports
processed in a type-to-value conversion were recorded as non-local imports
with a '*' name, and the ImportManager generated a new default import for
them. When transpiled to ES2015 modules, this resulted in the following
correct code:

import i3 from './module';

// somewhere in the file, a value reference of i3:
{type: i3}

However, when the AST with this synthetic import and reference was
transpiled to non-ES2015 modules (for example, to commonjs) an issue
appeared:

var module_1 = require('./module');
{type: i3}

TypeScript renames the imported identifier from i3 to module_1, but doesn't
substitute later references to i3. This is because the import and reference
are both synthetic, and never went through the TypeScript AST step of
"binding" which associates the reference to its import. This association is
important during emit when the identifiers might change.

Synthetic (transformer-added) imports will never be bound properly. The only
possible solution is to reuse the user's original import and the identifier
from it, which will be properly downleveled. The issue with this approach
(which prompted the fix in b6f6b117) is that if the import is only used in a
type position, TypeScript will mark it for deletion in the generated JS,
even though additional non-type usages are added in the transformer. This
again would leave a dangling import.

To work around this, it's necessary for the compiler to keep track of
identifiers that it emits which came from default imports, and tell TS not
to remove those imports during transpilation. A `DefaultImportTracker` class
is implemented to perform this tracking. It implements a
`DefaultImportRecorder` interface, which is used to record two significant
pieces of information:

* when a WrappedNodeExpr is generated which refers to a default imported
  value, the ts.Identifier is associated to the ts.ImportDeclaration via
  the recorder.
* when that WrappedNodeExpr is later emitted as part of the statement /
  expression translators, the fact that the ts.Identifier was used is
  also recorded.

Combined, this tracking gives the `DefaultImportTracker` enough information
to implement another TS transformer, which can recognize default imports
which were used in the output of the Ivy transform and can prevent them
from being elided. This is done by creating a new ts.ImportDeclaration for
the imports with the same ts.ImportClause. A test verifies that this works.

PR Close #29266
2019-03-12 18:02:08 -07:00
Andrew Kushnir fe76494759 fix(ivy): use default selector for Components if selector is empty (#29239)
Prior to this change default selector for Components was not applied in case selector is missing or defined as an empty string. This update aligns this behavior between Ivy and VE: now default selector is used for Components when it's needed. Directives with empty selector are not allowed and trigger a compile-time error in both Ivy and VE.

PR Close #29239
2019-03-12 14:09:46 -07:00
Andrew Kushnir 1d88c2bb81 fix(ivy): handle aliased Angular decorators (#29195)
Prior to this change the code didn't take into account the fact that decorators can be aliases while importing into a script. As a result, these decorators were not recognized by Angular and various failures happened because of that. Now we take aliases into account and resolve decorator name properly.

PR Close #29195
2019-03-11 11:20:41 -07:00
Alex Rickabaugh 49dccf4bfc fix(ivy): process separate declarations and exports for summaries (#29193)
ngsummary files were generated with an export for each class declaration.
However, some Angular code declares classes (class Foo) and exports them
(export {Foo}) separately, which was causing incomplete summary files.

This commit expands the set of symbol names for which summary exports will
be generated, fixing this issue.

PR Close #29193
2019-03-08 16:11:32 -08:00
Alex Rickabaugh 3a6ba00286 fix(ivy): escape all required characters in reexport aliases (#29194)
Previously, the compiler did not escape . or $, and this was causing issues
in google3. Now these characters are escaped.

PR Close #29194
2019-03-08 16:10:57 -08:00
Alex Rickabaugh c37ec8b255 fix(ivy): produce ts.Diagnostics for NgModule scope errors (#29191)
Previously, when the NgModule scope resolver discovered semantic errors
within a users NgModules, it would throw assertion errors. TODOs in the
codebase indicated these should become ts.Diagnostics eventually.

Besides producing better-looking errors, there is another reason to make
this change asap: these assertions were shadowing actual errors, via an
interesting mechanism:

1) a component would produce a ts.Diagnostic during its analyze() step
2) as a result, it wouldn't register component metadata with the scope
   resolver
3) the NgModule for the component references it in exports, which was
   detected as an invalid export (no metadata registering it as a
   component).
4) the resulting assertion error would crash the compiler, hiding the
   real cause of the problem (an invalid component).

This commit should mitigate this problem by converting scoping errors to
proper ts.Diagnostics. Additionally, we should consider registering some
marker indicating a class is a directive/component/pipe without actually
requiring full metadata to be produced for it, which would allow suppression
of errors like "invalid export" for such invalid types.

PR Close #29191
2019-03-08 14:21:48 -08: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
Alex Rickabaugh b6f6b1178f fix(ivy): generate type references to a default import (#29146)
This commit refactors and expands ngtsc's support for generating imports of
values from imports of types (this is used for example when importing a
class referenced in a type annotation in a constructor).

Previously, this logic handled "import {Foo} from" and "import * as foo
from" style imports, but failed on imports of default values ("import
Foo from"). This commit moves the type-to-value logic to a separate file and
expands it to cover the default import case. Doing this also required
augmenting the ImportManager to track default as well as non-default import
generation. The APIs were made a little cleaner at the same time.

PR Close #29146
2019-03-08 11:57:08 -08:00
Andrew Kushnir fd5cd100a3 fix(ivy): move i18n instructions after listener ones (#29173)
Prior to this commit, i18n instructions (i18n, i18nStart) were generated before listener instructions. As a result, event listeners were attached to the wrong element (text node, not the parent element). This change updates the order of instructions and puts i18n ones after listeners, to make sure listeners are attached to the right elements.

PR Close #29173
2019-03-07 15:36:39 -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
Pete Bacon Darwin 423ac01dcf refactor: rename `AttributeMarker.ProjectOnly` to `AttributeMarker.Bindings` (#29041)
PR Close #29041
2019-03-07 11:27:35 -08:00
Andrew Kushnir dc6192c8e5 fix(ivy): properly detect "inputs" and "outputs" field names that should be wrapped in quotes (#29126)
Prior to this change, the RegExp that was used to check for dashes in field names used "g" (global) flag that retains lastIndex, which might result in skipping some fields that should be wrapped in quotes (since lastIndex advanced beyond the next "-" location). This commit removes this flag and updates the test to make sure there are no regressions.

PR Close #29126
2019-03-06 11:01:53 -08:00
Alex Rickabaugh 881807dc36 fix(ivy): never use imported type references as values (#29111)
ngtsc occasionally converts a type reference (such as the type of a
parameter in a constructor) to a value reference (argument to a
directiveInject call). TypeScript has a bad habit of sometimes removing
the import statement associated with this type reference, because it's a
type only import when it initially looks at the file.

A solution to this is to always add an import to refer to a type position
value that's imported, and not rely on the existing import.

PR Close #29111
2019-03-05 16:47:41 -08:00
Marc Laval 25166d4f41 fix(ivy): support property values changed in ngOnChanges (forward rref case) (#29054)
PR Close #29054
2019-03-05 14:27:08 -08:00
Alex Rickabaugh 866d500324 fix(ivy): copy top-level comments into generated factory shims (#29065)
When ngtsc generates a .ngfactory shim, it does so based on the contents of
an original file in the program. Occasionally these original files have
comments at the top which are load-bearing (e.g. they contain jsdoc
annotations which are significant to downstream bundling tools). The
generated factory shims should preserve this comment.

This commit adds a step to the ngfactory generator to preserve the top-level
comment from the original source file.

FW-1006 #resolve
FW-1095 #resolve

PR Close #29065
2019-03-04 15:59:07 -08:00
Andrew Kushnir aa57bdbf90 fix(ivy): wrap "inputs" and "outputs" keys if they contain unsafe characters (#28919)
Prior to this change, keys in "inputs" and "outputs" objects generated by compiler were not checked against unsafe characters. As a result, in some cases the generated code was throwing JS error. Now we check whether a given key contains any unsafe chars and wrap it in quotes if needed.

PR Close #28919
2019-03-04 14:40:42 -08:00
Alex Rickabaugh b1df9a30f4 fix(ivy): use the imported name of decorators for detection (#29061)
Currently, ngtsc has a bug where if you alias the name of a decorator when
importing it, it won't be detected properly. This is because the compiler
uses the aliased name and not the original, declared name of the decorator
for detection.

This commit fixes the compiler to compare against the declared name of
decorators when available, and adds a test to prevent regression.

PR Close #29061
2019-03-01 15:19:34 -08:00
Alex Rickabaugh 3e5c1bcb9f fix(ivy): track cyclic imports that are added (#29040)
ngtsc has cyclic import detection, to determine when adding an import to a
directive or pipe would create a cycle. However, this detection must also
account for already inserted imports, as it's possible for both directions
of a circular import to be inserted by Ivy (as opposed to at least one of
those edges existing in the user's program).

This commit fixes the circular import detection for components to take into
consideration already added edges. This is difficult for one critical
reason: only edges to files which will *actually* be imported should be
considered. However, that depends on which directives & pipes are used in
a given template, which is currently only known by running the
TemplateDefinitionBuilder during the 'compile' phase. This is too late; the
decision whether to use remote scoping (which consults the import graph) is
made during the 'resolve' phase, before any compilation has taken place.

Thus, the only way to correctly consider synthetic edges is for the compiler
to know exactly which directives & pipes are used in a template during
'resolve'. There are two ways to achieve this:

1) refactor `TemplateDefinitionBuilder` to do its work in two phases, with
directive matching occurring as a separate step which can be performed
earlier.

2) use the `R3TargetBinder` in the 'resolve' phase to independently bind the
template and get information about used directives.

Option 1 is ideal, but option 2 is currently used for practical reasons. The
cost of binding the template can be shared with template-typechecking.

PR Close #29040
2019-03-01 15:18:50 -08:00
Alex Rickabaugh b50283ed67 fix(ivy): support dynamic host attribute bindings (#29033)
In the @Component decorator, the 'host' field is an object which represents
host bindings. The type of this field is complex, but is generally of the
form {[key: string]: string}. Several different kinds of bindings can be
specified, depending on the structure of the key.

For example:

```
@Component({
  host: {'[prop]': 'someExpr'}
})
```

will bind an expression 'someExpr' to the property 'prop'. This is known to
be a property binding because of the square brackets in the binding key.

If the binding key is a plain string (no brackets or parentheses), then it
is known as an attribute binding. In this case, the right-hand side is not
interpreted as an expression, but is instead a constant string.

There is no actual requirement that at build time, these constant strings
are known to the compiler, but this was previously enforced as a side effect
of requiring the binding expressions for property and event bindings to be
statically known (as they need to be parsed). This commit breaks that
relationship and allows the attribute bindings to be dynamic. In the case
that they are dynamic, the references to the dynamic values are reflected
into the Ivy instructions for attribute bindings.

PR Close #29033
2019-03-01 15:18:13 -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
Andrew Kushnir 772b24ccc3 fix(ivy): avoid missing imports for types that can be represented as values (#28941)
Prior to this change, TypeScript stripped out some imports in case we reference a type that can be represented as a value (for ex. classes). This fix ensures that we use correct symbol identifier, which makes TypeScript retain the necessary import statements.

PR Close #28941
2019-02-27 15:13:40 -08:00
Alex Rickabaugh 827e89cfc4 feat(ivy): support inline <style> and <link> tags in components (#28997)
Angular supports using <style> and <link> tags inline in component
templates, but previously such tags were not implemented within the ngtsc
compiler. This commit introduces that support.

FW-1069 #resolve

PR Close #28997
2019-02-27 11:56:40 -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
Andrew Kushnir 034de06ab1 fix(ivy): avoid duplicate i18n consts to be present in generated output (#28967)
Prior to this change, the logic that outputs i18n consts (like `const MSG_XXX = goog.getMsg(...)`) didn't have a check whether a given const that represent a certain i18n message was already included into the generated output. This commit adds the logic to mark corresponding i18n contexts after translation was generated, to avoid duplicate consts in the output.

PR Close #28967
2019-02-27 10:33:41 -08:00
Wassim Chegham dad5a258b8 style: enforce buildifier lint on CI (#28186)
PR Close #28186
2019-02-26 16:57:41 -08:00
Wassim Chegham ce68b4d839 style: enforce buildifier lint on CI (#28186)
PR Close #28186
2019-02-26 16:57:41 -08:00
Marc Laval 8f8f9a6e61 fix(ivy): ngtsc should correctly bind to context in nested template with many bindings (#28982)
PR Close #28982
2019-02-26 11:54:13 -08:00
Alex Rickabaugh c1392ce618 feat(ivy): produce and consume ES2015 re-exports for NgModule re-exports (#28852)
In certain configurations (such as the g3 repository) which have lots of
small compilation units as well as strict dependency checking on generated
code, ngtsc's default strategy of directly importing directives/pipes into
components will not work. To handle these cases, an additional mode is
introduced, and is enabled when using the FileToModuleHost provided by such
compilation environments.

In this mode, when ngtsc encounters an NgModule which re-exports another
from a different file, it will re-export all the directives it contains at
the ES2015 level. The exports will have a predictable name based on the
FileToModuleHost. For example, if the host says that a directive Foo is
from the 'root/external/foo' module, ngtsc will add:

```
export {Foo as ɵng$root$external$foo$$Foo} from 'root/external/foo';
```

Consumers of the re-exported directive will then import it via this path
instead of directly from root/external/foo, preserving strict dependency
semantics.

PR Close #28852
2019-02-22 12:15:58 -08:00
Alex Rickabaugh 15c065f9a0 refactor(ivy): extract selector scope logic to a new ngtsc package (#28852)
This commit splits apart selector_scope.ts in ngtsc and extracts the logic
into two separate classes, the LocalModuleScopeRegistry and the
DtsModuleScopeResolver. The logic is cleaned up significantly and new tests
are added to verify behavior.

LocalModuleScopeRegistry implements the NgModule semantics for compilation
scopes, and handles NgModules declared in the current compilation unit.
DtsModuleScopeResolver implements simpler logic for export scopes and
handles NgModules declared in .d.ts files.

This is done in preparation for the addition of re-export logic to solve
StrictDeps issues.

PR Close #28852
2019-02-22 12:15:58 -08:00
Kristiyan Kostadinov 32ae84da28 fixup! fix(ivy): incorrectly remapping certain properties that refer to inputs (#28765)
PR Close #28765
2019-02-21 17:59:50 -08:00
Andrew Kushnir 95d9aa22ef fix(ivy): allow HTML comments to be present inside <ng-content> (#28849)
Prior to this change presence of HTML comments inside <ng-content> caused compiler to throw an error that <ng-content> is not empty. Now HTML comments are not considered as a meaningful content, thus no error is thrown. This behavior is now aligned in Ivy/VE.

PR Close #28849
2019-02-21 00:13:40 -08:00
Andrew Kushnir df627e65df fix(ivy): correct absolute path processing for templateUrl and styleUrls (#28789)
Prior to this change absolute file paths (like `/a/b/c/style.css`) were calculated taking current component file location into account. As a result, absolute file paths were calculated using current file as a root. This change updates this logic to ignore current file path in case of absolute paths.

PR Close #28789
2019-02-21 00:13:12 -08:00
Andrew Kushnir 72d043f669 fix(ivy): check the presence of .css resource for styleUrls (#28770)
Prior to this change, Ivy and VE CSS resource resolution was different: in addition to specified styleUrl (with .scss, .less and .styl extensions), VE also makes an attempt to resolve resource with .css extension. This change introduces similar logic for Ivy to make sure Ivy behavior is backwards compatible.

PR Close #28770
2019-02-21 00:12:43 -08:00
Andrew Kushnir be121bba85 fix(ivy): restore @fileoverview annotations for Closure (#28723)
Prior to this change, the @fileoverview annotations added by users in source files or by tsickle during compilation might have change a location due to the fact that Ngtsc may prepend extra imports or constants. As a result, the output file is considered invalid by Closure (misplaced @fileoverview annotation). In order to resolve the problem we relocate @fileoverview annotation if we detect that its host node shifted.

PR Close #28723
2019-02-21 00:12:14 -08:00
Paul Gschwendtner 58436fd81a fix(ivy): unable to import shim factory files on case-insensitive platforms (#28831)
This change is kind of similar to #27466, but instead of ensuring that
these shims can be generated, we also need to make sure that developers
are able to also use the factory shims like with `ngc`.

This issue is now surfacing because we have various old examples which
are now also built with `ngtsc`  (due to the bazel migration). On case insensitive
platforms (e.g. windows) these examples cannot be built because ngtsc fails
the app imports a generated shim file (such as the factory shim files).

This is because the `GeneratedShimsHostWrapper` TypeScript host uses
the `getCanonicalFileName` method in order to check whether a given
file/module exists in the generator file maps. e.g.

```
// Generator Map:
'C:/users/paul/_bazel_paul/lm3s4mgv/execroot/angular/packages/core/index.ngfactory.ts' =>
'C:/users/paul/_bazel_paul/lm3s4mgv/execroot/angular/packages/core/index.ts',

// Path passed into `fileExists`
C:/users/paul/_bazel_paul/lm3s4mgv/execroot/angular/packages/core/index.ngfactory.ts

// After getCanonicalFileName (notice the **lower-case drive name**)
c:/users/paul/_bazel_paul/lm3s4mgv/execroot/angular/packages/core/index.ngfactory.ts
```

As seen above, the generator map does not use the canonical file names, as well as
TypeScript internally does not pass around canonical file names. We can fix this by removing
the manual call to `getCanonicalFileName` and just following TypeScript internal-semantics.

PR Close #28831
2019-02-20 18:26:05 -08:00
Paul Gschwendtner 3336de0970 refactor(ivy): fix typo in ngtsc "listLazyRoutes" method (#28831)
Fixes a minor typo in the `listLazyRoutes` method for `ngtsc`. Also in
addition fixes that a newly introduced test for `listLazyRoutes` broke the
tests in Windows. It's clear that we still don't run tests against
Windows, but we also made all other tests pass (without CI verification),
and it's not a big deal fixing this while being at it.

PR Close #28831
2019-02-20 18:26:05 -08:00
Matias Niemelä d0e81eb593 feat(ivy): open up ivy_switch_mode to non-core packages (#28711)
Prior to this fix, using the compiler's ivy_switch mechanism was
only available to core packages. This patch allows for this variable
switching mechanism to work across all other angular packages.

PR Close #28711
2019-02-20 13:46:14 -08:00
Greg Magolan 25aae64274 build(bazel): do not build rxjs from source under Bazel (#28720)
PR Close #28720
2019-02-19 16:28:14 -08:00
Kara Erickson 3c1a1620e3 fix(ivy): support static ContentChild queries (#28811)
This commit adds support for the `static: true` flag in `ContentChild`
queries. Prior to this commit, all `ContentChild` queries were resolved
after change detection ran. This is a problem for backwards
compatibility because View Engine also supported "static" queries which
would resolve before change detection.

Now if users add a `static: true` option, the query will be resolved in
creation mode (before change detection runs). For example:

```ts
@ContentChild(TemplateRef, {static: true}) template !: TemplateRef;
```

This feature will come in handy for components that need
to create components dynamically.

PR Close #28811
2019-02-19 15:29:01 -08:00