Commit 54440bb
Avoid method instance normalization for opaque closure methods (#59772)
Fixes #59222.
This issue was caused by a mismatch with
`jl_new_opaque_closure_from_code_info_in_world` filling in the
unnormalized method instance, and `new_opaque_closure` getting its
`spec_ptr` from the normalized one via `jl_compile_method_internal`.
For example, `g(xs...)` specialized as `g(:a, :b)` resulted in a
different method instance than the corresponding normalized one:
```julia
Tuple{Tuple{typeof(Main.g)}, Symbol, Symbol} # unnormalized
Tuple{Tuple{typeof(Main.g)}, Symbol, Vararg{Symbol}} # normalized
```
Here I chose to align on using the unnormalized one from the `CodeInfo`
at `OpaqueClosure` construction (the fix being a single-line change in
that case), but we could also choose the normalized one if that is
deemed preferable, so long as we use the same when storing the inferred
code and when retrieving the `spec_ptr`.
---
🤖 Generated with some assistance from Claude Code.
(cherry picked from commit e8667fb)1 parent 9db6222 commit 54440bb
2 files changed
+15
-1
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
3683 | 3683 | | |
3684 | 3684 | | |
3685 | 3685 | | |
3686 | | - | |
| 3686 | + | |
3687 | 3687 | | |
3688 | 3688 | | |
3689 | 3689 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
297 | 297 | | |
298 | 298 | | |
299 | 299 | | |
| 300 | + | |
| 301 | + | |
| 302 | + | |
| 303 | + | |
| 304 | + | |
| 305 | + | |
| 306 | + | |
| 307 | + | |
| 308 | + | |
| 309 | + | |
| 310 | + | |
| 311 | + | |
| 312 | + | |
| 313 | + | |
300 | 314 | | |
301 | 315 | | |
302 | 316 | | |
| |||
0 commit comments