Mirror A-LLVM + I-slow issues to the LLVM bug tracker?

There are currently 113 open issues with such labels. I have reported several such issues myself. And I got an impression that they have a relatively low priority and often do not get reported to the LLVM bug tracker, meaning that LLVM developers may not know about them in the first place unless there is a Rust developer interested enough in solving it.

I wonder if it could be worth to somehow automate mirroring of such issues to the LLVM side. It could help with solving them without burdening Rust developers, improving LLVM for all languages along the way. Also linking an LLVM issue in an original Rust one will help with tracking progress on such issue or lack of it.

Why not rely on authors of those Rust issues? I can name several reasons:

  • Often authors think that their part is done by reporting it to the Rust issue tracker.
  • Public registration to the LLVM bug tracker is currently closed. Many simply will not bother with sending a request email.
  • It's worth to be familiar with (often unwritten) rules of sending issues to large projects. For example, what category should Rust-related bugs use? IIRC there is a category for C/C++, but nothing for Rust.
4 Likes

LLVM is in the process of moving all their issue tracking to github, so assuming that removes the reporting burden, I would favour just closing anything in the rust tracker that also repros in clang.

(For example, if clang can optimize away the bounds checking in std::vector::at but rustc can't in Vec::index, that's a rust bug. But if clang can't remove it either, then it should be closed with a request to report upstream.)

I don't think it's worth to close Rust issues if they are duplicated in the LLVM tracker. An issue does not get automatically resolved on the Rust side after it got resolved on the LLVM side. At the very least Rust has to be updated to an LLVM version which includes the fix.

6 Likes