Remove redundant bound-method-field check in GlobalOpLowering - #250
Merged
Conversation
The #246 isBoundMethodTupleConstant special case in GlobalOpLowering decided whether a global's initializer needs the constructor path based on whether any ConstantOp in it had a bound-method-shaped tuple field. Since PR #249 boxes every method-bearing object literal, such a literal's initializer always contains a NewOp (the boxing recipe), which the walk's existing NewOp case already forces onto the constructor path -- making the bound-method check redundant. Verified via a diagnostic probe at that call site across every test file (zero hits) before removing it for real. Investigated but did NOT remove needsIdentityStorage/boundRefMaterializedCache: contrary to the original plan (docs/object-literal-boxing-design.md), these are still load-bearing. Whenever a boxed literal is unboxed back into a plain tuple to match a declared/inferred type (annotated const, parameter, interface-cast fallback, generic intersection/inference), the resulting tuple's method field is still bound-method-shaped even though the tuple itself is a plain value -- that machinery is what makes calling through it work correctly instead of crash. Root-caused via site-tagged diagnostic probes across the full test corpus; documented in the design doc so this isn't re-attempted without re-deriving the same finding. Full suite green: 353/353 JIT + 357/357 AOT. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
docs/object-literal-boxing-design.md) — this is the cleanup pass, but narrower than originally planned.isBoundMethodTupleConstantspecial case inGlobalOpLowering: confirmed redundant since every boxed literal's initializer region now unconditionally contains aNewOp(the boxing recipe from PR Box object literals with methods/accessors as reference-typed ObjectType #249), which the walk's existingNewOpcase already routes onto the global-constructor path.needsIdentityStorage/boundRefMaterializedCacheas the design doc originally planned — investigation showed they're still load-bearing. Whenever a boxedObjectTypeliteral is unboxed back into a plain tuple to match a declared/inferred type (an annotatedconst, a function parameter, an interface-cast fallback, a generic intersection/inference result), the resulting tuple's method field is still bound-method-shaped even though the tuple itself is a plain value — that machinery is what makes calling through it work correctly instead of crash. This is documented in the design doc (§5, §6) so it isn't re-attempted without re-deriving the finding.Test plan
GlobalOpLoweringremoval is safe via a diagnostic (non-fatal) probe run against every test file in the suite directly through the JIT (not just ctest) — zero hits at that specific call site — before removing it for real.needsIdentityStorage/boundRefMaterializedCacheare not dead via the same probe technique: 5+ test files (00interface_object5,00object_ref_semantics,00question_question,00type_aliases_in_generics,00object_boxed_infra) still exerciseTuple()'sisBoundRefbranch.ctest --test-dir <builddir> -C Debug -R "^test-jit-"/"^test-compile-"-j8).🤖 Generated with Claude Code