-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Non existing function imported when compiling for wasm #78744
Comments
@athei AFAIK wasm doesn't support unwinding, I think you need |
I have. That said, it appears that it is disabled automatically if the target spec disables unwinding. |
Also, disable overflow check due to bug in rustc: rust-lang/rust#78744
Does anybody have a solution for this? |
@athei I just tried your reproducer from https://github.com/athei/mult-panic with the latest |
I can confirm that the reproducer no longer reproduces the bug with the new rust nightly. This does not necessarily mean that the root cause is fixed, though. |
@athei would you be interested in adding a test for this? I doubt we'll be able to track down the exact cause, but preventing it from regressing seems just as good :) |
Yes. I would be interested. Can you toss me in the general direction where this test would go (as in which test sub directory)? |
@athei it depends what you need to test - it looks like the code here did compile successfully, it just didn't run, so you'd probably need a new run-make test (since there's no way to run wasm natively). |
Running isn't required I think. It would be OK to compile it and then look at the binaries imports and fail if there is anything. |
I guess that would still be a run-make test just that I don't run but inspect the binary? |
@athei yes, that's what I was imagining :) |
Add regression test for a spurious import This PR adds a test that verifies that the bug described in the linked issue does not creep back into the code. In essence it checks that compiling some specific code (that uses 128 bit multiplication) with a specific set of compiler options does not lead to a spurious import of a panic function. I noticed that other wasm tests use `# only-wasm32-bare` in their `Makefile`. This will skip the test for me. I did not find out how to run this test locally. Maybe someone can help. closes rust-lang#78744 r? `@jyn514`
Here's another example reproducing the same problem differently: With
|
I got it too with
|
Posting on a closed issue is not a good way to get visibility for this problem. I suggest opening a new issue and linking back to this one. |
Restore `#![no_builtins]` crates participation in LTO. After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again. `#![no_builtins]` with LTO does not result in undefined references to the error. I believe this type of issue won't happen again. \(^▽^)/ I will test the following issues later to verify. The task format is `Fixes {issue} {nightly-2023-07-20 result} {PR rust-lang#113923 result}`. - [x] Fixes rust-lang#72140. ❌ ✅ - [x] Fixes rust-lang#112245. ❌ ✅ - [x] Fixes rust-lang#110606. ❌ ✅ - [ ] Fixes rust-lang#105734. - [ ] Fixes rust-lang#96486. - [ ] Fixes rust-lang#108853. - [x] Fixes rust-lang/compiler-builtins#347. ❌ ✅ - [ ] Fixes rust-lang#108893. - [ ] Fixes rust-lang#78744. Fixes rust-lang#91158. Fixes rust-lang/cargo#10118. The `nightly-2023-07-20` version does not always reproduce problems due to changes in compiler-builtins, core, and user code. That's why this issue recurs and disappears. Some issues were not tested due to the difficulty of reproducing them. r? pnkfelix cc `@bjorn3` `@japaric` `@alexcrichton` `@Amanieu`
…kfelix Restore `#![no_builtins]` crates participation in LTO. After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again. `#![no_builtins]` with LTO does not result in undefined references to the error. I believe this type of issue won't happen again. \(^▽^)/ I will test the following issues later to verify. The task format is `Fixes {issue} {nightly-2023-07-20 result} {PR rust-lang#113923 result}`. - [x] Fixes rust-lang#72140. ❌ ✅ - [x] Fixes rust-lang#112245. ❌ ✅ - [x] Fixes rust-lang#110606. ❌ ✅ - [ ] Fixes rust-lang#105734. - [ ] Fixes rust-lang#96486. - [ ] Fixes rust-lang#108853. - [x] Fixes rust-lang/compiler-builtins#347. ❌ ✅ - [ ] Fixes rust-lang#108893. - [ ] Fixes rust-lang#78744. Fixes rust-lang#91158. Fixes rust-lang/cargo#10118. The `nightly-2023-07-20` version does not always reproduce problems due to changes in compiler-builtins, core, and user code. That's why this issue recurs and disappears. Some issues were not tested due to the difficulty of reproducing them. r? pnkfelix cc `@bjorn3` `@japaric` `@alexcrichton` `@Amanieu`
…kfelix Restore `#![no_builtins]` crates participation in LTO. After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again. `#![no_builtins]` with LTO does not result in undefined references to the error. I believe this type of issue won't happen again. \(^▽^)/ I will test the following issues later to verify. The task format is `Fixes {issue} {nightly-2023-07-20 result} {PR rust-lang#113923 result}`. - [x] Fixes rust-lang#72140. ❌ ✅ - [x] Fixes rust-lang#112245. ❌ ✅ - [x] Fixes rust-lang#110606. ❌ ✅ - [ ] Fixes rust-lang#105734. - [ ] Fixes rust-lang#96486. - [ ] Fixes rust-lang#108853. - [x] Fixes rust-lang/compiler-builtins#347. ❌ ✅ - [ ] Fixes rust-lang#108893. - [ ] Fixes rust-lang#78744. Fixes rust-lang#91158. Fixes rust-lang/cargo#10118. The `nightly-2023-07-20` version does not always reproduce problems due to changes in compiler-builtins, core, and user code. That's why this issue recurs and disappears. Some issues were not tested due to the difficulty of reproducing them. r? pnkfelix cc `@bjorn3` `@japaric` `@alexcrichton` `@Amanieu`
…kfelix Restore `#![no_builtins]` crates participation in LTO. After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again. `#![no_builtins]` with LTO does not result in undefined references to the error. I believe this type of issue won't happen again. Fixes rust-lang#72140. Fixes rust-lang#112245. Fixes rust-lang#110606. Fixes rust-lang#105734. Fixes rust-lang#96486. Fixes rust-lang#108853. Fixes rust-lang#108893. Fixes rust-lang#78744. Fixes rust-lang#91158. Fixes rust-lang/cargo#10118. Fixes rust-lang/compiler-builtins#347. The `nightly-2023-07-20` version does not always reproduce problems due to changes in compiler-builtins, core, and user code. That's why this issue recurs and disappears. Some issues were not tested due to the difficulty of reproducing them. r? pnkfelix cc `@bjorn3` `@japaric` `@alexcrichton` `@Amanieu`
…kfelix Restore `#![no_builtins]` crates participation in LTO. After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again. `#![no_builtins]` with LTO does not result in undefined references to the error. I believe this type of issue won't happen again. Fixes rust-lang#72140. Fixes rust-lang#112245. Fixes rust-lang#110606. Fixes rust-lang#105734. Fixes rust-lang#96486. Fixes rust-lang#108853. Fixes rust-lang#108893. Fixes rust-lang#78744. Fixes rust-lang#91158. Fixes rust-lang/cargo#10118. Fixes rust-lang/compiler-builtins#347. The `nightly-2023-07-20` version does not always reproduce problems due to changes in compiler-builtins, core, and user code. That's why this issue recurs and disappears. Some issues were not tested due to the difficulty of reproducing them. r? pnkfelix cc `@bjorn3` `@japaric` `@alexcrichton` `@Amanieu`
…kfelix Restore `#![no_builtins]` crates participation in LTO. After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again. `#![no_builtins]` with LTO does not result in undefined references to the error. I believe this type of issue won't happen again. Fixes rust-lang#72140. Fixes rust-lang#112245. Fixes rust-lang#110606. Fixes rust-lang#105734. Fixes rust-lang#96486. Fixes rust-lang#108853. Fixes rust-lang#108893. Fixes rust-lang#78744. Fixes rust-lang#91158. Fixes rust-lang/cargo#10118. Fixes rust-lang/compiler-builtins#347. The `nightly-2023-07-20` version does not always reproduce problems due to changes in compiler-builtins, core, and user code. That's why this issue recurs and disappears. Some issues were not tested due to the difficulty of reproducing them. r? pnkfelix cc `@bjorn3` `@japaric` `@alexcrichton` `@Amanieu`
Restore `#![no_builtins]` crates participation in LTO. After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again. `#![no_builtins]` with LTO does not result in undefined references to the error. I believe this type of issue won't happen again. Fixes rust-lang#72140. Fixes rust-lang#112245. Fixes rust-lang#110606. Fixes rust-lang#105734. Fixes rust-lang#96486. Fixes rust-lang#108853. Fixes rust-lang#108893. Fixes rust-lang#78744. Fixes rust-lang#91158. Fixes rust-lang/cargo#10118. Fixes rust-lang/compiler-builtins#347. The `nightly-2023-07-20` version does not always reproduce problems due to changes in compiler-builtins, core, and user code. That's why this issue recurs and disappears. Some issues were not tested due to the difficulty of reproducing them. r? pnkfelix cc `@bjorn3` `@japaric` `@alexcrichton` `@Amanieu`
…kfelix Restore `#![no_builtins]` crates participation in LTO. After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again. `#![no_builtins]` with LTO does not result in undefined references to the error. I believe this type of issue won't happen again. Fixes rust-lang#72140. Fixes rust-lang#112245. Fixes rust-lang#110606. Fixes rust-lang#105734. Fixes rust-lang#96486. Fixes rust-lang#108853. Fixes rust-lang#108893. Fixes rust-lang#78744. Fixes rust-lang#91158. Fixes rust-lang/cargo#10118. Fixes rust-lang/compiler-builtins#347. The `nightly-2023-07-20` version does not always reproduce problems due to changes in compiler-builtins, core, and user code. That's why this issue recurs and disappears. Some issues were not tested due to the difficulty of reproducing them. r? pnkfelix cc `@bjorn3` `@japaric` `@alexcrichton` `@Amanieu`
…kfelix Restore `#![no_builtins]` crates participation in LTO. After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again. `#![no_builtins]` with LTO does not result in undefined references to the error. I believe this type of issue won't happen again. Fixes rust-lang#72140. Fixes rust-lang#112245. Fixes rust-lang#110606. Fixes rust-lang#105734. Fixes rust-lang#96486. Fixes rust-lang#108853. Fixes rust-lang#108893. Fixes rust-lang#78744. Fixes rust-lang#91158. Fixes rust-lang/cargo#10118. Fixes rust-lang/compiler-builtins#347. The `nightly-2023-07-20` version does not always reproduce problems due to changes in compiler-builtins, core, and user code. That's why this issue recurs and disappears. Some issues were not tested due to the difficulty of reproducing them. r? pnkfelix cc `@bjorn3` `@japaric` `@alexcrichton` `@Amanieu`
…kfelix Restore `#![no_builtins]` crates participation in LTO. After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again. `#![no_builtins]` with LTO does not result in undefined references to the error. I believe this type of issue won't happen again. Fixes rust-lang#72140. Fixes rust-lang#112245. Fixes rust-lang#110606. Fixes rust-lang#105734. Fixes rust-lang#96486. Fixes rust-lang#108853. Fixes rust-lang#108893. Fixes rust-lang#78744. Fixes rust-lang#91158. Fixes rust-lang/cargo#10118. Fixes rust-lang/compiler-builtins#347. The `nightly-2023-07-20` version does not always reproduce problems due to changes in compiler-builtins, core, and user code. That's why this issue recurs and disappears. Some issues were not tested due to the difficulty of reproducing them. r? pnkfelix cc `@bjorn3` `@japaric` `@alexcrichton` `@Amanieu`
…kfelix Restore `#![no_builtins]` crates participation in LTO. After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again. `#![no_builtins]` with LTO does not result in undefined references to the error. I believe this type of issue won't happen again. Fixes rust-lang#72140. Fixes rust-lang#112245. Fixes rust-lang#110606. Fixes rust-lang#105734. Fixes rust-lang#96486. Fixes rust-lang#108853. Fixes rust-lang#108893. Fixes rust-lang#78744. Fixes rust-lang#91158. Fixes rust-lang/cargo#10118. Fixes rust-lang/compiler-builtins#347. The `nightly-2023-07-20` version does not always reproduce problems due to changes in compiler-builtins, core, and user code. That's why this issue recurs and disappears. Some issues were not tested due to the difficulty of reproducing them. r? pnkfelix cc `@bjorn3` `@japaric` `@alexcrichton` `@Amanieu`
…kfelix Restore `#![no_builtins]` crates participation in LTO. After rust-lang#113716, we can make `#![no_builtins]` crates participate in LTO again. `#![no_builtins]` with LTO does not result in undefined references to the error. I believe this type of issue won't happen again. Fixes rust-lang#72140. Fixes rust-lang#112245. Fixes rust-lang#110606. Fixes rust-lang#105734. Fixes rust-lang#96486. Fixes rust-lang#108853. Fixes rust-lang#108893. Fixes rust-lang#78744. Fixes rust-lang#91158. Fixes rust-lang/cargo#10118. Fixes rust-lang/compiler-builtins#347. The `nightly-2023-07-20` version does not always reproduce problems due to changes in compiler-builtins, core, and user code. That's why this issue recurs and disappears. Some issues were not tested due to the difficulty of reproducing them. r? pnkfelix cc `@bjorn3` `@japaric` `@alexcrichton` `@Amanieu`
Whenever I try to compile some specific code for
wasm32-unknown-unknown
with enabledoverflow-checks
andlto
the compiler inserts a function import into the resulting wasm module that looks like this:These are the complete contents of the
lib.rs
:What seems to trigger the bug are the following conditions:
--target
must bewasm32-unknown-unknown
overflow-checks = true
lto = true
The minimal reproducer repo contains the exact command line that reproduces the bug.
I expected to see this happen:
The resulting wasm module does not import any function from the environment.
Instead, this happened:
The resulting wasm module imports the previously mentioned panic function from the environment.
Meta
rustc +nightly --version --verbose
:The text was updated successfully, but these errors were encountered: