Commit Graph

873 Commits

Author SHA1 Message Date
Greg Magolan 861d6f1523 build(bazel): back out of @bazel/jasmine 0.27.7 with shard count (#29444)
PR Close #29444
2019-03-21 09:59:13 -07:00
Alex Rickabaugh dc10355d61 build(compiler-cli): enable full TypeScript strictness (#29436)
This commit enables strict: true in TypeScript builds of
//packages/compiler-cli.

PR Close #29436
2019-03-21 12:14:39 -04:00
JoostK 9eb8274991 fix(ivy): emit generic type arguments in Pipe metadata (#29403)
Previously, only directives and services with generic type parameters
would emit `any` as generic type when emitting Ivy metadata into .d.ts
files. Pipes can also have generic type parameters but did not emit
`any` for all type parameters, resulting in the omission of those
parameters which causes compilation errors.

This commit adds support for pipes with generic type arguments and emits
`any` as generic type in the Ivy metadata.

Fixes #29400

PR Close #29403
2019-03-20 16:11:22 -04:00
Alan Agius 68a9fe817c test: remove symlink workaround (#29426)
This is no longer required. And is causing some errors to some of our engineers

PR Close #29426
2019-03-20 15:13:09 -04:00
Pete Bacon Darwin 64e5628897 feat(ivy): ngcc - support creating a new copy of the entry-point format (#29092)
This commit adds a `NewEntryPointFileWriter` that will be used in
webpack integration. Instead of overwriting files in-place, this `FileWriter`
will make a copy of the TS program files and write the transformed files
there. It also updates the package.json with new properties that can be
used to access the new entry-point format.

FW-1121

PR Close #29092
2019-03-20 14:45:55 -04:00
Pete Bacon Darwin 849b327986 refactor(ivy): ngcc - extract file writing out into a class (#29092)
This is in preparation of having different file writing strategies.

PR Close #29092
2019-03-20 14:45:55 -04:00
Pete Bacon Darwin a827bc2e3a refactor(ivy): ngcc - mark target entry-point as processed even if ngcc was a noop (#29092)
If `targetEntryPointPath` is provided to `mainNgcc` then we will now mark all
the `propertiesToConsider` for that entry-point if we determine that
it does not contain code that was compiled by Angular (for instance it has
no `...metadata.json` file).

The commit also renames `__modified_by_ngcc__` to `__processed_by_ivy_ngcc__`, since
there may be entry-points that are marked despite ngcc not actually compiling anything.

PR Close #29092
2019-03-20 14:45:55 -04:00
Pete Bacon Darwin 083fb99033 fix(ivy): ngcc - fail build-marker check if any formats were compiled with different ngcc (#29092)
Now we check the build-marker version for all the formats
rather than just the one we are going to compile.

This way we don't get into the situation where one format was
built with one version of ngcc and another format was built with
another version.

PR Close #29092
2019-03-20 14:45:55 -04:00
Pete Bacon Darwin 55ea8da6eb refactor(ivy): ngcc - clean up the public API and export `hasBeenProcessed` helper (#29092)
Now the public API does not contain internal types, such as `AbsoluteFsPath` and
`EntryPointJsonProperty`. Instead we just accept strings and then guard them in
`mainNgcc` as appropriate.

A new public API function (`hasBeenProcessed`) has been exported to allow programmatic
checking of the build marker when the package.json contents are already known.

PR Close #29092
2019-03-20 14:45:55 -04:00
Pete Bacon Darwin 7ea0d1bd3a refactor(ivy): ngcc - use a fixed set of properties to compile if none provided (#29092)
Previously we always considered all the properties in the package.json
if no `propertiesToConsidere` were provided.
But this results in computing a new set of properties for each entry-point
plus iterating through many of the package.json properties that are
not related to bundle-format paths.

PR Close #29092
2019-03-20 14:45:55 -04:00
Pete Bacon Darwin bdcbd9ed4b fix(ivy): ngcc - teach Esm5ReflectionHost about aliased variables (#29092)
Sometimes, in ESM5 code, aliases to exported variables are used internally
to refer to the exported value. This prevented some analysis from being
able to match up a reference to an export to the actual export itself.

For example in the following code:

```
var HttpClientXsrfModule = /** @class */ (function () {
  function HttpClientXsrfModule() {
  }
  HttpClientXsrfModule_1 = HttpClientXsrfModule;
  HttpClientXsrfModule.withOptions = function (options) {
      if (options === void 0) { options = {}; }
      return {
          ngModule: HttpClientXsrfModule_1,
          providers: [],
      };
  };
  var HttpClientXsrfModule_1;
  HttpClientXsrfModule = HttpClientXsrfModule_1 = tslib_1.__decorate([
      NgModule({
          providers: [],
      })
  ], HttpClientXsrfModule);
  return HttpClientXsrfModule;
}());
```

We were not able to tell that the `ngModule: HttpClientXsrfModule_1` property
assignment was actually meant to refer to the `function HttpClientXrsfModule()`
declaration.  This caused the `ModuleWithProviders` processing to fail.

This commit ensures that we can compile typings files using the ESM5
format, so we can now update the examples boilerplate tool so that it
does not need to compile the ESM2015 format at all.

PR Close #29092
2019-03-20 14:45:55 -04:00
Pete Bacon Darwin b48d6e1b13 fix(ivy): ngcc - empower `Esm5ReflectionHost` to analyze `ModuleWithProviders` functions (#29092)
In ESM5 code, static methods appear as property assignments onto the constructor
function. For example:

```
var MyClass = (function() {
  function MyClass () {}
  MyClass.staticMethod = function() {};
  return MyClass;
})();
```

This commit teaches ngcc how to process these forms when searching
for `ModuleWithProviders` functions that need to be updated in the typings
files.

PR Close #29092
2019-03-20 14:45:55 -04:00
Pete Bacon Darwin 68f9d705f8 build(ivy): ngcc - only test under `no-ivy-aot` mode (#29092)
We want ngcc to test non-AOT builds of the Angular packages,
so we filter the tests in using the `no-ivy-aot` tag.

PR Close #29092
2019-03-20 14:45:54 -04:00
Pete Bacon Darwin 229f035969 feat(ivy): ngcc - support only compiling the first format property to match (#29092)
By default ngcc will compile all the format properties specified. With this
change you can configure ngcc so that it will stop compiling an entry-point
after the first property that matches the `propertiesToConsider`.

PR Close #29092
2019-03-20 14:45:54 -04:00
Pete Bacon Darwin c9f7cdaafd refactor(ivy): ngcc - simplify `Transformer.transform` API (#29092)
By ensuring that EntryPointBundle contains everything that `Transformer.transform()`
needs to do its work, we can simplify its signature.

PR Close #29092
2019-03-20 14:45:54 -04:00
Pete Bacon Darwin 7b55ba58b9 refactor(ivy): ngcc - remove flat-format and use AbsoluteFsPath (#29092)
Now that we are using package.json properties to indicate which
entry-point format to compile, it turns out that we don't really
need to distinguish between flat and non-flat formats, unless we
are compiling `@angular/core`.

PR Close #29092
2019-03-20 14:45:54 -04:00
Pete Bacon Darwin cd449021c1 feat(ivy): ngcc - compile only specified package.json format properties (#29092)
You can now specify a list of properties in the package.json that
should be considered (in order) to find the path to the format to compile.

The build marker system has been updated to store the markers in
the package.json rather than an additional external file.
Also instead of tracking the underlying bundle format that was compiled,
it now tracks the package.json property.

BREAKING CHANGE:

The `proertiesToConsider` option replaces the previous `formats` option,
which specified the final bundle format, rather than the property in the
package.json.
If you were using this option to compile only specific bundle formats,
you must now modify your usage to pass in the properties in the package.json
that map to the format that you wish to compile.

In the CLI, the `--formats` is no longer available. Instead use the
`--properties` option.

FW-1120

PR Close #29092
2019-03-20 14:45:54 -04:00
Pete Bacon Darwin 4bb0259bc0 feat(ivy): ngcc - support targeting a start entry-point (#29092)
You can now, programmatically, specify an entry-point where
the ngcc compilation will occur.
Only this entry-point and its dependencies will be compiled.

FW-1119

PR Close #29092
2019-03-20 14:45:54 -04:00
Pete Bacon Darwin 66239b9d09 refactor(ivy): expose ngcc programmatically (#29092)
The `mainNgcc()` function has been refactored to make it easier to call
ngcc from JavaScript, rather than via the command line.

For example, the `yargs` argument parsing and the exception
handling/logging have moved to the `main-ngcc.ts`
file so that it is only used for the command line version.

FW-1118

PR Close #29092
2019-03-20 14:45:54 -04:00
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
Pete Bacon Darwin cf4718c366 feat(ivy): ngcc - support dts compilation via ES5 bundles (#29092)
Previously we only compiled the typings files, in ngcc, if there was
an ES2015 formatted bundle avaiable. This turns out to be an artificial
constraint and we can also support typings compilation via ES5 formats
too.

This commit changes the ngcc compiler to attempt typings compilation
via ES5 if necessary. The order of the formats to consider is now:
FESM2015, FESM5, ESM2015, ESM5.

FW-1122

PR Close #29092
2019-03-20 14:45:54 -04:00
Pete Bacon Darwin 07aeafa75c style(ivy): ngcc - fix typo in comment (#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
George Kalpakas ce4da3f8e5 fix(ivy): run annotations handlers' `resolve()` in `ngcc` (#28963)
The `resolve` phase (run after all handlers have analyzed) was
introduced in 7d954dffd, but `ngcc` was not updated to run the handlers'
`resolve()` methods. As a result, certain operations (such as listing
directives used in component templates) would not be performed by
`ngcc`.

This commit fixes it by running the `resolve()` methods once analysis
has been completed.

PR Close #28963
2019-03-18 17:43:20 -04:00
George Kalpakas e79f57a6b8 test(ivy): expand `ngcc` `DecorationAnalyzer` tests to cover more cases (#28963)
PR Close #28963
2019-03-18 17:43:20 -04:00
George Kalpakas c439e14d39 refactor(ivy): avoid code duplication in `ngcc` tests (#28963)
PR Close #28963
2019-03-18 17:43:20 -04:00
George Kalpakas a8d84660e5 refactor(ivy): improve error message in `ngtsc`'s `findExportedNameOfNode()` (#28963)
PR Close #28963
2019-03-18 17:43:20 -04:00
George Kalpakas 4525619a73 refactor(ivy): remove unnecessary escaping in RegExp (#28963)
PR Close #28963
2019-03-18 17:43:20 -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
Alan Agius df354d1b34 fix(bazel): add missing binary path for api-extractor (#29202)
`api-extractor` binary is required for external consumers of `ng_module` that want to use the `bundle_dts` flag.

This also sets a different api-exttractor binary to use for ng_module, based if it's internal or external.

PR Close #29202
2019-03-12 10:49:49 -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
Alan ca20f571b8 fix(ivy): always convert `rootDirs` to `AbsoluteFsPath` in `getRootDirs` (#29151)
`getCurrentDirectory` directory doesn't return a posix separated normalized path. While `rootDir` and `rootDirs` should return posix separated paths, it's best to not assume as other paths within the compiler options can be returned not posix separated such as `basePath`

See: https://github.com/Microsoft/TypeScript/blob/master/src/compiler/sys.ts#L635

This partially fixes #29140, however there needs to be a change in the CLI as well to handle this, as at the moment we are leaking devkit paths which is not correct.

Fixes #29140

PR Close #29151
2019-03-11 08:31:52 -07:00
Alan Agius a5b8420234 fix(ivy): render alias exports for private declarations if possible (#28735)
Sometimes declarations are not exported publicly but are exported under
a private name. In this case, rather than adding a completely new
export to the entry point, we should create an export that aliases the
private name back to the original public name.

This is important when the typings files have been rolled-up using a tool
such as the [API Extractor](https://api-extractor.com/). In this case
the internal type of an aliased private export will be removed completely
from the typings file, so there is no "original" type to re-export.

For example:

If there are the following TS files:

**entry-point.ts**

```ts
export {Internal as External} from './internal';
```

**internal.ts**

```ts
export class Internal {
  foo(): void;
}
```

Then the API Extractor might roll up the .d.ts files into:

```ts
export declare class External {
  foo(): void;
}
```

In this case ngcc should add an export so the file looks like:

```ts
export declare class External {
  foo(): void;
}
export {External as Internal};
```

PR Close #28735
2019-03-11 07:17:19 -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
Alex Rickabaugh 37c5a26421 perf(ivy): switch ngtsc to use single-file emit (#29147)
In the TypeScript compiler API, emit() can be performed either on a single
ts.SourceFile or on the entire ts.Program simultaneously.

ngtsc previously used whole-program emit, which was convenient to use while
spinning up the project but has a significant drawback: it causes a type
checking operation to occur for the whole program, including .d.ts files.
In large Bazel environments (such as Google's codebase), an ngtsc invocation
can have a few .ts files and thousands of .d.ts inputs. This unwanted type
checking is therefore a significant drain on performance.

This commit switches ngtsc to emit each .ts file individually, avoiding the
unwanted type checking.

PR Close #29147
2019-03-08 11:56:46 -08:00
Pete Bacon Darwin 142ac41cac fix(ivy): ngcc - handle prototype pseudo-member from typings file in ESM5 host (#29158)
When processing a JavaScript program, TS may come across a symbol that has
been imported from a TypeScript typings file.

In this case the compiler may pass the ReflectionHost a `prototype` symbol
as an export of the class.

This pseudo-member symbol has no declarations, which previously caused the
code in `Esm5ReflectionHost.reflectMembers()` to crash.

Now we just quietly ignore such a symbol and leave `Esm2015ReflectionHost`
to deal with it.

(As it happens `Esm2015ReflectionHost` also quietly ignores this symbol).

PR Close #29158
2019-03-08 09:34:20 -08:00