-
Notifications
You must be signed in to change notification settings - Fork 109
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorrect namespaces in externs when non-ambient declarations are imported #1202
Comments
Not sure if that's relevant to your example, but here:
https://github.com/theseanl/tsickle-ambient-externs-bug/blob/master/types/types.d.ts#L5
All types are ambient in the file, due to being in a .d.ts, right?
|
By "ambient" I was just referring to the fact that isAmbient is returning |
@mprobst Maybe then the It seems that SourceFile nodes do not contian the In view of this, it seems to me that we don't need a conditional clause here https://github.com/angular/tsickle/blob/master/src/externs.ts#L629 that checks whether a node is ambient or not. If it belongs to a Moreover, it is invalid to use a value returned from Thus removing |
If I remember correctly, the `if (isAmbientModuleDeclaration) {` handles
the case that somebody might import a non-ambient symbol into an
ambient module. I.e. the symbol used here is or might be from a different
module. Imagine I have `a.ts` that has a regular declaration of `X`, and
`b.d.ts` that imports `X` from `a.ts`. If the original declaration of `X`
was ambient, than we (apparently) mangled its file name using
`moduleNameAsIdentifier`, if it's non-ambient then we need to use
`host.pathToModuleName`. Now I do not recall *why* exactly we have that
difference in name mangling. I'd hope there's a test case for it.
|
Hm, I'm not sure if I understand the situation you've describe correctly. I've tried to look up for a similar test case but couldn't find one -- could you elaborate? So, there is a goog.module goog.module('a.b.c'); // <---- module name produced by host.pathToModuleName
function A() { };
/** @type {number} */
A.prototype.prop; or something, which contains a regular code which defines a class, for example. /** @externs */
/**
* @param {a.b.c.A} x <------- this is what the non-ambient branch produces, using host.pathToModuleName
* @return {*}
*/
some_function = function(x) { } Does this actually work in closure compiler? I thought one needs In addition, if someone imports a non-ambient type declaration (that is, without tsickle/src/type_translator.ts Line 427 in 0a0b1b5
If the type declaration was ambient then it will be included in externs and there will be alias names, so there is no issue. These considerations make me inclined to think that there is no case that is relevant to the described situation, but this could be wrong. When I simply change lines Lines 632 to 633 in 0a0b1b5
to aliasName = moduleNameAsIdentifier(host, resolveModuleName(host, sourceFile.fileName, fullUri)); (I haven't check that this does not do the same operation twice, but it gets the right result) error messageWARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by com.google.protobuf.UnsafeUtil (file:...) to field java.nio.Buffer.address WARNING: Please consider reporting this to the maintainers of com.google.protobuf.UnsafeUtil WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release |
When non-ambient declarations in a module
.d.ts
file is imported and referenced by another.d.ts
, it will have an incorrect name.Here is a repro: https://github.com/theseanl/tsickle-ambient-externs-bug: execute
node invoke_tsickle.js
to generateexterns.js
, then its line 46 contains an identifier that is nowhere defined.The text was updated successfully, but these errors were encountered: