export aliasee if not export all and if alias is exported

[waterlike86]

we found that when using an exports list (i.e. not export_all), the side module imports the alias.
but just exporting the alias is not enough, we need to export the actual implementation as well (i.e. the aliasee, aliased)

[waterlike86]

@kripken do you think this makes sense? we were trying to obtain the list of aliases by scanning the imports and using llvm to scan the BC files, but there was always some which cannot be obtained and the BC level.
for example
in stdlib, __ZNSt12length_errorD1Ev maps to __ZNSt11logic_errorD2Ev and this information is not available at the BC level, but only available after JSBackend.
would you have any idea how we could get this from outside of the tool chain so we can avoid this modification?

[waterlike86]

cc @awtcode

[kripken]

I think this is right, yes. I thought we already handled it, though, but I'm not sure where.

Please add a testcase - we need one anyhow, and it will also help understand things.

[waterlike86]

@kripken added a test case

[waterlike86]

I think this is right, yes. I thought we already handled it, though, but I'm not sure where.

@kripken actually i see in here it might have been handled for side_modules?

emscripten/emscripten.py

Line 1609 in 6aea2c2

for k, v in metadata['aliases'].items():

[waterlike86]

I think this is right, yes. I thought we already handled it, though, but I'm not sure where.

@kripken actually i see in here it might have been handled for side_modules?
emscripten/emscripten.py

Line 1609 in 6aea2c2

for k, v in metadata['aliases'].items():

tried to edit this such that it works from main_modules as well but it doesnt seem to work

[kripken]

Is this outer loop needed? (all_exported_functions may be very large, which worries me)

Instead, how about

for name, alias in metadata['aliases']:
  if name in all_implemented:
    funcs.add(alias)

[waterlike86]

thats is actually to reduce the number of exports. we could just export all the alias like what you did, i think there arent many.

[waterlike86]

thats also why its only run if not export_all, so there shouldnt be that many exports i hope.

[kripken]

can we remove all the text parsing here? if it is enough to just test for success in running the program, that is simpler and better.

[waterlike86]

sure let me do that.

[kripken]

I think that existing code (line 1609 you found) handles exporting from the asm.js module, but your new code here is still needed to have the functions in the final list of exports overall. To confirm, I assume the test fails without your code change?

[waterlike86]

I think that existing code (line 1609 you found) handles exporting from the asm.js module, but your new code here is still needed to have the functions in the final list of exports overall. To confirm, I assume the test fails without your code change?

yes you are right. the test still fails without my code change.

[waterlike86]

strangely i see test which seem to fail which are unrelated to my change

[kripken]

I think those errors can be ignored (should vanish with merging in latest incoming to here), except for other.test_only_force_stdlibs which looks like we need to figure it out here.

[waterlike86]

@kripken seems like all tests passed after i did a merge from incoming

[kripken]

Thanks @waterlike86, looks good!