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

rustc is now dynamically linked to zlib #74420

Open
Mark-Simulacrum opened this issue Jul 16, 2020 · 13 comments
Open

rustc is now dynamically linked to zlib #74420

Mark-Simulacrum opened this issue Jul 16, 2020 · 13 comments
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. regression-from-stable-to-stable Performance or correctness regression from one stable version to another. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-release Relevant to the release subteam, which will review and decide on the PR/issue.
Milestone

Comments

@Mark-Simulacrum
Copy link
Member

Mark-Simulacrum commented Jul 16, 2020

Discovered in #74395, the current beta links to libz dynamically (through LLVM).

This is new, and is perhaps something we don't want. On the other hand, zlib is pretty ubiquitous so it may be fine to leave it as is. I would like to see us add tests that the set of dynamically linked libraries is stable so we're at least aware of this happening (it slipped into rustc this time in #72696 without that being noticed by the primary reviewer of that PR).

Separately, we should decide if zlib is sufficiently common that it's fine to dynamically link to it.

/home/mark/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/rustc:
        linux-vdso.so.1 (0x00007ffeec130000)
        librustc_driver-a07dcbb4ed0bdde8.so => /home/mark/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-a07dcbb4ed0bdde8.so (0x00007f858d5f7000)
        libstd-c147cd9c030850ef.so => /home/mark/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/../lib/libstd-c147cd9c030850ef.so (0x00007f858d2f6000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f858d2ca000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f858d2c4000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f858d2b9000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f858d0c7000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f8591b6a000)
        libLLVM-10-rust-1.45.0-stable.so => /home/mark/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM-10-rust-1.45.0-stable.so (0x00007f8588aca000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f8588aaf000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f8588960000)
/home/mark/.rustup/toolchains/beta-x86_64-unknown-linux-gnu/bin/rustc:
        linux-vdso.so.1 (0x00007ffd5ddb6000)
        librustc_driver-e231ac240cfaf689.so => /home/mark/.rustup/toolchains/beta-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-e231ac240cfaf689.so (0x00007f4a387a4000)
        libstd-d66e0ceb8eaec9b8.so => /home/mark/.rustup/toolchains/beta-x86_64-unknown-linux-gnu/bin/../lib/libstd-d66e0ceb8eaec9b8.so (0x00007f4a384a1000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f4a38475000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4a3846f000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f4a38464000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4a38272000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f4a3cdd2000)
        libLLVM-10-rust-1.46.0-beta.so => /home/mark/.rustup/toolchains/beta-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM-10-rust-1.46.0-beta.so (0x00007f4a33c07000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f4a33bec000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f4a33a9d000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f4a33a81000)
@Mark-Simulacrum Mark-Simulacrum added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. regression-from-stable-to-beta Performance or correctness regression from stable to beta. T-release Relevant to the release subteam, which will review and decide on the PR/issue. labels Jul 16, 2020
@Mark-Simulacrum Mark-Simulacrum added this to the 1.46 milestone Jul 16, 2020
@cuviper cuviper modified the milestones: 1.46, 1.45 Jul 16, 2020
@jethrogb
Copy link
Contributor

I certainly expect libz to be available on Linux and BSDs, so I don't think it's a problem there. What happens on Windows/MacOS?

@retep998
Copy link
Member

On the latest x86_64-pc-windows-msvc nightly I do not see any zlib runtime dependencies in rust-lld.exe nor rustc.exe.

@eddyb
Copy link
Member

eddyb commented Jul 17, 2020

This would be fine on NixOS but the Python wrapper around src/bootstrap needs to be updated. Working on that now.

EDIT: opened #74441 for the NixOS fix.

@mati865
Copy link
Contributor

mati865 commented Jul 17, 2020

On x86_64-pc-windows-gnu zlib somehow got linked statically.

@mati865

This comment has been minimized.

@rustbot rustbot self-assigned this Jul 17, 2020
@jethrogb
Copy link
Contributor

@mati865 what are you claiming exactly? I feel like more discussion is needed to decide what to do.

@mati865
Copy link
Contributor

mati865 commented Jul 17, 2020

I believe I know how to link zlib statically. From discussion in #74395 this seem like correct approach.

@mati865
Copy link
Contributor

mati865 commented Jul 17, 2020

I'll be away for few hours so I decided to post my findings in case somebody else wants to work on it.

MSVC builds probably don't have zlib linked at all since LLVM will ignore LLVM_ENABLE_ZLIB if zlib is not available in the system. Windows-gnu links LLVM and zlib statically.

Linux builds of Rust have ThinLTO enabled and that makes them link to LLVM dynamically:

if builder.config.llvm_link_shared || builder.config.llvm_thin_lto {
cargo.env("LLVM_LINK_SHARED", "1");
}

To avoid zlib dependency here we have to patch LLVM's CMake files. Do we want to do it?

@shepmaster
Copy link
Member

In working on cross-compiling rustc from x86_64-apple-darwin to aarch64-apple-darwin, I ran into what I think is the same root problem. In my case, I had to forcibly add -lz to the linker arguments in order to get a successful build.

I think that enabling a static build of zlib would help with this, and I'd be happy to help test any proposed solutions.

@mati865
Copy link
Contributor

mati865 commented Jul 17, 2020

@shepmaster your issue is a bit different. See here and the discussion in PR from the comment:

if !target.contains("netbsd") {
cfg.define("LLVM_ENABLE_ZLIB", "ON");
} else {
// FIXME: Enable zlib on NetBSD too
// https://github.com/rust-lang/rust/pull/72696#issuecomment-641517185
cfg.define("LLVM_ENABLE_ZLIB", "OFF");
}

I think that enabling a static build of zlib would help with this

While it cannot be called proper fix for your issue linking zlib statically will make work without passing -lz.

@mati865
Copy link
Contributor

mati865 commented Jul 17, 2020

I've patched LLVM to link with static zlib but it fails on Ubuntu 20.04 VM with:

ld.lld: error: relocation R_X86_64_PC32 cannot be used against symbol z_errmsg; recompile with -fPIC
>>> defined in /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libz.a(zutil.o)
>>> referenced by deflate.o:(deflate.part.0) in archive /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libz.a

AFAICT the error is legit. z_errmsg symbol is not PIC so it cannot be used in PIC enabled LLVM shared library.
I can't fix it but maybe somebody else has an idea.

@rustbot release-assignment

@rustbot rustbot removed their assignment Jul 17, 2020
Manishearth added a commit to Manishearth/rust that referenced this issue Jul 18, 2020
bootstrap.py: patch RPATH on NixOS to handle the new zlib dependency.

This is a stop-gap until rust-lang#74420 is resolved (assuming we'll patch beta to statically link zlib).

However, I've been meaning to rewrite the NixOS support we have in `bootstrap.py` for a while now, and had to in order to cleanly add zlib as a dependency (the second commit is a relatively small delta in functionality, compared to the first).

Previously, we would extract the `ld-linux.so` path from the output of `ldd /run/current-system/sw/bin/sh`, which assumes a lot. On top of that we didn't use any symlinks, which meant if the user ran  GC (`nix-collect-garbage`), e.g. after updating their system, their `stage0` binaries would suddenly be broken (i.e. referring to files that no longer exist).
We were also using `patchelf` directly, assuming it can be found in `$PATH` (which is not necessarily true).

My new approach relies on using `nix-build` to get the following "derivations" (packages, more or less):
* `stdenv.cc.bintools`, which has a `nix-support/dynamic-linker` file containing the path to `ld-linux.so`
  * reading this file is [the canonical way to run `patchelf --set-interpreter`](https://github.com/NixOS/nixpkgs/search?l=Nix&q=%22--set-interpreter+%24%28cat+%24NIX_CC%2Fnix-support%2Fdynamic-linker%29%22)
* `patchelf` (so that the user doesn't need to have it installed)
* `zlib`, for the `libz.so` dependency of `libLLVM-*.so` (until rust-lang#74420 is resolved, presumably)

This is closer to how software is built on Nix, but I've tried to keep it as simple as possible (and not add e.g. a `stage0.nix` file).
Symlinks to each of those dependencies are kept in `stage0/.nix-deps`, which prevents GC from invalidating `stage0` binaries.

r? @nagisa cc @Mark-Simulacrum @oli-obk @davidtwco
Manishearth added a commit to Manishearth/rust that referenced this issue Jul 18, 2020
bootstrap.py: patch RPATH on NixOS to handle the new zlib dependency.

This is a stop-gap until rust-lang#74420 is resolved (assuming we'll patch beta to statically link zlib).

However, I've been meaning to rewrite the NixOS support we have in `bootstrap.py` for a while now, and had to in order to cleanly add zlib as a dependency (the second commit is a relatively small delta in functionality, compared to the first).

Previously, we would extract the `ld-linux.so` path from the output of `ldd /run/current-system/sw/bin/sh`, which assumes a lot. On top of that we didn't use any symlinks, which meant if the user ran  GC (`nix-collect-garbage`), e.g. after updating their system, their `stage0` binaries would suddenly be broken (i.e. referring to files that no longer exist).
We were also using `patchelf` directly, assuming it can be found in `$PATH` (which is not necessarily true).

My new approach relies on using `nix-build` to get the following "derivations" (packages, more or less):
* `stdenv.cc.bintools`, which has a `nix-support/dynamic-linker` file containing the path to `ld-linux.so`
  * reading this file is [the canonical way to run `patchelf --set-interpreter`](https://github.com/NixOS/nixpkgs/search?l=Nix&q=%22--set-interpreter+%24%28cat+%24NIX_CC%2Fnix-support%2Fdynamic-linker%29%22)
* `patchelf` (so that the user doesn't need to have it installed)
* `zlib`, for the `libz.so` dependency of `libLLVM-*.so` (until rust-lang#74420 is resolved, presumably)

This is closer to how software is built on Nix, but I've tried to keep it as simple as possible (and not add e.g. a `stage0.nix` file).
Symlinks to each of those dependencies are kept in `stage0/.nix-deps`, which prevents GC from invalidating `stage0` binaries.

r? @nagisa cc @Mark-Simulacrum @oli-obk @davidtwco
Manishearth added a commit to Manishearth/rust that referenced this issue Jul 18, 2020
bootstrap.py: patch RPATH on NixOS to handle the new zlib dependency.

This is a stop-gap until rust-lang#74420 is resolved (assuming we'll patch beta to statically link zlib).

However, I've been meaning to rewrite the NixOS support we have in `bootstrap.py` for a while now, and had to in order to cleanly add zlib as a dependency (the second commit is a relatively small delta in functionality, compared to the first).

Previously, we would extract the `ld-linux.so` path from the output of `ldd /run/current-system/sw/bin/sh`, which assumes a lot. On top of that we didn't use any symlinks, which meant if the user ran  GC (`nix-collect-garbage`), e.g. after updating their system, their `stage0` binaries would suddenly be broken (i.e. referring to files that no longer exist).
We were also using `patchelf` directly, assuming it can be found in `$PATH` (which is not necessarily true).

My new approach relies on using `nix-build` to get the following "derivations" (packages, more or less):
* `stdenv.cc.bintools`, which has a `nix-support/dynamic-linker` file containing the path to `ld-linux.so`
  * reading this file is [the canonical way to run `patchelf --set-interpreter`](https://github.com/NixOS/nixpkgs/search?l=Nix&q=%22--set-interpreter+%24%28cat+%24NIX_CC%2Fnix-support%2Fdynamic-linker%29%22)
* `patchelf` (so that the user doesn't need to have it installed)
* `zlib`, for the `libz.so` dependency of `libLLVM-*.so` (until rust-lang#74420 is resolved, presumably)

This is closer to how software is built on Nix, but I've tried to keep it as simple as possible (and not add e.g. a `stage0.nix` file).
Symlinks to each of those dependencies are kept in `stage0/.nix-deps`, which prevents GC from invalidating `stage0` binaries.

r? @nagisa cc @Mark-Simulacrum @oli-obk @davidtwco
@Dylan-DPC-zz Dylan-DPC-zz modified the milestones: 1.46, 1.47 Aug 24, 2020
@Shnatsel
Copy link
Member

Why does rustc link to zlib and not simply use miniz_oxide? The latter is 100% safe Rust and is mature enough to be the default backend for flate2.

I suspect that rustc opted for zlib over miniz (in C) back when miniz_oxide (in Rust) was not yet available.

@jethrogb
Copy link
Contributor

It's an LLVM dependency, not rustc.

netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this issue Aug 30, 2020
according to various people on tech-pkg@, there are no problems with
the Firefox build

Version 1.46.0 (2020-08-27)
==========================

Language
--------
- [`if`, `match`, and `loop` expressions can now be used in const functions.][72437]
- [Additionally you are now also able to coerce and cast to slices (`&[T]`) in
  const functions.][73862]
- [The `#[track_caller]` attribute can now be added to functions to use the
  function's caller's location information for panic messages.][72445]
- [Recursively indexing into tuples no longer needs parentheses.][71322] E.g.
  `x.0.0` over `(x.0).0`.
- [`mem::transmute` can now be used in static and constants.][72920] **Note**
  You currently can't use `mem::transmute` in constant functions.

Compiler
--------
- [You can now use the `cdylib` target on Apple iOS and tvOS platforms.][73516]
- [Enabled static "Position Independent Executables" by default
  for `x86_64-unknown-linux-musl`.][70740]

Libraries
---------
- [`mem::forget` is now a `const fn`.][73887]
- [`String` now implements `From<char>`.][73466]
- [The `leading_ones`, and `trailing_ones` methods have been stabilised for all
  integer types.][73032]
- [`vec::IntoIter<T>` now implements `AsRef<[T]>`.][72583]
- [All non-zero integer types (`NonZeroU8`) now implement `TryFrom` for their
  zero-able equivalent (e.g. `TryFrom<u8>`).][72717]
- [`&[T]` and `&mut [T]` now implement `PartialEq<Vec<T>>`.][71660]
- [`(String, u16)` now implements `ToSocketAddrs`.][73007]
- [`vec::Drain<'_, T>` now implements `AsRef<[T]>`.][72584]

Stabilized APIs
---------------
- [`Option::zip`]
- [`vec::Drain::as_slice`]

Cargo
-----
Added a number of new environment variables that are now available when
compiling your crate.

- [`CARGO_BIN_NAME` and `CARGO_CRATE_NAME`][cargo/8270] Providing the name of
  the specific binary being compiled and the name of the crate.
- [`CARGO_PKG_LICENSE`][cargo/8325] The license from the manifest of the package.
- [`CARGO_PKG_LICENSE_FILE`][cargo/8387] The path to the license file.

Compatibility Notes
-------------------
- [The target configuration option `abi_blacklist` has been renamed
  to `unsupported_abis`.][74150] The old name will still continue to work.
- [Rustc will now warn if you cast a C-like enum that implements `Drop`.][72331]
  This was previously accepted but will become a hard error in a future release.
- [Rustc will fail to compile if you have a struct with
  `#[repr(i128)]` or `#[repr(u128)]`.][74109] This representation is currently only
  allowed on `enum`s.
- [Tokens passed to `macro_rules!` are now always captured.][73293] This helps
  ensure that spans have the correct information, and may cause breakage if you
  were relying on receiving spans with dummy information.
- [The InnoSetup installer for Windows is no longer available.][72569] This was
  a legacy installer that was replaced by a MSI installer a few years ago but
  was still being built.
- [`{f32, f64}::asinh` now returns the correct values for negative numbers.][72486]
- [Rustc will no longer accept overlapping trait implementations that only
  differ in how the lifetime was bound.][72493]
- [Rustc now correctly relates the lifetime of an existential associated
  type.][71896] This fixes some edge cases where `rustc` would erroneously allow
  you to pass a shorter lifetime than expected.
- [Rustc now dynamically links to `libz` (also called `zlib`) on Linux.][74420]
  The library will need to be installed for `rustc` to work, even though we
  expect it to be already available on most systems.
- [Tests annotated with `#[should_panic]` are broken on ARMv7 while running
  under QEMU.][74820]
- [Pretty printing of some tokens in procedural macros changed.][75453] The
  exact output returned by rustc's pretty printing is an unstable
  implementation detail: we recommend any macro relying on it to switch to a
  more robust parsing system.

[75453]: rust-lang/rust#75453
[74820]: rust-lang/rust#74820
[74420]: rust-lang/rust#74420
[74109]: rust-lang/rust#74109
[74150]: rust-lang/rust#74150
[73862]: rust-lang/rust#73862
[73887]: rust-lang/rust#73887
[73466]: rust-lang/rust#73466
[73516]: rust-lang/rust#73516
[73293]: rust-lang/rust#73293
[73007]: rust-lang/rust#73007
[73032]: rust-lang/rust#73032
[72920]: rust-lang/rust#72920
[72569]: rust-lang/rust#72569
[72583]: rust-lang/rust#72583
[72584]: rust-lang/rust#72584
[72717]: rust-lang/rust#72717
[72437]: rust-lang/rust#72437
[72445]: rust-lang/rust#72445
[72486]: rust-lang/rust#72486
[72493]: rust-lang/rust#72493
[72331]: rust-lang/rust#72331
[71896]: rust-lang/rust#71896
[71660]: rust-lang/rust#71660
[71322]: rust-lang/rust#71322
[70740]: rust-lang/rust#70740
[cargo/8270]: rust-lang/cargo#8270
[cargo/8325]: rust-lang/cargo#8325
[cargo/8387]: rust-lang/cargo#8387
[`Option::zip`]: https://doc.rust-lang.org/stable/std/option/enum.Option.html#method.zip
[`vec::Drain::as_slice`]: https://doc.rust-lang.org/stable/std/vec/struct.Drain.html#method.as_slice
@Mark-Simulacrum Mark-Simulacrum added regression-from-stable-to-stable Performance or correctness regression from one stable version to another. and removed regression-from-stable-to-beta Performance or correctness regression from stable to beta. labels Oct 2, 2020
netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this issue Oct 30, 2020
Pkgsrc changes:
 * Portability patches for Illumos have been intregrated upstream,
   so are no longer needed in pkgsrc.
 * Adjust one other patch, and update vendor/libc cargo checksum.

Upstream changes:

Version 1.46.0 (2020-08-27)
==========================

Language
--------
- [`if`, `match`, and `loop` expressions can now be used in const functions.]
  [72437]
- [Additionally you are now also able to coerce and cast to slices (`&[T]`) in
  const functions.][73862]
- [The `#[track_caller]` attribute can now be added to functions to use the
  function's caller's location information for panic messages.][72445]
- [Recursively indexing into tuples no longer needs parentheses.][71322] E.g.
  `x.0.0` over `(x.0).0`.
- [`mem::transmute` can now be used in static and constants.][72920] **Note**
  You currently can't use `mem::transmute` in constant functions.

Compiler
--------
- [You can now use the `cdylib` target on Apple iOS and tvOS platforms.][73516]
- [Enabled static "Position Independent Executables" by default
  for `x86_64-unknown-linux-musl`.][70740]

Libraries
---------
- [`mem::forget` is now a `const fn`.][73887]
- [`String` now implements `From<char>`.][73466]
- [The `leading_ones`, and `trailing_ones` methods have been stabilised for all
  integer types.][73032]
- [`vec::IntoIter<T>` now implements `AsRef<[T]>`.][72583]
- [All non-zero integer types (`NonZeroU8`) now implement `TryFrom` for their
  zero-able equivalent (e.g. `TryFrom<u8>`).][72717]
- [`&[T]` and `&mut [T]` now implement `PartialEq<Vec<T>>`.][71660]
- [`(String, u16)` now implements `ToSocketAddrs`.][73007]
- [`vec::Drain<'_, T>` now implements `AsRef<[T]>`.][72584]

Stabilized APIs
---------------
- [`Option::zip`]
- [`vec::Drain::as_slice`]

Cargo
-----
Added a number of new environment variables that are now available when
compiling your crate.

- [`CARGO_BIN_NAME` and `CARGO_CRATE_NAME`][cargo/8270] Providing the name of
  the specific binary being compiled and the name of the crate.
- [`CARGO_PKG_LICENSE`][cargo/8325] The license from the manifest of the
  package.
- [`CARGO_PKG_LICENSE_FILE`][cargo/8387] The path to the license file.

Compatibility Notes
-------------------
- [The target configuration option `abi_blacklist` has been renamed
  to `unsupported_abis`.][74150] The old name will still continue to work.
- [Rustc will now warn if you have a C-like enum that implements `Drop`.][72331]
  This was previously accepted but will become a hard error in a future release.
- [Rustc will fail to compile if you have a struct with
  `#[repr(i128)]` or `#[repr(u128)]`.][74109] This representation is currently
  only allowed on `enum`s.
- [Tokens passed to `macro_rules!` are now always captured.][73293] This helps
  ensure that spans have the correct information, and may cause breakage if you
  were relying on receiving spans with dummy information.
- [The InnoSetup installer for Windows is no longer available.][72569] This was
  a legacy installer that was replaced by a MSI installer a few years ago but
  was still being built.
- [`{f32, f64}::asinh` now returns the correct values for negative numbers.]
  [72486]
- [Rustc will no longer accept overlapping trait implementations that only
  differ in how the lifetime was bound.][72493]
- [Rustc now correctly relates the lifetime of an existential associated
  type.][71896] This fixes some edge cases where `rustc` would erroneously
  allow you to pass a shorter lifetime than expected.
- [Rustc now dynamically links to `libz` (also called `zlib`) on Linux.][74420]
  The library will need to be installed for `rustc` to work, even though we
  expect it to be already available on most systems.
- [Tests annotated with `#[should_panic]` are broken on ARMv7 while running
  under QEMU.][74820]
- [Pretty printing of some tokens in procedural macros changed.][75453] The
  exact output returned by rustc's pretty printing is an unstable
  implementation detail: we recommend any macro relying on it to switch to a
  more robust parsing system.

[75453]: rust-lang/rust#75453
[74820]: rust-lang/rust#74820
[74420]: rust-lang/rust#74420
[74109]: rust-lang/rust#74109
[74150]: rust-lang/rust#74150
[73862]: rust-lang/rust#73862
[73887]: rust-lang/rust#73887
[73466]: rust-lang/rust#73466
[73516]: rust-lang/rust#73516
[73293]: rust-lang/rust#73293
[73007]: rust-lang/rust#73007
[73032]: rust-lang/rust#73032
[72920]: rust-lang/rust#72920
[72569]: rust-lang/rust#72569
[72583]: rust-lang/rust#72583
[72584]: rust-lang/rust#72584
[72717]: rust-lang/rust#72717
[72437]: rust-lang/rust#72437
[72445]: rust-lang/rust#72445
[72486]: rust-lang/rust#72486
[72493]: rust-lang/rust#72493
[72331]: rust-lang/rust#72331
[71896]: rust-lang/rust#71896
[71660]: rust-lang/rust#71660
[71322]: rust-lang/rust#71322
[70740]: rust-lang/rust#70740
[cargo/8270]: rust-lang/cargo#8270
[cargo/8325]: rust-lang/cargo#8325
[cargo/8387]: rust-lang/cargo#8387
[`Option::zip`]: https://doc.rust-lang.org/stable/std/option/enum.Option.html#method.zip
[`vec::Drain::as_slice`]: https://doc.rust-lang.org/stable/std/vec/struct.Drain.html#method.as_slice
@Enselic Enselic added the A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. label Dec 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. regression-from-stable-to-stable Performance or correctness regression from one stable version to another. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-release Relevant to the release subteam, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests