Skip to content
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

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

Closed
torch2424 opened this issue Jul 10, 2020 · 9 comments · Fixed by #1415
Closed

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

torch2424 opened this issue Jul 10, 2020 · 9 comments · Fixed by #1415
Assignees
Labels

Comments

@torch2424
Copy link
Contributor

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:

Screenshot from 2020-07-10 13-07-10

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 😄

@torch2424 torch2424 added the bug label Jul 10, 2020
@torch2424 torch2424 changed the title "No exported member" when Importring an exported "import * as" "No exported member" when Importing an exported "import * as" Jul 10, 2020
@dcodeIO
Copy link
Member

dcodeIO commented Jul 10, 2020

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
Copy link
Contributor Author

@dcodeIO Oops haha! 😂

But unfortunately no, that doesn't fix things 😢

Screenshot from 2020-07-10 15-21-51

@torch2424
Copy link
Contributor Author

torch2424 commented Jul 21, 2020

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? 🤔

Screenshot from 2020-07-20 18-10-44

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
Copy link
Member

dcodeIO commented Jul 21, 2020

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
Copy link
Contributor Author

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

@torch2424 torch2424 self-assigned this Jul 21, 2020
@dcodeIO
Copy link
Member

dcodeIO commented Jul 21, 2020

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
Copy link
Contributor Author

@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
Copy link
Contributor Author

@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 🙃

Screenshot from 2020-07-24 18-33-54

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
Copy link
Member

dcodeIO commented Jul 25, 2020

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)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants