which means disabling a bunch of individual warnings, until I
fix them up.

I don't actually totally understand how these are pessimizing;
the basic case for this warning seems to be about copy elision in
return values. My best guess is that it has something to do with
the fact that takeError is defined to take ownership anyway, so
I guess it is kind of a move operation already, and maybe returns
a prvalue?

I'm not totally sure how ExecuteAction works, but I'm almost
entirely sure it's not supposed to hang. I copied the Base:: use in
the other ExecuteAction definition.

Some of these I'm not sure about, especially in the debugger. I
don't think there's really a good way to write a bulletproof
accessible_memory_p.

The order of C++ initializer lists is not used - fields are
initialized in the order they are declared in the class. This
matters when an initializer relies on another initialization in the
same initializer list having been completed, but in general we
probably ought to keep the orders the same to avoid any confusion.

The single dispatch miss stuff is not ready, and also I'm not
entirely sure it needs its own lisp function.

This code makes fmt complain because we pass it a weird enum, but
really the error message was unclear anyway.

On Macs, apparently, the underlying type of an enum is not int by
default, so fmt complains if you use %d.
The stream stuff I fixed up a bit since that's an ext: function
and we should not be presenting users with internal codes.