-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Panic compiling multiplex-rs
#46744
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Labels
A-incr-comp
Area: Incremental compilation
C-bug
Category: This is a bug.
I-ICE
Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
here's a test case. i got this ICE by random (un)luck and i can't remove any further code or it won't reproduce. at least it's a single file. cannot reproduce with rustc, must be called from cargo. use std::io;
enum Tree {
Leaf(
Vec<u8>
),
Branch(
Vec<BlockRef>,
),
}
struct Block {
tree: Tree
}
enum BlockRef {
StoreRef(Vec<u8>),
Memory(Block),
}
trait Blockstore {
fn store(&mut self, block: Block) -> io::Result<Block>;
}
struct FilesystemStore {
}
impl FilesystemStore {
pub fn open<P: AsRef<Path>>(path: P) -> Result<Self> {
Ok(Self{})
}
}
impl Blockstore for FilesystemStore {
fn store(&mut self, block: Block) -> io::Result<Block> {
}
}
fn main() {
let some_file = include_bytes!("main.rs");
} |
at least i think its related, since its in CacheDecoder as well
|
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Nov 12, 2020
incr-comp: hash and serialize span end line/column Hash both the length and the end location (line/column) of a span. If we hash only the length, for example, then two otherwise equal spans with different end locations will have the same hash. This can cause a problem during incremental compilation wherein a previous result for a query that depends on the end location of a span will be incorrectly reused when the end location of the span it depends on has changed. A similar analysis applies if some query depends specifically on the length of the span, but we only hash the end location. So hash both. Fix rust-lang#46744, fix rust-lang#59954, fix rust-lang#63161, fix rust-lang#73640, fix rust-lang#73967, fix rust-lang#74890, fix rust-lang#75900 --- See rust-lang#74890 for a more in-depth analysis. I haven't thought about what other problems this root cause could be responsible for. Please let me know if anything springs to mind. I believe the issue has existed since the inception of incremental compilation.
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Labels
A-incr-comp
Area: Incremental compilation
C-bug
Category: This is a bug.
I-ICE
Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Index out of bounds ICE while compiling multiplex-rs. I don't know enough about why this could happen to produce a minimal reproduction. Backtrace:
The text was updated successfully, but these errors were encountered: