…xcrichton

Wasm: remove implicit `__heap_base`/`__data_end` exports

This is kind of a follow-up to rust-lang#147225. Currently `__heap_base`/`__data_end` globals are implicitly exported on `wasm*-unknown-unknown` and `wasm32v1-none`, even though they were only used for Wasm multi-threading, requiring the atomics target feature and shared memory.

Instead users should explicitly opt-in to these features, in which case toolchains, like `wasm-bindgen`, would require some linker flags. After this PR the following would be required for multi-threading support in `wasm-bindgen`:
```
-Clink-arg=--shared-memory -Clink-arg=--max-memory=1073741824 -Clink-arg=--import-memory -Clink-arg=--export=__heap_base -Clink-arg=--export=__wasm_init_tls -Clink-arg=--export=__tls_size -Clink-arg=--export=__tls_align -Clink-arg=--export=__tls_base
```

You will notice that the only new addition is `--export=__heap_base`, apparently `wasm-bindgen` doesn't need `__data_end` anymore (I didn't dig into the original motivation).

---

For context why `wasm-bindgen` needed access to `__heap_base`:
There is currently no mechanism in the Wasm tool conventions that automatically allocates the stack for every thread (e.g. via the `start` function). So `wasm-bindgen` has to explicitly call `malloc` to allocate the stack on the new thread.

However, calling `malloc` itself requires a stack to be present! With the help of `__heap_base` `wasm-bindgen` constructs a temporary stack to make this work. This is obviously quite hacky. A newer implementation could go a different route: e.g. allocate the threads stack in the main thread and passing the right information on, not requiring access to `__heap_base` at all (and avoiding this really messy workaround).

I should also note here that e.g. [`js-bindgen`](https://github.com/wasm-bindgen/js-bindgen), the successor currently being worked on, doesn't need any of these exports because it doesn't rely on post-processing. In which case all of these variables can be accessed by name at link-time, instead of requiring the linker to export each variable for post-processing to find them by name. That is to say: all these workaround are toolchain-specific and not universal to the Wasm targets.

---

r? @alexcrichton

…xcrichton

Wasm: remove implicit `__heap_base`/`__data_end` exports

This is kind of a follow-up to rust-lang#147225. Currently `__heap_base`/`__data_end` globals are implicitly exported on `wasm*-unknown-unknown` and `wasm32v1-none`, even though they were only used for Wasm multi-threading, requiring the atomics target feature and shared memory.

Instead users should explicitly opt-in to these features, in which case toolchains, like `wasm-bindgen`, would require some linker flags. After this PR the following would be required for multi-threading support in `wasm-bindgen`:
```
-Clink-arg=--shared-memory -Clink-arg=--max-memory=1073741824 -Clink-arg=--import-memory -Clink-arg=--export=__heap_base -Clink-arg=--export=__wasm_init_tls -Clink-arg=--export=__tls_size -Clink-arg=--export=__tls_align -Clink-arg=--export=__tls_base
```

You will notice that the only new addition is `--export=__heap_base`, apparently `wasm-bindgen` doesn't need `__data_end` anymore (I didn't dig into the original motivation).

---

For context why `wasm-bindgen` needed access to `__heap_base`:
There is currently no mechanism in the Wasm tool conventions that automatically allocates the stack for every thread (e.g. via the `start` function). So `wasm-bindgen` has to explicitly call `malloc` to allocate the stack on the new thread.

However, calling `malloc` itself requires a stack to be present! With the help of `__heap_base` `wasm-bindgen` constructs a temporary stack to make this work. This is obviously quite hacky. A newer implementation could go a different route: e.g. allocate the threads stack in the main thread and passing the right information on, not requiring access to `__heap_base` at all (and avoiding this really messy workaround).

I should also note here that e.g. [`js-bindgen`](https://github.com/wasm-bindgen/js-bindgen), the successor currently being worked on, doesn't need any of these exports because it doesn't rely on post-processing. In which case all of these variables can be accessed by name at link-time, instead of requiring the linker to export each variable for post-processing to find them by name. That is to say: all these workaround are toolchain-specific and not universal to the Wasm targets.

---

r? @alexcrichton

Rollup of 12 pull requests

Successful merges:

 - #155341 (generic_const_args: allow paths to non type consts)
 - #156062 (Added command-line argument support for `wasm32-wali-linux-musl`)
 - #156159 ([AIX] add -bdbg:namedsects:ss link arg)
 - #156174 (Wasm: remove implicit `__heap_base`/`__data_end` exports)
 - #156186 (fix: remap ci-llvm debug paths via `-ffile-prefix-map`)
 - #156193 (port `rustc_ast*` crates from `box_` to `deref_patterns`)
 - #156201 (Don't run ui-fulldeps tests twice in stage 1)
 - #155808 (Always use `ConstFn` context for `const` closures)
 - #156105 (interpret: correctly deal with repr(transparent) enums)
 - #156148 (Use `all_impls` instead of handrolling it)
 - #156156 (Adjust getMCSubtargetInfo signature for LLVM 23+)
 - #156205 (move generalization test)

…xcrichton

Wasm: remove implicit `__heap_base`/`__data_end` exports

This is kind of a follow-up to rust-lang#147225. Currently `__heap_base`/`__data_end` globals are implicitly exported on `wasm*-unknown-unknown` and `wasm32v1-none`, even though they were only used for Wasm multi-threading, requiring the atomics target feature and shared memory.

Instead users should explicitly opt-in to these features, in which case toolchains, like `wasm-bindgen`, would require some linker flags. After this PR the following would be required for multi-threading support in `wasm-bindgen`:
```
-Clink-arg=--shared-memory -Clink-arg=--max-memory=1073741824 -Clink-arg=--import-memory -Clink-arg=--export=__heap_base -Clink-arg=--export=__wasm_init_tls -Clink-arg=--export=__tls_size -Clink-arg=--export=__tls_align -Clink-arg=--export=__tls_base
```

You will notice that the only new addition is `--export=__heap_base`, apparently `wasm-bindgen` doesn't need `__data_end` anymore (I didn't dig into the original motivation).

---

For context why `wasm-bindgen` needed access to `__heap_base`:
There is currently no mechanism in the Wasm tool conventions that automatically allocates the stack for every thread (e.g. via the `start` function). So `wasm-bindgen` has to explicitly call `malloc` to allocate the stack on the new thread.

However, calling `malloc` itself requires a stack to be present! With the help of `__heap_base` `wasm-bindgen` constructs a temporary stack to make this work. This is obviously quite hacky. A newer implementation could go a different route: e.g. allocate the threads stack in the main thread and passing the right information on, not requiring access to `__heap_base` at all (and avoiding this really messy workaround).

I should also note here that e.g. [`js-bindgen`](https://github.com/wasm-bindgen/js-bindgen), the successor currently being worked on, doesn't need any of these exports because it doesn't rely on post-processing. In which case all of these variables can be accessed by name at link-time, instead of requiring the linker to export each variable for post-processing to find them by name. That is to say: all these workaround are toolchain-specific and not universal to the Wasm targets.

---

r? @alexcrichton

Rollup of 15 pull requests

Successful merges:

 - #151122 (fix: more descriptive error message for enum to integer)
 - #155341 (generic_const_args: allow paths to non type consts)
 - #156062 (Added command-line argument support for `wasm32-wali-linux-musl`)
 - #156159 ([AIX] add -bdbg:namedsects:ss link arg)
 - #156174 (Wasm: remove implicit `__heap_base`/`__data_end` exports)
 - #156186 (fix: remap ci-llvm debug paths via `-ffile-prefix-map`)
 - #156193 (port `rustc_ast*` crates from `box_` to `deref_patterns`)
 - #156201 (Don't run ui-fulldeps tests twice in stage 1)
 - #155808 (Always use `ConstFn` context for `const` closures)
 - #156105 (interpret: correctly deal with repr(transparent) enums)
 - #156148 (Use `all_impls` instead of handrolling it)
 - #156156 (Adjust getMCSubtargetInfo signature for LLVM 23+)
 - #156170 (add known-bug test for coroutine 'static-yields-non-'static unsoundness (#144442))
 - #156195 (Move tests codegen)
 - #156205 (move generalization test)