Skip to content

fix: nested lambda base rewriting in combine#584

Open
AriajSarkar wants to merge 1 commit intozio:developfrom
AriajSarkar:issue-571-fix
Open

fix: nested lambda base rewriting in combine#584
AriajSarkar wants to merge 1 commit intozio:developfrom
AriajSarkar:issue-571-fix

Conversation

@AriajSarkar
Copy link
Copy Markdown
Contributor

  • fix LightTypeTag.combine and combineNonPos to only apply outer arguments to inherited lambda bases
  • keep unrelated nested lambda bases under plain reference rewriting
  • add a Scala 2 regression test for RuntimeAPI.unpack with abstract type bounds and intersections
  • move the now-passing combine coverage out of the progression suite

Testing

  • sbt "++2.13.14" "izumi-reflectJVM/testOnly izumi.reflect.test.TagTest -- -z RuntimeAPI.unpack"
  • sbt "++2.13.14" "izumi-reflectJVM/testOnly izumi.reflect.test.TagTest"
  • sbt "++2.13.14" "izumi-reflectJVM/testOnly izumi.reflect.test.TagCombineTest"
  • sbt "++2.13.14" "izumi-reflectJVM/test"
  • sbt +test

Closes #571

@neko-kai
Copy link
Copy Markdown
Member

neko-kai commented Apr 4, 2026

Hi @AriajSarkar, thanks for the attempt, but the diff is large and unexplained (I suspect that a proper fix can be done via a much smaller diff) + 2 progression tests were removed (not inverted), so it's not clear whether the misbehavior they were capturing was fixed or just changed. Someone has to know what's going on in the code - merging a significant refactor by LLM means no one knows anymore - not me, not you, not the LLM.

The project is not LLM-first - Issue 1. it's somewhat brittle (LLM-first projects require much more extensive test suites, to prevent LLMs from introducing regressions), Issue 2. it's largely undocumented (while the project itself is small, there's a lot of implied nuance in the subject matter that an LLM misses on glance).

Now, what can be done to make the project LLM-first is correcting both of these. The second issue is easier - you may put Claude Code onto a research task to crawl through the code, through git history, through issues, through associated Scala Macro APIs and make it write down as much as it can into an llm-docs/ directory in the project. That directory can be committed and then serve as distilled context for the model, so that it can make more informed decisions. It can then also be used to attempt to address issue 1: the LLM can look at the docs it generated and compare it with the actual tested surface and try to fill gaps.

Note: just putting my post into the LLM prompt is unlikely to result in usable output. Claude usually has to be carefully prompted to perform research tasks in a non-lazy way, such that they actually contain useful information, not already obvious trivia.

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.

RuntimeAPI.unpack for abstract type bounds is broken since 3.0.4 (scala 2.13)

2 participants