Commit a594c56
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 9a692b1 commit a594c56
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