Skip to content

Conversation

torch2424
Copy link
Contributor

@torch2424 torch2424 commented Feb 25, 2021

closes #1643
closes #1559

Kind of relates to #1647
Doesn't fix, but puts on the right path I think, for relates to #1648

So this PR was opened from a discussion in the tinygo slack: https://gophers.slack.com/archives/CDJD3SUP6/p1614201204223100 . Involving a conflict with wasm imports with the name of write. Which conflicts with the LLVM IR @write, and requires decoupling the LLVM IR symbol, and the wasm-import-name.

I tested this pr with the following code: https://github.com/torch2424/tinygo-compiler-playground (Which also contains the output LLVM IR of this current PR) , and ran the tests: go test -target=wasm and make wasmtest.

Screenshots of tests and things

Screenshot from 2021-02-24 18-20-02
Screenshot from 2021-02-24 18-15-57
Screenshot from 2021-02-24 18-14-04

@torch2424
Copy link
Contributor Author

torch2424 commented Feb 25, 2021

Oops, looks like my fork got a little weird, Let me force push to this branch based on my current branch 😄

EDIT: Ah! The actual issue was that I tried to merge into release, and not dev 🙃 Fixing that now!

EDIT2: This is now for real good to go! 😄 🎉

@torch2424 torch2424 changed the base branch from release to dev February 25, 2021 03:39
@deadprogram
Copy link
Member

Hello @torch2424 thanks for this contribution.

Looks like there are some problems with the CI build: https://app.circleci.com/pipelines/github/tinygo-org/tinygo/4409/workflows/09f56573-cf9f-4d30-af51-fc15dfc75753/jobs/24355/parallel-runs/0/steps/0-121?invite=true

It appears that you need to run go fmt on the test output.

Separately, please make sure you rebase off of the most current dev branch to pickup some CI fixes from yesterday/

Thank you!

@torch2424
Copy link
Contributor Author

Hello @deadprogram Thanks for the tips! 😄

Looks like there are some problems with the CI build: https://app.circleci.com/pipelines/github/tinygo-org/tinygo/4409/workflows/09f56573-cf9f-4d30-af51-fc15dfc75753/jobs/24355/parallel-runs/0/steps/0-121?invite=true

It appears that you need to run go fmt on the test output.

So I tried running go fmt and gofmt -w but it just gives the same error unfortunately :(

Screenshot from 2021-02-25 11-13-29

Though, I am a bit confused why this would be happening? As I don't know why the test output is incorrectly formatted for the fix that I made? 🤔

Separately, please make sure you rebase off of the most current dev branch to pickup some CI fixes from yesterday/

I made sure to do that! Looking at my branch, I am now rebased on top of: torch2424@e76729c . Which seems to match up with what is at the HEAD of tinygo:dev 😄 🎉

@torch2424
Copy link
Contributor Author

torch2424 commented Feb 25, 2021

So I tried running go fmt and gofmt -w but it just gives the same error unfortunately :(

So I did some digging around the makefile, and I just had to run the fmt in the makefile, make fmt. 😄


Things are starting to pass in the CI, so I think this is good to go @deadprogram ! 😄 🎉

Comment on lines 161 to 162
wasmImportNameAttr := c.ctx.CreateStringAttribute("wasm-import-name", info.importName)
llvmFn.AddFunctionAttr(wasmImportNameAttr)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps this needs an extra check that info.importName is not unset (an empty string)?

if info.module == "" {
info.linkName = info.importName
} else {
info.linkName = fmt.Sprintf("tinygo_wasm_import_%s_%s", info.module, info.importName)
Copy link
Member

@aykevl aykevl Feb 25, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are here introducing an order dependency between //go:wasm-module and //export: using //export before //go:wasm-module would change the behavior which is probably not expected.
Also, you're setting info.importName for all systems, not just WebAssembly? I guess LLVM will ignore it but it doesn't seem clean to me.

Instead of this if/else, I would move this if/else right after the for loop (putting parts[1] in a temporary variable). Something like this:

if info.module != "" {
    // WebAssembly import
    info.importName = importName
} else {
    info.linkName = importName
}

Note, in particular, that this doesn't change the link name. I think that's fine (and perhaps better): a TinyGo function name is unlikely to conflict with a name from another programming language with names such as main.someExportedName or github.com/user/pkg/subpkg.someFunction.

@torch2424
Copy link
Contributor Author

Thanks for the review @aykevl ! 😄

So I addressed the first comment!

and then for the second suggestion I tried moving it after the for loop, but then I get runtime panics (I added a screenshot), and I couldn't figure out why that was happening. 🤔 But! I was going to start heading out for the day, so I just pushed up where I'm at. But no worries, I'm sure I'll figure out what is going on. 😄

Screenshot from 2021-02-25 19-15-18

Once everything is good to go I'll add a mention 😄 👍

@torch2424
Copy link
Contributor Author

@deadprogram @aykevl Alright! So I fixed the bug I had yesterday! 😄 🎉

I saw the CI was passing, but then found an uneeded comment, removed it, and then re-ran make fmt. And my example is still working! 🎉

Screenshot from 2021-02-26 13-04-07

So I think this is good to go! 😄

@deadprogram
Copy link
Member

This is some great work @torch2424 thank you for all of the updates to feedback.

Would you prefer that I squash the commits before merging, or would you like to do that yourself?

Copy link
Member

@aykevl aykevl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me!

if decl, ok := f.Syntax().(*ast.FuncDecl); ok && decl.Doc != nil {

// Our importName for a wasm module (if we are compiling to wasm), or llvm link name
var importName string = ""
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a nitpick: this can be declared slightly shorter as follows:

importName := ""

or like this:

var importName string

@torch2424
Copy link
Contributor Author

Ah! My apologies, been handling some family stuff as of lately! 😄

@deadprogram

Would you prefer that I squash the commits before merging, or would you like to do that yourself?

First, thank you for the kind words! 😄 🎉 Please feel free to squash this, I'd very much appreciate it 😄


@aykevl

Thank you for the review. Made the suggested change, this should be good to go! 😄 🎉

@deadprogram
Copy link
Member

Thank you so very much for all the effort on this contribution. Now squash/merging.

@torch2424
Copy link
Contributor Author

@deadprogram @aykevl Yay! Thank you very much for the review, and squashing / merging! 😄 🎉

@torch2424 torch2424 deleted the torch2424/fix-1559 branch March 3, 2021 22:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Cannot import functions with the same name from different modules Import uses the wrong module when function name is "write"
3 participants