rust-lang / rust-lang/rust

rustc 1.87.0 ICE compiling rusqlite 0.31.0 in Docker release build

Open
#155,369 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

C-bug I-ICE needs-triage P-medium regression-untriaged S-needs-repro T-compiler
Dominant language
Rust
Stars
119k
Forks
16.1k
PR merge metrics
PR metrics pending

Description

Summary

I hit an internal compiler error from rustc 1.87.0 while building rusqlite 0.31.0 inside a Docker release build.

The crash happened repeatedly while compiling rusqlite with feature="bundled" and involved repeated panics in:

  • compiler/rustc_trait_selection/src/traits/specialize/specialization_graph.rs:41:57
  • compiler/rustc_trait_selection/src/traits/select/candidate_assembly.rs:563:83

The panic message was:

called `Option::unwrap()` on a `None` value

This was reported by rustc itself as:

error: the compiler unexpectedly panicked. this is a bug.

As of April 15, 2026, I can no longer reproduce this reliably from the same checkout with the same rust:1.87-slim tag, so this may be an unstable or dependency-resolution-sensitive ICE. I am filing it anyway because the original failure log is very detailed and points at compiler internals.

Reproducer

The failing build came from this Dockerfile:

FROM rust:1.87-slim AS builder
WORKDIR /app
RUN apt-get update && apt-get install -y pkg-config libssl-dev && rm -rf /var/lib/apt/lists/*
COPY Cargo.toml .
COPY src ./src
RUN cargo build --release

The crate under build depended on:

rusqlite = { version = "0.31", features = ["bundled"] }

The failure occurred during:

RUN cargo build --release

and the final error was:

error: could not compile `rusqlite` (lib)

One of the rustc invocations from the failing log was:

/usr/local/rustup/toolchains/1.87.0-x86_64-unknown-linux-gnu/bin/rustc --crate-name rusqlite --edition=2021 /usr/local/cargo/registry/src/index.crates.io-1949cf8c6b5b557f/rusqlite-0.31.0/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C embed-bitcode=no --cfg 'feature="bundled"' --cfg 'feature="modern_sqlite"' ... -C strip=debuginfo ...

Relevant resolved crates from the failure log included:

  • rusqlite 0.31.0
  • bitflags 2.11.1
  • libsqlite3-sys 0.28.0
  • hashlink 0.9.1
  • smallvec 1.15.1
What I expected

cargo build --release should either compile successfully or produce a normal diagnostic from the crate graph. It should not ICE in trait selection.

What happened instead

rustc repeatedly panicked while compiling rusqlite, including query stacks like:

#0 [specialization_graph_of] building specialization graph of trait `core::ops::drop::Drop`
#1 [coherent_trait] coherence checking all impls of trait `core::ops::drop::Drop`

and:

#0 [evaluate_obligation] evaluating trait selection obligation `<i32 as core::ops::bit::BitXor>::Output == i32`
#1 [compare_impl_item] checking assoc item `<impl at /usr/local/cargo/registry/src/index.crates.io-1949cf8c6b5b557f/bitflags-2.11.1/src/public.rs:536:9: 536:47>::Bits` is compatible with trait definition

The repeated panic sites were:

thread 'rustc' panicked at compiler/rustc_trait_selection/src/traits/specialize/specialization_graph.rs:41:57:
called `Option::unwrap()` on a `None` value

and later:

thread 'rustc' panicked at compiler/rustc_trait_selection/src/traits/select/candidate_assembly.rs:563:83:
called `Option::unwrap()` on a `None` value

I saw many repeated query stacks for traits like:

  • core::ops::drop::Drop
  • core::marker::Copy
  • core::clone::Clone
  • core::fmt::Debug
  • core::marker::Send
  • core::cmp::Eq
  • core::hash::Hash
  • core::cmp::PartialEq
  • core::cmp::PartialOrd
  • core::cmp::Ord
  • core::ops::bit::BitXor
  • core::ops::bit::BitXorAssign
  • core::ops::bit::BitAnd
  • core::ops::bit::BitAndAssign
  • core::ops::arith::Sub
  • core::ops::arith::SubAssign
  • core::ops::bit::Not
  • core::marker::Sync
  • core::error::Error
  • core::ops::deref::Deref
  • core::ops::deref::DerefMut
  • core::convert::TryFrom
Version

From the failing output:

rustc 1.87.0 (17067e9ac 2025-05-09) running on x86_64-unknown-linux-gnu

I also confirmed on April 15, 2026 that rust:1.87-slim currently reports:

rustc 1.87.0 (17067e9ac 2025-05-09)
host: x86_64-unknown-linux-gnu
LLVM version: 20.1.1
Additional context
  • The build was happening in Docker, not in a local interactive shell.
  • The builder stage used rust:1.87-slim.
  • The original failure log was very large because the compiler panicked repeatedly across many trait queries before the build stopped.
  • On April 15, 2026, docker build -q -f products/signal-hive/backend/Dockerfile products/signal-hive/backend succeeded for me from the same checkout, so I do not currently have a stable minimized reproducer.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the Dockerfile and run cargo build --release using rust:1.87-slim and the listed rusqlite dependency versions. Then inspect the reported panic locations in compiler/rustc_trait_selection/src/traits/specialize/specialization_graph.rs and compiler/rustc_trait_selection/src/traits/select/candidate_assembly.rs. Done means establishing a stable reproducer or documenting why the ICE cannot be reproduced from the supplied inputs.

Written by the indexing model from the issue text.

Assessment

Tech stack
docker, rust, sqlite
Domain
build-system, compilers
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
28/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.