Skip to content

RFC: Put unreachablility inside abort function #2041

Description

@MaxGraey

Currently "assert" function and exceptions required one external abort function and one "unreachable" on wasm side.
But what if, instead of inserting unreachable on the wasm side after the abort call, we move the completion of the program to the host side?

Current approach:

function assert(cond: bool, msg: string | null = null): void {
   if (cond) {
     abort(__FILE, __LINE, __COLUMN, msg);
     unreachable();
   }
}

Proposed approach:

function assert(cond: bool, msg: string | null = null): void {
   if (cond) {
     abort(__FILE, __LINE, __COLUMN, msg);
   }
}

and on host side use something like this:

const imports = {
  env: {
    abort(file, line, column, msg) {
      throw new AbortError(`Abort at ${file}[${line}, ${column}]: ${__getString(msg)}`);
    }
  }
}

Pros:

  • Reduce binary size
  • Allows us to turn on recent TrapsNeverHappen mode which will remove much more dead code.

Cons:

  • Breaking changes which especially sensitive for non-web environments.
  • Now the processing of program termination delegate to the host's side. This can be both an advantage (e.g., user can just ignore the assert or specific assert and continue program working) and a disadvantage (non-deterministic termination depends from host to host decision). In general, this point is quite controversial.

Thoghts?

Activity

  1. dcodeIO commented on Aug 19, 2021

    @dcodeIO
    Member

    My immediate thoughts are that we probably cannot trivially remove the use of unreachable, since we are generating it in many places, provide it as a built-in (quite a breaking change removing it), and there are use cases where trapping instead of calling an import can be desirable.

    I would be OK with a separate intrinsic as Alon suggested I think, and separately also see a future where we largely switch to exception handling, of course. As for a Binaryen-level intrinsic, naming it abort would kinda match what we currently do, but I would be fine with any name.

  2. MaxGraey commented on Aug 19, 2021

    @MaxGraey
    MemberAuthor

    Well, separate intrinsic also makes sense, it is not such a breaking change

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions