This is not actually legal (although the restriction is not
documented anywhere), and is not caught by LLVM unless the codegen
option -verify-machineinstrs is specified. This option is now used
on Travis.
While not legal, this does not seem to result in invalid output
(although it creates an unnecessary spill); however, under extremely
specific circumstances (e.g. when a register scavenger is run under
severe pressure), this will result in a codegen crash, which is
how I found it.
This makes more sense, because "generate" implies *running*
a generator, not *returning* from a generator. That name was
a vestige of the time when libfringe only really provided a .next()
implementation, which made marginally more sense together with
.generate(), but it doesn't anymore when we have .resume().
The core::intrinsics::unreachable() we used at the end of every naked
function is essentially pointless, as #[naked] implies that intrinsic
at the end of the function. rustc currently does not implement that
behavior (rust-lang/rust#32487), but it is a bug. On top of that,
anything except a single asm!() in naked functions is likely to be
disallowed in the future (rust-lang/rust#32490).
A nice side effect is that we avoid the core_intrinsics feature,
which will be never stabilized, though neither asm nor
naked_functions are likely to be stabilized soon.
Also, remove the Windows OsStack implementation. It will not ever
be useful in libfringe, as even if we add support for Windows
using fibers, the OS allocates stacks for fibers and we needn't
do it manually.
The new design concerns itself with one thing and exactly one thing:
passing values back and forth with an extern "C" function.
This allows to simplify fringe::arch into a single primitive, swap.
Close#21
whitequark
edef
Corey Richardson
John Ericson