Binary reader options and intended use cases

Currently, we have the following binary reader options:

  Features features;
  Stream* log_stream = nullptr;
  bool read_debug_names = false;
  bool stop_on_first_error = true;
  bool fail_on_custom_section_error = true;
  bool skip_function_bodies = false;

Now, features and log_stream are... fairly universal, we wanna be able to select which post-MVP features to enable and disable and oftentimes also enable verbose logging.

However, it's another story with these other options. Most of these aren't available when running the provided tools, but API users can bring their own ReadBinaryOptions. In theory, this leads to use-cases like:

• Emitting IR without function bodies. (#2534 / #2535)
• Interpreting a module without function bodies.
• Interpreting a module with errors.
• Emitting IR with errors (this may well be useful to someone, but we don't officially support it).

among other, potentially questionable ideas. However, we would like to highlight one issue in particular, and it's that our interpreter is designed to be... pretty fast. It's not trying to be the fastest thing in the world, but it does little run-time checking, instead relying entirely on the SharedValidator to do its job. As such, it's a dangerous idea to run (maliciously crafted) broken modules in the interpreter.

Would it make sense to more strictly enforce that many of these options are purely for use with the objdump reader? Ofc, we can still support use-cases like those in #2534 / #2535, but we (Soni) don't believe the API should look like this.

Start by tracing ReadBinaryOptions through the objdump reader and interpreter, with particular attention to SharedValidator and the options for skipping function bodies or tolerating errors. Compare the use cases in #2534 and #2535 with the desired API boundary; done means reaching a maintainer-approved decision on which options are supported by each reader.