Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Doc gap: no discoverable notice that CAGRA's C++ build API changed argument types in 26.10

Aperta Adatta ai principianti
  • Qualcosa non va?
#2,673 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
82/100
Tipo di issue
Documentazione
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
cpp
Ambito
documentation

Direzione di ricerca

Inizia con CHANGELOG.md e cpp/include/cuvs/neighbors/cagra.hpp; confronta la cronologia delle versioni documentata con le signature tipizzate di build() e update_dataset() introdotte in 26.10. Aggiungi una nota del changelog facilmente individuabile che descriva le modifiche incompatibili alla forma delle chiamate C++ e ai tipi restituiti, con il contesto pertinente dell’API CAGRA. Il lavoro è completato quando un consumatore esterno può trovare la nota durante l’aggiornamento.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Doc gap

There's no discoverable notice anywhere in the repo — not CHANGELOG.md, not the CAGRA docs — that cuvs::neighbors::cagra::build()/update_dataset() changed their argument and return types in 26.10. The old call shape (build(res, params, raft::device_matrix_view<...>) returning index<T, uint32_t>) no longer compiles; the new one requires a typed dataset view (device_padded_dataset_view, host_standard_dataset_view, etc., see cpp/include/cuvs/neighbors/cagra.hpp) and returns a matching typed index (device_padded_index<T, uint32_t>, ...).

Everything internal to this repo — the 5 examples/cpp/src/cagra_*.cu examples, the C API in c/src/neighbors/cagra.cpp, the fern docs — is already consistent with the new API. So the gap isn't correctness, it's discoverability for anyone building against the headers from outside the repo.

How this cost us

We maintain a fork of facebookresearch/faiss that links directly against published cuVS releases as a C++ dependency. Rebuilding it against a post-26.10 cuVS release failed to compile with no clue from cuVS's own materials about what changed or why. cuVS's own build and full test suite (35/35) passed on both sides of the change, which only confirms cuVS's own call sites match its own current API — it doesn't help an external consumer at all.

We eventually found that NVIDIA's own faiss maintainer had already fixed this exact break in facebookresearch/faiss#5633 (open since 2026-08-26, not yet merged), and cherry-picked the relevant hunks rather than re-deriving the port. The fix existed, upstream, in a sibling project, before we had any way to know we needed one — because nothing in cuVS pointed at it. A one-line changelog entry would have turned an afternoon of investigation into a five-minute search.

Suggestion

At minimum, a CHANGELOG.md entry for releases that change the C++ header API's call shape — the same instinct that already tracks C-ABI breaks in this repo, just extended to the template header API most C++ consumers (faiss included) actually build against.

Separately, and this is a design opinion rather than a doc request: changing argument and return types on an existing function is a breaking change to anyone calling it, whether or not it's covered by the stated ABI policy. The usual way to avoid forcing an unannounced recompile-or-break choice on downstream consumers is to introduce the new call shape under its own name and deprecate the old one for a release or two, rather than changing the existing signature in place. I'm raising it here because it's the direct cause of this particular gap, not to relitigate the whole API — just flagging it as the kind of change that most needs a changelog line if it's going to happen at all.

Lingua principale
Cuda
Stelle
869
Fork
243
Merge medio
3g 15h
PR unite (30g)
78

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di NVIDIA/cuvs

Tutte le issue di NVIDIA/cuvs

Issue simili

Altre issue su Documentation

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.