ICE: index out of bounds: the len is 1 but the index is 1 #118185
Assignees
Labels
C-bug
Category: This is a bug.
I-ICE
Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
S-bug-has-test
Status: This bug is tracked inside the repo by a `known-bug` test.
S-has-mcve
Status: A Minimal Complete and Verifiable Example has been found for this issue
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
rkuklik
added
C-bug
rustbot
added
the
needs-triage
compiler-errors
changed the title
compiler-errors
added
the
E-needs-mcve
saethlin
removed
the
needs-triage
|
Relabeling issues which don't have a runnable reproduction (as opposed to not having a minimized one) to the new label S-needs-repro. |
rustbot
added
S-needs-repro
|
I think I encountered the same bug. A minimal example is below. fn main() {
let target: Target = create_target();
target.get(0); // correct arguments work
target.get(10.0); // CRASH HERE
}
// must be generic
fn create_target<T>() -> T {
unimplemented!()
}
// unimplemented trait, but contains function with the same name
pub trait RandomTrait {
fn get(&mut self); // but less arguments
}
struct Target;
impl Target {
// correct function with arguments
pub fn get(&self, data: i32) {
unimplemented!()
}
}I think the problem is a lookup, which includes the unimplemented trait without checking the length of the argument list before accessing.
Also fails on nightly. nightly ructc-ice.txt
|
matthiaskrgr
added
S-has-mcve
|
|
Maybe #112537 inside rollup #112774? cc @compiler-errors |
matthiaskrgr
added
the
S-bug-has-test
|
I ran into this ICE and minimized my case to the following reproducer. Its slightly different way to get to the same case as @antonWetzel 's code above. Still happens from stable 1.77.2 to nightly 2024-04-19. fn ice() {
let a: &dyn A = &V;
a.x(&());
}
struct V;
impl V {
pub fn x(&self) {
todo!()
}
}
trait A {
fn x(&self, y: ());
}
impl A for V {
fn x(&self, y: ()) {
todo!();
}
}When doing a bisection I get nightly-2023-05-16. |
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
May 22, 2024
…res, r=estebank Make sure that the method resolution matches in `note_source_of_type_mismatch_constraint` `note_source_of_type_mismatch_constraint` is a pile of hacks that I implemented to cover up another pile of hacks. It does a bunch of re-confirming methods, but it wasn't previously checking that the methods it was looking (back) up were equal to the methods we previously had. This PR adds those checks. Fixes rust-lang#118185
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello,
I am sorry, but I wasn't able to reproduce the bug outside my company's project (proprietary and which I don't have the permission to share), so I can't really help here. Code like this resides in proc-macro transformed function (
#[component]from leptos) and inside recursivelly callingwith!macro. Here is how approximately it looks:Code
Meta
Fails on both nightly and stable, backtrace if from nightly.
rustc --version --verbose:Error output
Backtrace
Hope this helps and thank for your work.
The text was updated successfully, but these errors were encountered: