"No exported member" when Importing an exported "import * as"

[torch2424]

I know the title is a bit confusing, but the best way to show off this bug is by just showing the pattern in code 😄

in tests/compiler/reexport.ts we export {} an import * as

https://github.com/torch2424/assemblyscript/blob/export-star-as/tests/compiler/reexport.ts#L28

Then, if we try to import that export in other AS code, it will erorr:

https://github.com/torch2424/assemblyscript/blob/export-star-as/tests/compiler/rereexport.ts#L1

For example:

It is worth noting that if we export {exportstar} along with the other exports, the final wasm module will correctly have the right exports. Seems to just not be working between AS files 😄

cc @dcodeIO @MaxGraey 😄

[dcodeIO]

Hmm, in the example above (and the test?), there seems to be a typo exportstar vs exportstart. Does it still fail when fixing that?

[torch2424]

@dcodeIO Oops haha! 😂

But unfortunately no, that doesn't fix things 😢

[torch2424]

I did some research on this, it seems like the export * doesn't have a foreignPath, therefore it can't find the exports from the original file? 🤔

Though, this kinda makes sense since the namespace is technically in the file, but, I can't seem to find where the namespace is created...Perhaps it's a lazy compilation bug? 🤔 But even if I call a function on the import * as it'll work in the test, but not in the export/import 🤔

[dcodeIO]

A foreignPath is only set for export ... from "foreignPath", so on an export { X } without a from it's expected to be null. Most likely a problem with the algorithm itself, which is kinda unwieldy due to going through multiple stages. Always a lot of fun to dive back into it :)

[torch2424]

Ahhh thanks for the insight 😄 If you don't mind, can you send me a link to where the algorithm is in the code? 😄

[dcodeIO]

Sure: The linking starts around here, after the queued collections have been populated during initialization of the original elements (in their respective file). Afterwards the graph of what re-exports what from where is known, but I guess there's something missing during traversal.

[torch2424]

@dcodeIO Thanks for the link! So after looking at my current fork, it seems like I'm in the right place and everything 😄 🎉 SO I'll just keep doing my console log debugging until I catch something funny 😄

[torch2424]

@dcodeIO So I think I figured out what's wrong, but I'm a bit unsure how to proceed. So if it helps at all, here's my console.log debugging trace 🙃

But from what I'm gathering it seems like the flow is:

• We sucessfully declare that we are exporting reexportstar from reexport.ts
• We see that we want to import reexportstar from reexport.ts
• We try to lookupInSelf for the reexport.ts File class (which Extends Element)
• reexport.ts has no members properties, so everything returns null
• We then fail because we could not find the reexportstar Element object in the reexport.ts File Object.

So in general, I don't think this is an issue with traversal of the file tree. But perhaps, its more of an error that files don't have members. Thus, I am thinking maybe we could notice this pattern in initializeExports when we queue the export, and then manually just create the decalred element and push it onto the reexport.ts members property? To provide more context, I was thinking of doing so here in initializeExport only if it is an import * as export.

Let me know if this makes sense? I've been like going in circles trying to understand what's going on. I finally think I have a realllyyyy good grasp on the flow of logic, and I could hack in a fix, but I figured I'd ask here and do it the right way 😄

cc @dcodeIO or @MaxGraey since either of y'all would probably know what to do 😄

[dcodeIO]

Hmm, what should happen for star imports is that the file becomes converted to a namespace via File#asImportedNamespace, and lookups are then performed against that namespace. Perhaps there's something wrong when such an imported namespace is populated or goes through another layer of exports (in wrong order)?