Remove fast return references from docs

doc/compiler.rst

@@ -2035,34 +2035,9 @@ generic, always correct longjmp handler.
 Compiling "return"
 ==================
 
-Compiling a ``return`` statement is mostly trivial, but there are a few
-interesting issues:
+Compiling a ``return`` statement is mostly trivial, but tail calls pose
+some interesting problems.
 
-* A return can be "fast" or "slow"
-
-* Tail calls
-
-A "slow" return is executed as a longjmp() out of the currently executing
-function.  The longjmp handler will correctly unwind call and catch stacks,
-execute finally-statements, etc.  A "slow" return always gets correct handling
-but is not very fast.
-
-A "fast" return is handled by the executor without resorting to a longmp().
-The goal is to handle most ordinary return statements without need for complex
-call/catch stack management.  The specific restrictions placed on fast returns
-depends on what the executor fast return is capable of doing.
-
-As of Duktape 1.3 fast returns are not yet implemented in the executor.  But
-when they're added, fast returns probably:
-
-* Won't be able to cross an active "finally" statement which would need to
-  capture execution.
-
-* Will be able to cross any other catchers without a "finally" part, including
-  label catchers and "with" bindings.  These, unlike "finally", can be unwound
-  without executing any code.
-
-One non-trivial issue for return statement parsing is tail call handling.
 If the return value is generated by a preceding ``CALL`` opcode, the call
 can be flagged a tail call.  The ``RETURN`` opcode is still emitted just
 in case, if there's some feature preventing the tail call from happening
@@ -2563,11 +2538,6 @@ Future work
 Some future work (not a comprehensive list by any means), in no particular
 order.
 
-Fast return support
--------------------
-
-Add support for proper fast returns (not implemented as of Duktape 1.3).
-
 Better handling of "catch" variables, "let" bindings
 ----------------------------------------------------