Replace FutureFeatures.md content with current links (WebAssembly#1541)

* Replace FutureFeatures.md content with current links

FutureFeatures.md contained a list of some possible future features
envisioned early in WebAssembly's history. At this time, this list no
longer reliably reflects current priorities of CG participants, so
remove the content and just link to the main feature, proposal, and
discussion lists.

Some of them these features now have their own proposal repos, others
have their own design-repo issues, others are now covered by documents
in tool-conventions. And some do not appear to have active discussions.

If anyone would like to start a discussion about any of these features,
please file an issue in [the design repo's issue tracker].

[the design repo's issue tracker]: https://github.com/WebAssembly/design/issues

* Update links to FutureFeatures.md to link elsewhere.

Author: sunfishcode

CAndC++.md

@@ -127,7 +127,7 @@ expected that compiled WebAssembly programs will behave very consistently
 across different implementations, and across different versions of the same
 implementation.
 
-[future 64-bit]: FutureFeatures.md#linear-memory-bigger-than-4-gib
+[future 64-bit]: https://github.com/WebAssembly/memory64
 [future threads]: https://github.com/WebAssembly/design/issues/1073
 [future simd]: https://github.com/WebAssembly/design/issues/1075
 [future exceptions]: https://github.com/WebAssembly/design/issues/1078

DynamicLinking.md

@@ -92,4 +92,4 @@ for specialized purposes.
 
  [ABI]: https://en.wikipedia.org/wiki/Application_binary_interface
 
-[future types]: FutureFeatures.md#more-table-operators-and-types
+[future types]: https://github.com/WebAssembly/reference-types/blob/master/proposals/reference-types/Overview.md#language-extensions

FAQ.md

@@ -392,5 +392,5 @@ Android / iOS.
 
 [future general]: FutureFeatures.md
 [future garbage collection]: https://github.com/WebAssembly/proposals/issues/16
-[future floating point]: FutureFeatures.md#additional-floating-point-operators
-[future memory control]: FutureFeatures.md#finer-grained-control-over-memory
+[future floating point]: https://github.com/WebAssembly/design/issues/1391
+[future memory control]: https://github.com/WebAssembly/memory-control

FeatureTest.md

@@ -41,8 +41,8 @@ it can be constant-folded by WebAssembly engines.
 
 To illustrate, consider 4 examples:
 
-* [`i32.min_s` :unicorn:][future integer] - Strategy 2
-  could be used to translate `(i32.min_s lhs rhs)` into an equivalent expression
+* [`i32.bitrev` :unicorn:][future integer] - Strategy 2
+  could be used to translate `(i32.bitrev lhs rhs)` into an equivalent expression
   that stores `lhs` and `rhs` in locals then uses `i32.lt_s` and `select`.
 * [Threads :unicorn:][future threads] - If an application uses `#ifdef` extensively
   to produce thread-enabled/disabled builds, Strategy 1 would be appropriate.
@@ -61,7 +61,7 @@ To illustrate, consider 4 examples:
   the existing `__builtin_cpu_supports`.
 * [SIMD][future simd] - When SIMD operators have a good-enough
   polyfill, e.g., `f32x4.fma` via `f32x4.mul`/`add`, Strategy 2 could be used 
-  (similar to the `i32.min_s` example above). However, when a SIMD feature has no
+  (similar to the `i32.bitrev` example above). However, when a SIMD feature has no
   efficient polyfill (e.g., `f64x2`, which introduces both operators *and*
   types), alternative algorithms need to be provided and selected at load time.
 
@@ -101,8 +101,8 @@ See also the [better feature testing support :unicorn:][future feature testing]
 future feature.
 
 [future general]: FutureFeatures.md
-[future feature testing]: FutureFeatures.md#feature-testing
-[future integer]: FutureFeatures.md#additional-integer-operators
+[future feature testing]: https://github.com/WebAssembly/design/issues/1280
+[future integer]: https://github.com/WebAssembly/design/issues/1382
 [future threads]: https://github.com/WebAssembly/design/issues/1073
 [future simd]: https://github.com/WebAssembly/design/issues/1075
-[future memory control]: FutureFeatures.md#finer-grained-control-over-memory
+[future memory control]: https://github.com/WebAssembly/memory-control

FutureFeatures.md

@@ -1,6 +1,6 @@
 # JIT and Optimization Library
 
-WebAssembly's [Just-in-Time compilation (JIT)][future jit control]
+WebAssembly's Just-in-Time compilation (JIT)
 interface will likely be fairly low-level, exposing general-purpose primitives
 rather than higher-level functionality. Still, there is a need for higher-level
 functionality, and for greater flexibility than the WebAssembly spec can provide.
@@ -84,5 +84,3 @@ A significant range of approaches are possible:
     would allow a unique degree of flexibility.
 
  * And many things in between.
-
-[future jit control]: FutureFeatures.md#platform-independent-just-in-time-jit-compilation

JITLibrary.md

@@ -32,7 +32,7 @@ characteristics:
 * Memory regions which can be efficiently addressed with 32-bit
   pointers or indices.
 * wasm64 additionally supports linear memory bigger than
- [4 GiB with 64-bit pointers or indices][memory64].
+ [4 GiB with 64-bit pointers or indices][future 64-bit].
 * Enforce secure isolation between WebAssembly modules and other modules or
   processes executing on the same machine.
 * An execution environment which offers forward progress guarantees to all
@@ -61,6 +61,6 @@ the standard interface to the host environment's available imports either at
 compile-time (via `#ifdef`) or run-time (via [feature detection]
 and dynamic [loading](Modules.md)/[linking](DynamicLinking.md)).
 
-[memory64]: https://github.com/WebAssembly/memory64/blob/main/proposals/memory64/Overview.md
+[future 64-bit]: https://github.com/WebAssembly/memory64/blob/main/proposals/memory64/Overview.md
 [floating-point operations]: https://webassembly.github.io/spec/core/exec/numerics.html#floating-point-operations
 [feature detection]: https://github.com/WebAssembly/design/issues/1280

Portability.md

@@ -457,10 +457,10 @@ hardware platforms.
 ## Motivating Scenarios for Feature Testing
 
 1. [Post-MVP :unicorn:][future general],
-[`i32.min_s` :unicorn:][future integer] is introduced. A
+[`i32.bitrev` :unicorn:][future bitrev] is introduced. A
 WebAssembly developer updates their toolkit so that the compiler may leverage
-`i32.min_s`. The developer's WebAssembly module works correctly both on
-execution environments at MVP, as well as those supporting `i32.min_s`.
+`i32.bitrev`. The developer's WebAssembly module works correctly both on
+execution environments at MVP, as well as those supporting `i32.bitrev`.
 
  * A variant of this, where a few more new opcodes are available, the compiler
 is updated to be able to leverage all of them, but not all execution targets
@@ -605,8 +605,8 @@ Moreover, programming languages that allow control transfer _expressions_ usuall
 
 
 [future general]: FutureFeatures.md
-[future flow control]: FutureFeatures.md#more-expressive-control-flow
-[future integer]: FutureFeatures.md#additional-integer-operations
+[future flow control]: https://github.com/WebAssembly/design/issues/796
+[future bitrev]: https://github.com/WebAssembly/design/issues/1382
 [future threads]: https://github.com/WebAssembly/design/issues/1073
 [future simd]: https://github.com/WebAssembly/design/issues/1075
 [future garbage collection]: https://github.com/WebAssembly/proposals/issues/16

Rationale.md

@@ -64,8 +64,8 @@ support for [multiple linear memory sections](Modules.md#linear-memory-section)
 [Traps](Semantics.md#traps) are used to immediately terminate execution and
 signal abnormal behavior to the execution environment. In a browser, this is
 represented as a JavaScript exception. Support for
-[module-defined trap handlers][future trapping]
-will be implemented in the future. Operations that can trap include:
+module-defined trap handlers
+may be implemented in the future. Operations that can trap include:
 
  * specifying an invalid index in any index space,
  * performing an indirect function call with a mismatched signature,
@@ -181,5 +181,4 @@ in WebAssembly.
  [time of check to time of use]: https://en.wikipedia.org/wiki/Time_of_check_to_time_of_use
 
 [future threads]: https://github.com/WebAssembly/design/issues/1073
-[future memory control]: FutureFeatures.md#finer-grained-control-over-memory
-[future trapping]: FutureFeatures.md#trapping-or-non-trapping-strategies
+[future memory control]: https://github.com/WebAssembly/memory-control