all: replace target=wasi with target=wasip1

[ydnar]

This eliminates the wasi build tag in favor of GOOS=wasip1, introduced in Go 1.21.

For backwards compatibility, -target=wasi is a synonym for -target=wasip1.

[aykevl]

While I am in favor of the general idea, there is one problem: we already support wasip1 in a different way. This would add two separate ways of using wasip1 which I think is a bad idea. The other lives in the compiler, here (among others): https://github.com/tinygo-org/tinygo/blob/release/compileopts/target.go#L394

I don't have a strong opinion on either way, but I certainly would want to avoid this duplication. Either by always using the definition in target.go (and no separate JSON file), or by loading the JSON file when using GOOS=wasip1 GOARCH=wasi.

[ydnar]

The latter (loading the JSON file for particular GOARCH/GOOS tuples) is an interesting idea.

That would avoid duplication of config between code and the JSON target files. I’m happy to sketch that out.

[ydnar]

While I am in favor of the general idea, there is one problem: we already support wasip1 in a different way. This would add two separate ways of using wasip1 which I think is a bad idea. The other lives in the compiler, here (among others): https://github.com/tinygo-org/tinygo/blob/release/compileopts/target.go#L394

Remove the duplication of config in target.go in favor of loading a target JSON file seems like a good idea, but that’s a bigger change. Separate PR?

[aykevl]

Reviewed, looks good to me with some nits.

Remove the duplication of config in target.go in favor of loading a target JSON file seems like a good idea, but that’s a bigger change. Separate PR?

Seems fine by me.

[aykevl]

The WebAssembly page size is a fixed constant, and unless WebAssembly decides to introduce a major backwards compatibility break it's not going to change either. I don't think we need to define this in a single place and reuse everywhere (and if we needed to, libc getpagesize would probably be the appropriate place anyway).

In any case, I think it's fine (in fact I'd say just use a numeric constant but a call is fine too).

[ydnar]

Done! I’ll see about a second PR to eliminate the hard-coded target options.

[deadprogram]

@aykevl any other feedback on this PR, or are we good to merge?

[deadprogram]

Reminder to @aykevl on this PR, please.

[deadprogram]

Just looked and realized all the feedback was addressed. Now merging, thank you @ydnar and @aykevl for getting this closer to being all sorted out.

[deadprogram]

Done! I’ll see about a second PR to eliminate the hard-coded target options.

@ydnar you should be unblocked for this now. 😸

[aykevl]

Remove the duplication of config in target.go in favor of loading a target JSON file seems like a good idea, but that’s a bigger change. Separate PR?

@ydnar is this something you're still going to do?

[ydnar]

Thanks for the nudge. I'll take a look.