Clarifications/confusion about `task.return`

[alexcrichton]

Looking at today's definition of task.return in CanonicalABI.md I'm left with a few questions I want to clarify:

• For the type of the function generated it takes $opts into account, but that means that the intrinsic can be declared as both async and sync, is that intended? Is there a use case for calling this asynchronously?
• For the runtime validation when the intrinsic is called it ensures that the $opts on task.return equals the options specified on the original canon lift, but is this what's intended when taking into account async/callbacks/etc? My (naive) expectation was that I could have an async/callback lifted export and be able to call this intrinsic synchronously, but as-written that means that the intrinsic would generate a trap I think?

cc @dicej

[lukewagner]

Ah, great point! I think what's missing is that we need to specify that validation only allows a subset of the <opts> and only this subset is required to equal the <opts> on the lift, and this subset would (currently) only include memory, string_encoding and realloc.

So we'd have something like:

async def canon_task_return(task, result_type, opts, flat_args):
  ...
  trap_if(opts != only_return_opts(task.opts))
  ...

Does that sound right?

[alexcrichton]

Ah ok yeah that makes sense to me. To confirm though it's intentional that this intrinsic shouldn't be allowed to have async on it? That definitely simplifies it I think, but wanted to double-check

[lukewagner]

Right! No async, post_return, callback or always_task_return. I'll follow up with a PR in a bit.

[lukewagner]

Hopefully fixed in #456