Skip to content

Conversation

@bkoropoff
Copy link
Contributor

Closes #16939

When an overloaded call expression has parameters but the function
object takes none, construct an array of formal argument types with
the arity of the call expression so that we don't fail by indexing out
of bounds later.

Closes #16939
bors added a commit that referenced this pull request Oct 18, 2014
@bors bors closed this Oct 19, 2014
@bors bors merged commit 0e68c63 into rust-lang:master Oct 19, 2014
lnicola pushed a commit to lnicola/rust that referenced this pull request Sep 25, 2024
fix: Extend `type_variable_table` when modifying index is larger than the table size

Fixes rust-lang#18109

Whenever we create an inference variable in r-a, we extend `type_variable_table` to matching size here;

https://github.com/rust-lang/rust-analyzer/blob/f4aca78c92e03354327c8f6c7fefaef9f45ab166/crates/hir-ty/src/infer/unify.rs#L378-L381

But sometimes, an inference variable is [created from chalk](https://github.com/rust-lang/chalk/blob/ab710e0c9b455403b138ef72a2fb90967a58eff3/chalk-solve/src/infer/unify.rs#L743) and passed to r-a as a type of an expression or a pattern.
If r-a set diverging flag to this before the table is extended to a sufficient size, it panics here;

https://github.com/rust-lang/rust-analyzer/blob/f4aca78c92e03354327c8f6c7fefaef9f45ab166/crates/hir-ty/src/infer/unify.rs#L275-L277

I think that extending table when setting diverging flag is reasonable becase we are already doing such extending to a size that covers the inference vars created from chalk and this change only covers the order-dependent random cases that this might fail
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

ICE calling an unboxed closure with the wrong number of parameters inside another closure

4 participants