Skip to content
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

Latest nightly are failing to build non-toy projects at linking stage when using LTO optimization #108853

Closed
dbachelot opened this issue Mar 7, 2023 · 25 comments · Fixed by #113923
Labels
-Zbuild-std Unstable Cargo option: Compile the standard library yourself. A-linkage Area: linking into static, shared libraries and binaries C-bug Category: This is a bug. E-needs-mcve Call for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example P-high High priority regression-untriaged Untriaged performance or correctness regression. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@dbachelot
Copy link

dbachelot commented Mar 7, 2023

After updating to the latest version of Rust, I found that many of my projects are failing to compile at linking stage when doing size-optimized builds (cf. https://github.com/johnthagen/min-sized-rust). I found the possible nightly-to-nightly regression to be from nightly-2023-02-27 to nightly-2023-02-28. This seems to be a real issue since min-sized builds are widely used. Also I failed to reproduce this in a toy project.

To trigger that "bug" I used these compiler flags:

OPTI_FLAGS="-C link-dead-code=n -C lto=fat -C opt-level=z -C embed-bitcode=yes -C panic=abort"
OPTI_ARGS="-Z build-std=std,panic_abort -Z build-std-features=panic_immediate_abort"

# for linux you might want to use -C panic=abort to overpass another bug

RUSTFLAGS=$OPTI_FLAGS cargo +nightly build --target x86_64-unknown-linux-gnu --release $OPTI_ARGS
RUSTFLAGS=$OPTI_FLAGS XWIN_ARCH="x86_64" XWIN_CACHE_DIR="/tmp/xwin_64" cargo +nightly xwin build --target x86_64-pc-windows-msvc --release $OPTI_ARGS

Possible linked issues:

I tried to build those projects with the latest working nightly (nightly-2023-02-27) and the first non-working nightly (nightly-2023-02-28):

I expected to see this happen: build succeed in both cases.

Instead, this happened: linker errors on the first non-working nightly (nightly-2023-02-28) and compile success with the latest working nightly (nightly-2023-02-27). This show a possible regression.

For RustHound (using nightly-2023-02-28):

Compile error

   Compiling rusthound v1.1.62 (/$USER/Projets/XXX/RustHound)
error: linking with `lld-link` failed: exit status: 1
  |
  = note: LC_ALL="C" PATH="/$USER/.rustup/toolchains/nightly-2023-02-28-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin:/$USER/.vscode-server/bin/441438abd1ac652551dbe4d408dfcec8a499b8bf/bin/remote-cli:/$USER/.local/bin:/$USER/.cargo/bin:/$USER/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/tmp" VSLANG="1033" "lld-link" "-flavor" "link" "/NOLOGO" "/tmp/rustcAWOQqQ/symbols.o" "/$USER/Projets/XXX/RustHound/target/x86_64-pc-windows-msvc/release/deps/rusthound.rusthound.4bfd0cff-cgu.3.rcgu.o" "/LIBPATH:/$USER/Projets/XXX/RustHound/target/x86_64-pc-windows-msvc/release/deps" "/LIBPATH:/$USER/Projets/XXX/RustHound/target/release/deps" "/LIBPATH:/tmp/xwin_64/crt/lib/x86_64" "/LIBPATH:/tmp/xwin_64/sdk/lib/um/x86_64" "/LIBPATH:/tmp/xwin_64/sdk/lib/ucrt/x86_64" "/LIBPATH:/$USER/.cargo/registry/src/github.com-1ecc6299db9ec823/windows_x86_64_msvc-0.42.1/lib" "/LIBPATH:/$USER/.cargo/registry/src/github.com-1ecc6299db9ec823/windows_x86_64_msvc-0.34.0/lib" "/LIBPATH:/$USER/Projets/XXX/RustHound/target/x86_64-pc-windows-msvc/release/build/ring-175a80523169bc78/out" "/LIBPATH:/$USER/.rustup/toolchains/nightly-2023-02-28-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-msvc/lib" "/tmp/rustcAWOQqQ/libring-98a43d4a731d3bc1.rlib" "/$USER/Projets/XXX/RustHound/target/x86_64-pc-windows-msvc/release/deps/libcompiler_builtins-a57aa224b6747535.rlib" "windows.lib" "windows.lib" "iphlpapi.lib" "bcrypt.lib" "ntdll.lib" "windows.lib" "advapi32.lib" "cfgmgr32.lib" "credui.lib" "fwpuclnt.lib" "gdi32.lib" "kernel32.lib" "msimg32.lib" "ntdll.lib" "ole32.lib" "opengl32.lib" "runtimeobject.lib" "secur32.lib" "user32.lib" "winspool.lib" "ws2_32.lib" "kernel32.lib" "advapi32.lib" "userenv.lib" "kernel32.lib" "ws2_32.lib" "bcrypt.lib" "msvcrt.lib" "legacy_stdio_definitions.lib" "/NXCOMPAT" "/LIBPATH:/$USER/.rustup/toolchains/nightly-2023-02-28-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-msvc/lib" "/OUT:/$USER/Projets/XXX/RustHound/target/x86_64-pc-windows-msvc/release/deps/rusthound.exe" "/OPT:REF,ICF" "/DEBUG"
  = note: lld-link: error: undefined symbol: _$LT$T$u20$as$u20$core..convert..TryInto$LT$U$GT$$GT$::try_into::ha70d088502189c5c
          >>> referenced by libcompiler_builtins-a57aa224b6747535.rlib(compiler_builtins-a57aa224b6747535.compiler_builtins.08706f9d-cgu.3.rcgu.o):(_$LT$u8$u20$as$u20$compiler_builtins..int..Int$GT$::wrapping_shl::h75be24e30ae66717)
          >>> referenced by libcompiler_builtins-a57aa224b6747535.rlib(compiler_builtins-a57aa224b6747535.compiler_builtins.08706f9d-cgu.3.rcgu.o):(_$LT$u8$u20$as$u20$compiler_builtins..int..Int$GT$::logical_shr::h2923ea1dd2188a7b)
          
          lld-link: error: undefined symbol: _$LT$T$u20$as$u20$core..convert..TryInto$LT$U$GT$$GT$::try_into::h3facc516142b808f
          >>> referenced by libcompiler_builtins-a57aa224b6747535.rlib(compiler_builtins-a57aa224b6747535.compiler_builtins.08706f9d-cgu.3.rcgu.o):(_$LT$u16$u20$as$u20$compiler_builtins..int..Int$GT$::wrapping_shl::hc9f2c5447bea3c19)
          >>> referenced by libcompiler_builtins-a57aa224b6747535.rlib(compiler_builtins-a57aa224b6747535.compiler_builtins.08706f9d-cgu.3.rcgu.o):(_$LT$u16$u20$as$u20$compiler_builtins..int..Int$GT$::logical_shr::ha0c8059f27d2ee43)
          
          lld-link: error: undefined symbol: _$LT$T$u20$as$u20$core..convert..TryInto$LT$U$GT$$GT$::try_into::hc3c814c714409716
          >>> referenced by libcompiler_builtins-a57aa224b6747535.rlib(compiler_builtins-a57aa224b6747535.compiler_builtins.08706f9d-cgu.3.rcgu.o):(_$LT$u32$u20$as$u20$compiler_builtins..int..Int$GT$::wrapping_shl::h5da56a5404567510)
          >>> referenced by libcompiler_builtins-a57aa224b6747535.rlib(compiler_builtins-a57aa224b6747535.compiler_builtins.08706f9d-cgu.3.rcgu.o):(_$LT$u32$u20$as$u20$compiler_builtins..int..Int$GT$::logical_shr::he654838393c6dac6)
          >>> referenced by libcompiler_builtins-a57aa224b6747535.rlib(compiler_builtins-a57aa224b6747535.compiler_builtins.08706f9d-cgu.7.rcgu.o):(compiler_builtins::int::specialized_div_rem::u32_div_rem::hb22b2448b8f01ed2)
          

error: could not compile `rusthound` due to previous error

For RustScan (using nightly-2023-02-28):

Compile error

   Compiling rustscan v2.1.1 (/$USER/Projets/XXX/RustScan)
error: linking with `lld-link` failed: exit status: 1
  |
  = note: LC_ALL="C" PATH="/$USER/.rustup/toolchains/nightly-2023-02-28-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin:/$USER/.vscode-server/bin/441438abd1ac652551dbe4d408dfcec8a499b8bf/bin/remote-cli:/$USER/.local/bin:/$USER/.cargo/bin:/$USER/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/tmp" VSLANG="1033" "lld-link" "-flavor" "link" "/NOLOGO" "/tmp/rustcMAAVJR/symbols.o" "/$USER/Projets/XXX/RustScan/target/x86_64-pc-windows-msvc/release/deps/rustscan.rustscan.2fa56812-cgu.0.rcgu.o" "/LIBPATH:/$USER/Projets/XXX/RustScan/target/x86_64-pc-windows-msvc/release/deps" "/LIBPATH:/$USER/Projets/XXX/RustScan/target/release/deps" "/LIBPATH:/tmp/xwin_64/crt/lib/x86_64" "/LIBPATH:/tmp/xwin_64/sdk/lib/um/x86_64" "/LIBPATH:/tmp/xwin_64/sdk/lib/ucrt/x86_64" "/LIBPATH:/$USER/Projets/XXX/RustScan/target/x86_64-pc-windows-msvc/release/build/wepoll-ffi-719df429f6c384f7/out" "/LIBPATH:/$USER/.cargo/registry/src/github.com-1ecc6299db9ec823/windows_x86_64_msvc-0.42.0/lib" "/LIBPATH:/$USER/Projets/XXX/RustScan/target/x86_64-pc-windows-msvc/release/build/ring-a690ee922a6572a9/out" "/LIBPATH:/$USER/.rustup/toolchains/nightly-2023-02-28-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-msvc/lib" "/tmp/rustcMAAVJR/libring-188f86f2fd8f068a.rlib" "/tmp/rustcMAAVJR/libwepoll_ffi-48d31142813b117f.rlib" "/$USER/Projets/XXX/RustScan/target/x86_64-pc-windows-msvc/release/deps/libcompiler_builtins-18ed03317118022b.rlib" "iphlpapi.lib" "bcrypt.lib" "ntdll.lib" "windows.lib" "advapi32.lib" "advapi32.lib" "cfgmgr32.lib" "credui.lib" "fwpuclnt.lib" "gdi32.lib" "kernel32.lib" "msimg32.lib" "ntdll.lib" "ole32.lib" "opengl32.lib" "secur32.lib" "shell32.lib" "synchronization.lib" "user32.lib" "winspool.lib" "ws2_32.lib" "kernel32.lib" "advapi32.lib" "userenv.lib" "kernel32.lib" "ws2_32.lib" "bcrypt.lib" "msvcrt.lib" "legacy_stdio_definitions.lib" "/NXCOMPAT" "/LIBPATH:/$USER/.rustup/toolchains/nightly-2023-02-28-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-msvc/lib" "/OUT:/$USER/Projets/XXX/RustScan/target/x86_64-pc-windows-msvc/release/deps/rustscan.exe" "/OPT:REF,ICF" "/DEBUG"
  = note: lld-link: error: undefined symbol: _$LT$T$u20$as$u20$core..convert..TryInto$LT$U$GT$$GT$::try_into::hf83a56f591ad91c2
          >>> referenced by libcompiler_builtins-18ed03317118022b.rlib(compiler_builtins-18ed03317118022b.compiler_builtins.c902bbf6-cgu.3.rcgu.o):(_$LT$u8$u20$as$u20$compiler_builtins..int..Int$GT$::wrapping_shl::he7ed35977b0d0fac)
          >>> referenced by libcompiler_builtins-18ed03317118022b.rlib(compiler_builtins-18ed03317118022b.compiler_builtins.c902bbf6-cgu.3.rcgu.o):(_$LT$u8$u20$as$u20$compiler_builtins..int..Int$GT$::logical_shr::h00538ae7c426f37f)
          
          lld-link: error: undefined symbol: _$LT$T$u20$as$u20$core..convert..TryInto$LT$U$GT$$GT$::try_into::hae711d779ec4e591
          >>> referenced by libcompiler_builtins-18ed03317118022b.rlib(compiler_builtins-18ed03317118022b.compiler_builtins.c902bbf6-cgu.3.rcgu.o):(_$LT$u16$u20$as$u20$compiler_builtins..int..Int$GT$::wrapping_shl::h659e210b754e206f)
          >>> referenced by libcompiler_builtins-18ed03317118022b.rlib(compiler_builtins-18ed03317118022b.compiler_builtins.c902bbf6-cgu.3.rcgu.o):(_$LT$u16$u20$as$u20$compiler_builtins..int..Int$GT$::logical_shr::h970afb9c096c3a26)
          
          lld-link: error: undefined symbol: _$LT$T$u20$as$u20$core..convert..TryInto$LT$U$GT$$GT$::try_into::h183171ab1b2751dc
          >>> referenced by libcompiler_builtins-18ed03317118022b.rlib(compiler_builtins-18ed03317118022b.compiler_builtins.c902bbf6-cgu.3.rcgu.o):(_$LT$u32$u20$as$u20$compiler_builtins..int..Int$GT$::wrapping_shl::h6c6b22f19a38a7e4)
          >>> referenced by libcompiler_builtins-18ed03317118022b.rlib(compiler_builtins-18ed03317118022b.compiler_builtins.c902bbf6-cgu.3.rcgu.o):(_$LT$u32$u20$as$u20$compiler_builtins..int..Int$GT$::logical_shr::hb512d2478bac3150)
          >>> referenced by libcompiler_builtins-18ed03317118022b.rlib(compiler_builtins-18ed03317118022b.compiler_builtins.c902bbf6-cgu.7.rcgu.o):(compiler_builtins::int::specialized_div_rem::u32_div_rem::h4103159706e15559)
          

error: could not compile `rustscan` due to previous error

For Helix (using nightly-2023-02-28):

Compile error

   Compiling helix-tui v0.6.0 (/$USER/Projets/XXX/Helix/helix-tui)
error: linking with `lld-link` failed: exit status: 1
  |
  = note: LC_ALL="C" PATH="/$USER/.rustup/toolchains/nightly-2023-02-28-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin:/$USER/.vscode-server/bin/441438abd1ac652551dbe4d408dfcec8a499b8bf/bin/remote-cli:/$USER/.local/bin:/$USER/.cargo/bin:/$USER/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/tmp" VSLANG="1033" "lld-link" "-flavor" "link" "/NOLOGO" "/tmp/rustcIC5pT0/symbols.o" "/$USER/Projets/XXX/Helix/target/x86_64-pc-windows-msvc/release/deps/hx.hx.97f34d47-cgu.12.rcgu.o" "/LIBPATH:/$USER/Projets/XXX/Helix/target/x86_64-pc-windows-msvc/release/deps" "/LIBPATH:/$USER/Projets/XXX/Helix/target/release/deps" "/LIBPATH:/tmp/xwin_64/crt/lib/x86_64" "/LIBPATH:/tmp/xwin_64/sdk/lib/um/x86_64" "/LIBPATH:/tmp/xwin_64/sdk/lib/ucrt/x86_64" "/LIBPATH:/$USER/.cargo/registry/src/github.com-1ecc6299db9ec823/windows_x86_64_msvc-0.42.1/lib" "/LIBPATH:/$USER/Projets/XXX/Helix/target/x86_64-pc-windows-msvc/release/build/tree-sitter-2a9907837c51abd5/out" "/LIBPATH:/$USER/.rustup/toolchains/nightly-2023-02-28-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-msvc/lib" "/tmp/rustcIC5pT0/libtree_sitter-846e7dfbf9fccdfd.rlib" "/$USER/Projets/XXX/Helix/target/x86_64-pc-windows-msvc/release/deps/libcompiler_builtins-15b4049fca2c0d34.rlib" "windows.lib" "ntdll.lib" "legacy_stdio_definitions.lib" "windows.lib" "kernel32.lib" "advapi32.lib" "ole32.lib" "oleaut32.lib" "bcrypt.lib" "windows.lib" "advapi32.lib" "cfgmgr32.lib" "fwpuclnt.lib" "gdi32.lib" "kernel32.lib" "msimg32.lib" "ntdll.lib" "ole32.lib" "opengl32.lib" "runtimeobject.lib" "shell32.lib" "shlwapi.lib" "synchronization.lib" "user32.lib" "winspool.lib" "ws2_32.lib" "kernel32.lib" "advapi32.lib" "userenv.lib" "kernel32.lib" "ws2_32.lib" "bcrypt.lib" "msvcrt.lib" "legacy_stdio_definitions.lib" "/NXCOMPAT" "/LIBPATH:/$USER/.rustup/toolchains/nightly-2023-02-28-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-msvc/lib" "/OUT:/$USER/Projets/XXX/Helix/target/x86_64-pc-windows-msvc/release/deps/hx.exe" "/OPT:REF,ICF" "/DEBUG"
  = note: lld-link: error: undefined symbol: _$LT$T$u20$as$u20$core..convert..TryInto$LT$U$GT$$GT$::try_into::hc27fcf92225fa76d
          >>> referenced by libcompiler_builtins-15b4049fca2c0d34.rlib(compiler_builtins-15b4049fca2c0d34.compiler_builtins.b4f7fc22-cgu.3.rcgu.o):(_$LT$u8$u20$as$u20$compiler_builtins..int..Int$GT$::wrapping_shl::hde1da1a440758e53)
          >>> referenced by libcompiler_builtins-15b4049fca2c0d34.rlib(compiler_builtins-15b4049fca2c0d34.compiler_builtins.b4f7fc22-cgu.3.rcgu.o):(_$LT$u8$u20$as$u20$compiler_builtins..int..Int$GT$::logical_shr::h69f3e9a4cec906c3)
          
          lld-link: error: undefined symbol: _$LT$T$u20$as$u20$core..convert..TryInto$LT$U$GT$$GT$::try_into::hc09440a623908dd2
          >>> referenced by libcompiler_builtins-15b4049fca2c0d34.rlib(compiler_builtins-15b4049fca2c0d34.compiler_builtins.b4f7fc22-cgu.3.rcgu.o):(_$LT$u16$u20$as$u20$compiler_builtins..int..Int$GT$::wrapping_shl::h8fa431404ce61bc8)
          >>> referenced by libcompiler_builtins-15b4049fca2c0d34.rlib(compiler_builtins-15b4049fca2c0d34.compiler_builtins.b4f7fc22-cgu.3.rcgu.o):(_$LT$u16$u20$as$u20$compiler_builtins..int..Int$GT$::logical_shr::h66ae3ce6d28d7dc9)
          
          lld-link: error: undefined symbol: _$LT$T$u20$as$u20$core..convert..TryInto$LT$U$GT$$GT$::try_into::hcee917ca27ced0ac
          >>> referenced by libcompiler_builtins-15b4049fca2c0d34.rlib(compiler_builtins-15b4049fca2c0d34.compiler_builtins.b4f7fc22-cgu.3.rcgu.o):(_$LT$u32$u20$as$u20$compiler_builtins..int..Int$GT$::wrapping_shl::h51b6ed721278058c)
          >>> referenced by libcompiler_builtins-15b4049fca2c0d34.rlib(compiler_builtins-15b4049fca2c0d34.compiler_builtins.b4f7fc22-cgu.3.rcgu.o):(_$LT$u32$u20$as$u20$compiler_builtins..int..Int$GT$::logical_shr::h337b670af4036651)
          >>> referenced by libcompiler_builtins-15b4049fca2c0d34.rlib(compiler_builtins-15b4049fca2c0d34.compiler_builtins.b4f7fc22-cgu.7.rcgu.o):(compiler_builtins::int::specialized_div_rem::u32_div_rem::hc40953c0c14b372c)
          

error: could not compile `helix-term` due to previous error

Please note that I used windows cross compilation builds as an example, but same thing can happen with other targets (even when not cross-compiling). Also note that the linking errors can be different regarding the selected target.

After some more tests with Linux (and checking this issue), I found that we need to add -C panic=abort to overpass another linking issue (cf. #107016 (comment)). This doesn't resolve the issue for Windows cross-compilation however.

@dbachelot dbachelot added the C-bug Category: This is a bug. label Mar 7, 2023
@tmiasko
Copy link
Contributor

tmiasko commented Mar 7, 2023

A few things you could try:

  1. Use -Csymbol-mangling-version=v0 (for more informative symbol names, not because it will fix the issue in itself).
  2. Build with -Ccodegen-units=1
  3. Add #[inline] annotation to the following function in the core (and then clean & rebuild)
    fn try_from(value: U) -> Result<Self, Self::Error> {
    Ok(U::into(value))
    }

If the last suggestion helps, please mention this in rust-lang/compiler-builtins#491.

@dbachelot
Copy link
Author

dbachelot commented Mar 7, 2023

I tested 1&2 and got:

Compile error

   Compiling rustscan v2.1.1 (/home/$USER/Projets/XXX/RustScan)
error: linking with `lld-link` failed: exit status: 1
  |
  = note: LC_ALL="C" PATH="/home/$USER/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin:/home/$USER/.vscode-server/bin/441438abd1ac652551dbe4d408dfcec8a499b8bf/bin/remote-cli:/home/$USER/.local/bin:/home/$USER/.cargo/bin:/home/$USER/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/tmp" VSLANG="1033" "lld-link" "-flavor" "link" "/NOLOGO" "/tmp/rustc3sx4fq/symbols.o" "/home/$USER/Projets/XXX/RustScan/target/x86_64-pc-windows-msvc/release/deps/rustscan.rustscan.73ae6a84-cgu.0.rcgu.o" "/LIBPATH:/home/$USER/Projets/XXX/RustScan/target/x86_64-pc-windows-msvc/release/deps" "/LIBPATH:/home/$USER/Projets/XXX/RustScan/target/release/deps" "/LIBPATH:/tmp/xwin_64/crt/lib/x86_64" "/LIBPATH:/tmp/xwin_64/sdk/lib/um/x86_64" "/LIBPATH:/tmp/xwin_64/sdk/lib/ucrt/x86_64" "/LIBPATH:/home/$USER/Projets/XXX/RustScan/target/x86_64-pc-windows-msvc/release/build/wepoll-ffi-719df429f6c384f7/out" "/LIBPATH:/home/$USER/.cargo/registry/src/github.com-1ecc6299db9ec823/windows_x86_64_msvc-0.42.0/lib" "/LIBPATH:/home/$USER/Projets/XXX/RustScan/target/x86_64-pc-windows-msvc/release/build/ring-a690ee922a6572a9/out" "/LIBPATH:/home/$USER/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-msvc/lib" "/tmp/rustc3sx4fq/libring-7aca1892b1101c44.rlib" "/tmp/rustc3sx4fq/libwepoll_ffi-b138a1eba95895ba.rlib" "/home/$USER/Projets/XXX/RustScan/target/x86_64-pc-windows-msvc/release/deps/libcompiler_builtins-83400d04a98abbd8.rlib" "iphlpapi.lib" "bcrypt.lib" "ntdll.lib" "windows.lib" "advapi32.lib" "advapi32.lib" "cfgmgr32.lib" "credui.lib" "fwpuclnt.lib" "gdi32.lib" "kernel32.lib" "msimg32.lib" "ntdll.lib" "ole32.lib" "opengl32.lib" "secur32.lib" "shell32.lib" "synchronization.lib" "user32.lib" "winspool.lib" "ws2_32.lib" "kernel32.lib" "advapi32.lib" "userenv.lib" "kernel32.lib" "ws2_32.lib" "bcrypt.lib" "msvcrt.lib" "legacy_stdio_definitions.lib" "/NXCOMPAT" "/LIBPATH:/home/$USER/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-msvc/lib" "/OUT:/home/$USER/Projets/XXX/RustScan/target/x86_64-pc-windows-msvc/release/deps/rustscan.exe" "/OPT:REF,ICF" "/DEBUG"
  = note: lld-link: error: undefined symbol: <u32 as core::convert::TryInto<u32>>::try_into
          >>> referenced by libcompiler_builtins-83400d04a98abbd8.rlib(compiler_builtins-83400d04a98abbd8.compiler_builtins.2da580f8-cgu.0.rcgu.o):(compiler_builtins::int::specialized_div_rem::u32_div_rem)
          >>> referenced by libcompiler_builtins-83400d04a98abbd8.rlib(compiler_builtins-83400d04a98abbd8.compiler_builtins.2da580f8-cgu.0.rcgu.o):(<i32 as compiler_builtins::int::Int>::logical_shr)
          >>> referenced by libcompiler_builtins-83400d04a98abbd8.rlib(compiler_builtins-83400d04a98abbd8.compiler_builtins.2da580f8-cgu.0.rcgu.o):(<u32 as compiler_builtins::int::Int>::wrapping_shl)
          
          lld-link: error: undefined symbol: <u32 as core::convert::TryInto<u8>>::try_into
          >>> referenced by libcompiler_builtins-83400d04a98abbd8.rlib(compiler_builtins-83400d04a98abbd8.compiler_builtins.2da580f8-cgu.0.rcgu.o):(<i8 as compiler_builtins::int::Int>::logical_shr)
          >>> referenced by libcompiler_builtins-83400d04a98abbd8.rlib(compiler_builtins-83400d04a98abbd8.compiler_builtins.2da580f8-cgu.0.rcgu.o):(<u8 as compiler_builtins::int::Int>::wrapping_shl)
          
          lld-link: error: undefined symbol: <u32 as core::convert::TryInto<u16>>::try_into
          >>> referenced by libcompiler_builtins-83400d04a98abbd8.rlib(compiler_builtins-83400d04a98abbd8.compiler_builtins.2da580f8-cgu.0.rcgu.o):(<i16 as compiler_builtins::int::Int>::logical_shr)
          >>> referenced by libcompiler_builtins-83400d04a98abbd8.rlib(compiler_builtins-83400d04a98abbd8.compiler_builtins.2da580f8-cgu.0.rcgu.o):(<u16 as compiler_builtins::int::Int>::wrapping_shl)
          

error: could not compile `rustscan` due to previous error

(PS: I'm currently testing 3)

@dbachelot
Copy link
Author

Adding #[inline] on the try_from implementation in core doesn't seem to change anything.

@tmiasko
Copy link
Contributor

tmiasko commented Mar 7, 2023

One more suggestion: ensure that -Zshare-generics=off is used when building compiler-builtins (-C opt-level=z implies -Zshare-generics=on, which looks like the root cause of the problem here):

cargo-features = ["profile-rustflags"]

[profile.release.package.compiler_builtins]
rustflags = ["-Zshare-generics=off"]

(Update the profile name as appropriate).

@dbachelot
Copy link
Author

Thank you, this fix the issue! Is this considered a regression or can we close the issue?

@pnkfelix
Copy link
Member

pnkfelix commented Mar 7, 2023

The fact that we need to use a -Z flag to work around the problem implies that we cannot close the issue. -Z flags aren't available to stable Rust users.

@pnkfelix pnkfelix added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. I-prioritize Issue: Indicates that prioritization has been requested for this issue. labels Mar 7, 2023
@estebank estebank added regression-untriaged Untriaged performance or correctness regression. and removed I-prioritize Issue: Indicates that prioritization has been requested for this issue. labels Mar 7, 2023
@rustbot rustbot added the I-prioritize Issue: Indicates that prioritization has been requested for this issue. label Mar 7, 2023
@estebank estebank removed the regression-untriaged Untriaged performance or correctness regression. label Mar 7, 2023
@pnkfelix
Copy link
Member

pnkfelix commented Mar 7, 2023

Is there a variant of this that demonstrates the problem described here without using any -Z flags at all?

@pnkfelix pnkfelix added the regression-untriaged Untriaged performance or correctness regression. label Mar 7, 2023
@pnkfelix
Copy link
Member

pnkfelix commented Mar 7, 2023

(if we can gain confidence that this always requires some -Z flag to be observed, then we can remove the regression labels. But I'm not confident right now; I don't think -C opt-level=z gets a terrible amount of testing in our CI....)

@saethlin
Copy link
Member

saethlin commented Mar 7, 2023

FWIW, I see opt=level = "z" used a shocking amount among embedded developers (and by that I mean it seems like every single time someone links me an embedded Rust project they have set this option), and I also hear a lot of grousing from people like @thomcc about unnecessarily poor optimizations under that setting.

So even setting the present issue aside, it seems to me like we have a mismatch in the amount of use versus the amount of care or investment that's put into this behavior of this option.

@thomcc
Copy link
Member

thomcc commented Mar 7, 2023

Yeah, even aside from embedded, I can only speak personally, but a very large number of the Rust projects I've worked on professionally (most of which are not embedded) compile with s or z, to help mitigate the size of compiled Rust code1.

Either way, it would be good to test them in CI, although I can imagine that doing so might be painful.

Footnotes

  1. Sadly, this sometimes causes the size to be larger than with "3"... since idiomatic Rust code heavily relies on inlining, which those opt levels avoid 😔... This is very off-topic though.

@dbachelot
Copy link
Author

Is there a variant of this that demonstrates the problem described here without using any -Z flags at all?

From what I tested this issue is (only) triggered by -Z build-std=std,panic_abort -Z build-std-features=panic_immediate_abort since this will build compiler_builtins, core and std with provided optimizations. When used with opt-level=z this will enable share-generics by default and since compiler_builtins need to have it off to avoid linking issues with lto this trigger the compile error (maybe linked to rust-lang/compiler-builtins#491). So yeah, I think this problem will only happen when using -Z flags.

However please note that these flags are used by a lot of projects (even ones targeting stable) to make size-optimized builds (cf. https://github.com/johnthagen/min-sized-rust).

@apiraino
Copy link
Contributor

apiraino commented Mar 8, 2023

WG-prioritization assigning priority (Zulip discussion).

I wonder if a smaller reproducible can help (seems the topic of opt. flags is somewhat wide), tentatively setting that label either.

@rustbot label -I-prioritize +P-high +E-needs-mcve

@rustbot rustbot added E-needs-mcve Call for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example P-high High priority and removed I-prioritize Issue: Indicates that prioritization has been requested for this issue. labels Mar 8, 2023
@saethlin
Copy link
Member

saethlin commented Mar 8, 2023

I'm pretty sure the problem is that you are trying to use the unwinding panic runtime with panic_immediate_abort. If you pass -Cpanic=abort, things should work.

I believe this is exactly the same issue as #107016

I do not really know why unwinding panics with panic_immediate_abort ever compiled. And in any case, if you're looking for a minimally-sized artifact, you should compile with aborting panics.

@dbachelot
Copy link
Author

I'm pretty sure the problem is that you are trying to use the unwinding panic runtime with panic_immediate_abort. If you pass -Cpanic=abort, things should work.

I believe this is exactly the same issue as #107016

I do not really know why unwinding panics with panic_immediate_abort ever compiled. And in any case, if you're looking for a minimally-sized artifact, you should compile with aborting panics.

As pointed out in my initial post, I removed -C panic=abort to minimize flags to a minimum, but this issue also appears when using it and cross-compiling (as discussed in the last part of my initial message). However, since I agree that it should not compile without it (another issue #107016) and that this can confuse people, I edited my message and added it

tldr; this doesn't fix the issue

@saethlin
Copy link
Member

saethlin commented Mar 8, 2023

Interesting. I can get linker errors when compiling RustHound and helix without -Cpanic=abort, but with the flag, they link just fine. RustScan always seems to build.

(I'm only testing with nightly-2023-02-28)

@dbachelot
Copy link
Author

Interesting. I can get linker errors when compiling RustHound and helix without -Cpanic=abort, but with the flag, they link just fine. RustScan always seems to build.

(I'm only testing with nightly-2023-02-28)

Do you have the exact compile line used? It's important to note that this seems to only happen when cross-compiling. For example, let's take RustScan:

Building for i686-unknown-linux-gnu:

Compile error

Compiling rustscan v2.1.1 (/home/$USER/Projets/XXX/RustScan)
error: linking with `cc` failed: exit status: 1
  |
  = note: LC_ALL="C" PATH="/home/$USER/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin:/home/$USER/.vscode-server/bin/441438abd1ac652551dbe4d408dfcec8a499b8bf/bin/remote-cli:/home/$USER/.local/bin:/home/$USER/.cargo/bin:/home/$USER/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin" VSLANG="1033" "cc" "-m32" "/tmp/rustcxtfFc3/symbols.o" "/home/$USER/Projets/XXX/RustScan/target/i686-unknown-linux-gnu/release/deps/rustscan-8069d2dff506ca4d.rustscan.a822f4a7-cgu.0.rcgu.o" "-Wl,--as-needed" "-L" "/home/$USER/Projets/XXX/RustScan/target/i686-unknown-linux-gnu/release/deps" "-L" "/home/$USER/Projets/XXX/RustScan/target/release/deps" "-L" "/home/$USER/Projets/XXX/RustScan/target/i686-unknown-linux-gnu/release/build/ring-b1a3c9ae3ccb6cc9/out" "-L" "/home/$USER/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/i686-unknown-linux-gnu/lib" "-Wl,-Bstatic" "/tmp/rustcxtfFc3/libring-a85cb11ce5dd843d.rlib" "/home/$USER/Projets/XXX/RustScan/target/i686-unknown-linux-gnu/release/deps/libcompiler_builtins-e8354e5232d2c05a.rlib" "-Wl,-Bdynamic" "-lgcc_s" "-lutil" "-lrt" "-lpthread" "-lm" "-ldl" "-lc" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack" "-L" "/home/$USER/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/i686-unknown-linux-gnu/lib" "-o" "/home/$USER/Projets/XXX/RustScan/target/i686-unknown-linux-gnu/release/deps/rustscan-8069d2dff506ca4d" "-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now" "-nodefaultlibs"
  = note: /usr/bin/ld: /home/$USER/Projets/XXX/RustScan/target/i686-unknown-linux-gnu/release/deps/libcompiler_builtins-e8354e5232d2c05a.rlib(compiler_builtins-e8354e5232d2c05a.compiler_builtins.e77cb671-cgu.0.rcgu.o): in function `<u32 as compiler_builtins::int::Int>::logical_shr':
          compiler_builtins.e77cb671-cgu.0:(.text._RNvXs4_NtCsg8UtXzRGVrx_17compiler_builtins3intmNtB5_3Int11logical_shr+0x1e): undefined reference to `<u32 as core::convert::TryInto<u32>>::try_into'
          /usr/bin/ld: /home/$USER/Projets/XXX/RustScan/target/i686-unknown-linux-gnu/release/deps/libcompiler_builtins-e8354e5232d2c05a.rlib(compiler_builtins-e8354e5232d2c05a.compiler_builtins.e77cb671-cgu.0.rcgu.o): in function `<u32 as compiler_builtins::int::Int>::wrapping_shl':
          compiler_builtins.e77cb671-cgu.0:(.text._RNvXs4_NtCsg8UtXzRGVrx_17compiler_builtins3intmNtB5_3Int12wrapping_shl+0x1e): undefined reference to `<u32 as core::convert::TryInto<u32>>::try_into'
          collect2: error: ld returned 1 exit status
          
  = note: some `extern` functions couldn't be found; some native libraries may need to be installed or have their path specified
  = note: use the `-l` flag to specify native libraries to link
  = note: use the `cargo:rustc-link-lib` directive to specify the native libraries to link with Cargo (see https://doc.rust-lang.org/cargo/reference/build-scripts.html#cargorustc-link-libkindname)

error: could not compile `rustscan` due to previous error

Building for x86_64-pc-windows-msvc:

Compile error

   Compiling rustscan v2.1.1 (/home/$USER/Projets/XXX/RustScan)
error: linking with `lld-link` failed: exit status: 1
  |
  = note: LC_ALL="C" PATH="/home/$USER/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin:/home/$USER/.vscode-server/bin/441438abd1ac652551dbe4d408dfcec8a499b8bf/bin/remote-cli:/home/$USER/.local/bin:/home/$USER/.cargo/bin:/home/$USER/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/tmp" VSLANG="1033" "lld-link" "-flavor" "link" "/NOLOGO" "/tmp/rustcAlAIfz/symbols.o" "/home/$USER/Projets/XXX/RustScan/target/x86_64-pc-windows-msvc/release/deps/rustscan.rustscan.73ae6a84-cgu.0.rcgu.o" "/LIBPATH:/home/$USER/Projets/XXX/RustScan/target/x86_64-pc-windows-msvc/release/deps" "/LIBPATH:/home/$USER/Projets/XXX/RustScan/target/release/deps" "/LIBPATH:/tmp/xwin_64/crt/lib/x86_64" "/LIBPATH:/tmp/xwin_64/sdk/lib/um/x86_64" "/LIBPATH:/tmp/xwin_64/sdk/lib/ucrt/x86_64" "/LIBPATH:/home/$USER/Projets/XXX/RustScan/target/x86_64-pc-windows-msvc/release/build/wepoll-ffi-719df429f6c384f7/out" "/LIBPATH:/home/$USER/.cargo/registry/src/github.com-1ecc6299db9ec823/windows_x86_64_msvc-0.42.0/lib" "/LIBPATH:/home/$USER/Projets/XXX/RustScan/target/x86_64-pc-windows-msvc/release/build/ring-a690ee922a6572a9/out" "/LIBPATH:/home/$USER/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-msvc/lib" "/tmp/rustcAlAIfz/libring-7aca1892b1101c44.rlib" "/tmp/rustcAlAIfz/libwepoll_ffi-b138a1eba95895ba.rlib" "/home/$USER/Projets/XXX/RustScan/target/x86_64-pc-windows-msvc/release/deps/libcompiler_builtins-83400d04a98abbd8.rlib" "iphlpapi.lib" "bcrypt.lib" "ntdll.lib" "windows.lib" "advapi32.lib" "advapi32.lib" "cfgmgr32.lib" "credui.lib" "fwpuclnt.lib" "gdi32.lib" "kernel32.lib" "msimg32.lib" "ntdll.lib" "ole32.lib" "opengl32.lib" "secur32.lib" "shell32.lib" "synchronization.lib" "user32.lib" "winspool.lib" "ws2_32.lib" "kernel32.lib" "advapi32.lib" "userenv.lib" "kernel32.lib" "ws2_32.lib" "bcrypt.lib" "msvcrt.lib" "legacy_stdio_definitions.lib" "/NXCOMPAT" "/LIBPATH:/home/$USER/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-msvc/lib" "/OUT:/home/$USER/Projets/XXX/RustScan/target/x86_64-pc-windows-msvc/release/deps/rustscan.exe" "/OPT:REF,ICF" "/DEBUG"
  = note: lld-link: error: undefined symbol: <u32 as core::convert::TryInto<u32>>::try_into
          >>> referenced by libcompiler_builtins-83400d04a98abbd8.rlib(compiler_builtins-83400d04a98abbd8.compiler_builtins.2da580f8-cgu.0.rcgu.o):(compiler_builtins::int::specialized_div_rem::u32_div_rem)
          >>> referenced by libcompiler_builtins-83400d04a98abbd8.rlib(compiler_builtins-83400d04a98abbd8.compiler_builtins.2da580f8-cgu.0.rcgu.o):(<i32 as compiler_builtins::int::Int>::logical_shr)
          >>> referenced by libcompiler_builtins-83400d04a98abbd8.rlib(compiler_builtins-83400d04a98abbd8.compiler_builtins.2da580f8-cgu.0.rcgu.o):(<u32 as compiler_builtins::int::Int>::wrapping_shl)
          
          lld-link: error: undefined symbol: <u32 as core::convert::TryInto<u8>>::try_into
          >>> referenced by libcompiler_builtins-83400d04a98abbd8.rlib(compiler_builtins-83400d04a98abbd8.compiler_builtins.2da580f8-cgu.0.rcgu.o):(<i8 as compiler_builtins::int::Int>::logical_shr)
          >>> referenced by libcompiler_builtins-83400d04a98abbd8.rlib(compiler_builtins-83400d04a98abbd8.compiler_builtins.2da580f8-cgu.0.rcgu.o):(<u8 as compiler_builtins::int::Int>::wrapping_shl)
          
          lld-link: error: undefined symbol: <u32 as core::convert::TryInto<u16>>::try_into
          >>> referenced by libcompiler_builtins-83400d04a98abbd8.rlib(compiler_builtins-83400d04a98abbd8.compiler_builtins.2da580f8-cgu.0.rcgu.o):(<i16 as compiler_builtins::int::Int>::logical_shr)
          >>> referenced by libcompiler_builtins-83400d04a98abbd8.rlib(compiler_builtins-83400d04a98abbd8.compiler_builtins.2da580f8-cgu.0.rcgu.o):(<u16 as compiler_builtins::int::Int>::wrapping_shl)
          

error: could not compile `rustscan` due to previous error

I used those flags for compilation:

OPTI_FLAGS="-C link-dead-code=n -C lto=fat -C opt-level=z -C embed-bitcode=yes -C panic=abort -C symbol-mangling-version=v0 -C codegen-units=1"
OPTI_ARGS="-Z build-std=core,std,panic_abort -Z build-std-features=panic_immediate_abort"

Please also note that I confirm this worked prior to nightly-2023-02-28. Furthermore, we can see in #108893 the same issue which isn't about the -C panic=abort + panic_immediate_abort use case, but is more about cross compiling for embedded development. The common points among these cases are -Z build-std=std and share-generics (regarding compiler_builtins as pointed out by @tmiasko).

@apiraino apiraino added regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. and removed regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. labels Mar 9, 2023
yvt added a commit to r3-os/r3 that referenced this issue Mar 18, 2023
Work-around for [rust-lang/rust#108853][1] suggested [here][2]. Fixes
undefined symbol errors in the `report-size` CI workflow.

[1]: rust-lang/rust#108853
[2]: rust-lang/rust#108853 (comment)
corwinkuiper added a commit to corwinkuiper/agb-fork that referenced this issue Mar 23, 2023
corwinkuiper added a commit to agbrs/agb that referenced this issue Mar 23, 2023
This works around rust-lang/rust#108853 by using an `opt-level` of `3`
rather than `s`.

- [x] Changelog updated / no changelog update needed
@cr1901
Copy link
Contributor

cr1901 commented Mar 26, 2023

One more suggestion: ensure that -Zshare-generics=off is used when building compiler-builtins (-C opt-level=z implies -Zshare-generics=on, which looks like the root cause of the problem here):

cargo-features = ["profile-rustflags"]

[profile.release.package.compiler_builtins]
rustflags = ["-Zshare-generics=off"]

(Update the profile name as appropriate).

FWIW this does not work for me; maybe b/c I'm part of a workspace, when I put this at the top-level Cargo.toml, I get "warning: profile package spec compiler_builtins in profile release did not match any packages". On the other hand, the solution here, enabling rustflags = ["-Zshare-generics=off"] unconditionally does work.

This issue is essentially a showstopper bug for my msp430 work, so even a working unstable solution to reenable LTO like above will unblock me. If I have time, I'll do my own bisection; for some reason I'm unable to duplicate this bug on Linux on the same codebase with a nightly that's a week or two behind Windows.

@dbachelot
Copy link
Author

dbachelot commented Mar 27, 2023

Hi, here some precision about the workarounds:

  • The first workaround will disallow 'share-generics' (which is an optimization, see this) for all crates in your compilation tree: rustflags = ["-Zshare-generics=off"]. Since we want to disable the latter option when compiling compiler_builtins, this overpass the issue.
  • A better approach, however, allows us to just disable share-generics when compiling compiler_builtins. To do that we need to tell rustc to only pass a certain flag during compilation of the targeted crate. Here we are configuring cargo so we can't use the package manifest (the Cargo.toml file in the root folder of each package) and need to use the .cargo/config.toml file. Here, you can tell cargo to pass rustflags = ["-Zshare-generics=off"] only for the compiler_builtins package:
[unstable]
profile-rustflags = true

[profile.release.package.compiler_builtins]
rustflags = ["-Zshare-generics=off"]

Even if you use a workspace, you need to place this file in the root folder (more info here).

If you don't want to edit any file, for both solutions you can pass these options using the command line:

  • For the first workaround: cargo +nightly b -Zshare-generics=off [...]
  • And for the second: cargo +nightly b --config unstable.profile-rustflags=true --config profile.release.package.compiler_builtins.rustflags=['-Zshare-generics=off'] [...]

@cr1901
Copy link
Contributor

cr1901 commented Mar 27, 2023

Okay, so the reason I got confused is: if Cargo.toml doesn't work at all, even from your workspace root, your .cargo/config.toml file needs to look something like this:

[profile.examples-fix]
inherits = "examples"

[profile.examples-fix.package.compiler_builtins]
rustflags = ["-Zshare-generics=off"]

[unstable]
profile-rustflags = true

AFAICT, cargo-features = ["profile-rustflags"] is Cargo.toml only.

The example profile looks like this:

[profile.examples]
inherits = "release"
lto = "fat"
opt-level = "s"
codegen-units = 1

Adding a separate profile in config.toml allows me to use the stable compiler without getting a nice "you're using an unstable feature in stable" error, only going to nightly for targets where I'm using build-std explicitly. This is an alternate take on your command-line solution, but I like yours better. So I'll go ahead and steal yours and just leave this comment for completeness :).

@cr1901
Copy link
Contributor

cr1901 commented Mar 31, 2023

So strangely, best we can work out, is that it all started failing in 6cb3449 which doesn't make any sense to us. But the commit before succeeds to build and this commit fails.

I did my own bisect tonight on my own codebase, thinking it was incredibly weird that this specific commit broke LTO.

But alas, I can confirm from my bisection that this is the exact commit where everything broke. I can't help but wonder if this is an LLVM bug in disguise, and this commit simply triggered an existing bug. But it's late right now, so I'll have to test that theory later.

@pnkfelix pnkfelix added the A-linkage Area: linking into static, shared libraries and binaries label Jul 13, 2023
bors added a commit to rust-lang-ci/rust that referenced this issue Sep 14, 2023
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`
bors added a commit to rust-lang-ci/rust that referenced this issue Oct 12, 2023
…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`
bors added a commit to rust-lang-ci/rust that referenced this issue Oct 17, 2023
…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`
bors added a commit to rust-lang-ci/rust that referenced this issue Oct 26, 2023
…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`
bors added a commit to rust-lang-ci/rust that referenced this issue Oct 27, 2023
…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`
bors added a commit to rust-lang-ci/rust that referenced this issue Oct 28, 2023
…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`
bors added a commit to rust-lang-ci/rust that referenced this issue Nov 14, 2023
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`
bors added a commit to rust-lang-ci/rust that referenced this issue Nov 16, 2023
…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`
bors added a commit to rust-lang-ci/rust that referenced this issue Nov 16, 2023
…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`
@wesleywiser
Copy link
Member

@tmiasko applied a work around to resolve this particular issue in PR #109983

bors added a commit to rust-lang-ci/rust that referenced this issue Nov 30, 2023
…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`
bors added a commit to rust-lang-ci/rust that referenced this issue Dec 1, 2023
…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`
@bors bors closed this as completed in 8c2b577 Dec 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
-Zbuild-std Unstable Cargo option: Compile the standard library yourself. A-linkage Area: linking into static, shared libraries and binaries C-bug Category: This is a bug. E-needs-mcve Call for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example P-high High priority regression-untriaged Untriaged performance or correctness regression. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet