* Clear faulting_p from a safepoint rather than inside general_error, because jumping into unwind-native-frames could blow up.
* Handle multiple faults from fatal_error by breakpointing. Is there anything else we can safely do at that point?
* Verify memory protection faults in the top half of the signal handlers because signal dispatch could fault. Treat memory faults during gc or fep as fatal errors.
* Add a function factor_vm::abort() that restores the default SIGABRT handler and ::abort()s. Use it from fatal_error() so we get useful context from gdb and so the user gets feedback from the system crash reporter that Factor blew up and didn't just disappear.
* In factorbug(), don't proceed with .s .r .c if it would be unsafe to do so.
* Don't pile on signals if we've already called fatal_error().
Put a no-op "vocab name" drop in the small-enough? tests so that it's immediately apparent from build farm errors which vocabs are deploying over the limit.
This makes the separate "code" and "entry_point" fields in word and quotation redundant, so also remove them to reclaim an additional cell per word and quotation object, which should help with #318.
A signal during early bootstrap is certainly an error, and the environment isn't there yet for Factor's signal handlers to work, so it makes no sense to install Factor's signal handlers beforehand. They'll just crash.
This gives us an escape hatch for when things go way south and ^C can't be handled. Also unmask SIGQUIT and SIGTERM from the stdin_loop thread so the thread doesn't keep the process alive after those signals.
* Change the interface of read-into to return a slice and an eof boolean separately so the compiler can optimize the slice.
* Add an each-stream-block-slice combinator that behaves like each-block but reuses a preallocated buffer for every iteration.
* Pull some strings in the stream-read-into implementation to further improve type propagation and bounds check elimination.
Joe Groff
Philipp Brüschweiler
Slava Pestov
John Benediktsson
Doug Coleman