honeymoose
/
angular-cn
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
angular-cn/packages/compiler-cli/ngcc/test/host/util.ts

40 lines
1.6 KiB
TypeScript
Raw Normal View History

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-04 14:43:55 -05: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
*/
import * as ts from 'typescript';
refactor(ivy): move ngcc into a higher level folder (#29092) PR Close #29092
2019-03-20 09:47:58 -04:00
import {CtorParameter} from '../../../src/ngtsc/reflection';
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-04 14:43:55 -05:00
/**
* Check that a given list of `CtorParameter`s has `typeValueReference`s of specific `ts.Identifier`
* names.
*/
export function expectTypeValueReferencesForParameters(
style(ngcc): reformat of ngcc after clang update (#36447) PR Close #36447
2020-04-06 03:30:08 -04:00
parameters: CtorParameter[], expectedParams: (string|null)[], fromModule: string|null = null) {
parameters!.forEach((param, idx) => {
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-04 14:43:55 -05:00
const expected = expectedParams[idx];
if (expected !== null) {
fix(ngcc): properly detect origin of constructor param types (#33901) The ReflectionHost supports enumeration of constructor parameters, and one piece of information it returns describes the origin of the parameter's type. Parameter types come in two flavors: local (the type is not imported from anywhere) or non-local (the type comes via an import). ngcc incorrectly classified all type parameters as 'local', because in the source files that ngcc processes the type parameter is a real ts.Identifer. However, that identifier may still have come from an import and thus might be non-local. This commit changes ngcc's ReflectionHost(s) to properly recognize and report these non-local type references. Fixes #33677 PR Close #33901
2019-11-18 14:53:25 -05:00
if (param.typeValueReference === null) {
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-04 14:43:55 -05:00
fail(`Incorrect typeValueReference generated, expected ${expected}`);
fix(ngcc): properly detect origin of constructor param types (#33901) The ReflectionHost supports enumeration of constructor parameters, and one piece of information it returns describes the origin of the parameter's type. Parameter types come in two flavors: local (the type is not imported from anywhere) or non-local (the type comes via an import). ngcc incorrectly classified all type parameters as 'local', because in the source files that ngcc processes the type parameter is a real ts.Identifer. However, that identifier may still have come from an import and thus might be non-local. This commit changes ngcc's ReflectionHost(s) to properly recognize and report these non-local type references. Fixes #33677 PR Close #33901
2019-11-18 14:53:25 -05:00
} else if (param.typeValueReference.local && fromModule !== null) {
fail(`Incorrect typeValueReference generated, expected non-local`);
} else if (!param.typeValueReference.local && fromModule === null) {
fail(`Incorrect typeValueReference generated, expected local`);
} else if (param.typeValueReference.local) {
if (!ts.isIdentifier(param.typeValueReference.expression)) {
fail(`Incorrect typeValueReference generated, expected identifer`);
} else {
expect(param.typeValueReference.expression.text).toEqual(expected);
}
} else if (param.typeValueReference !== null) {
style(ngcc): reformat of ngcc after clang update (#36447) PR Close #36447
2020-04-06 03:30:08 -04:00
expect(param.typeValueReference.moduleName).toBe(fromModule!);
fix(compiler): handle type references to namespaced symbols correctly (#36106) When the compiler needs to convert a type reference to a value expression, it may encounter a type that refers to a namespaced symbol. Such namespaces need to be handled specially as there's various forms available. Consider a namespace named "ns": 1. One can refer to a namespace by itself: `ns`. A namespace is only allowed to be used in a type position if it has been merged with a class, but even if this is the case it may not be possible to convert that type into a value expression depending on the import form. More on this later (case a below) 2. One can refer to a type within the namespace: `ns.Foo`. An import needs to be generated to `ns`, from which the `Foo` property can then be read. 3. One can refer to a type in a nested namespace within `ns`: `ns.Foo.Bar` and possibly even deeper nested. The value representation is similar to case 2, but includes additional property accesses. The exact strategy of how to deal with these cases depends on the type of import used. There's two flavors available: a. A namespaced import like `import * as ns from 'ns';` that creates a local namespace that is irrelevant to the import that needs to be generated (as said import would be used instead of the original import). If the local namespace "ns" itself is referred to in a type position, it is invalid to convert it into a value expression. Some JavaScript libraries publish a value as default export using `export = MyClass;` syntax, however it is illegal to refer to that value using "ns". Consequently, such usage in a type position *must* be accompanied by an `@Inject` decorator to provide an explicit token. b. An explicit namespace declaration within a module, that can be imported using a named import like `import {ns} from 'ns';` where the "ns" module declares a namespace using `declare namespace ns {}`. In this case, it's the namespace itself that needs to be imported, after which any qualified references into the namespace are converted into property accesses. Before this change, support for namespaces in the type-to-value conversion was limited and only worked correctly for a single qualified name using a namespace import (case 2a). All other cases were either producing incorrect code or would crash the compiler (case 1a). Crashing the compiler is not desirable as it does not indicate where the issue is. Moreover, the result of a type-to-value conversion is irrelevant when an explicit injection token is provided using `@Inject`, so referring to a namespace in a type position (case 1) could still be valid. This commit introduces logic to the type-to-value conversion to be able to properly deal with all type references to namespaced symbols. Fixes #36006 Resolves FW-1995 PR Close #36106
2020-03-17 11:23:46 -04:00
expect(param.typeValueReference.importedName).toBe(expected);
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-04 14:43:55 -05:00
}
}
});
}