-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Panic compiling multiplex-rs
#46744
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
sfackler
added
the
I-ICE
Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
label
Dec 15, 2017
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
|
pnkfelix
added
the
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
label
Mar 29, 2019
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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in 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: