test: cover compatibility YESNO field type checks

2026-09-14 01:24:35 +00:00
parent dfb707972e
commit 636fcc01d2
6 changed files with 25 additions and 3 deletions
@@ -345,7 +345,7 @@ The same missing-object guidance is now validated for direct field assignment be
 Object player is not known yet. Create it with NEW ClassName player before setting player.score.
 ```

-The checker also names typed method-body field checks and assignments. Inside `Player.rename`, `CHECK TYPE name IS NUMBER` reports `Type check failed in Player.rename: expected NUMBER, but name looks like TEXT.` Inside `Player.rename`, `SET name 123` reports `Type mismatch for field name in Player.rename: expected TEXT, but this value looks like NUMBER.` Inside `Player.add RETURNS NUMBER`, `SET score score + name` reports `Type mismatch for field score in Player.add: addition needs NUMBER values, but name looks like TEXT.` so the learner sees that the field belongs to the current class method, not an unrelated variable.
+The checker also names typed method-body field checks and assignments. Inside `Player.rename`, `CHECK TYPE name IS NUMBER` reports `Type check failed in Player.rename: expected NUMBER, but name looks like TEXT.` Inside `Player.add RETURNS NUMBER`, `SET score score + name` reports `Type mismatch for field score in Player.add: addition needs NUMBER values, but name looks like TEXT.` The same metadata check is covered for compatibility `TAKES` / `LEARNED` methods with YESNO fields, so `CHECK TYPE ready IS TEXT` reports `Type check failed in Player.toggle: expected TEXT, but ready looks like YESNO.` The learner sees that the field belongs to the current class method, not an unrelated variable.

 The release validator also runs the modern and compatibility method-body field diagnostic fixtures, including `CHECK TYPE` checks in older `TAKES` / `LEARNED` methods, so these learner-facing errors remain part of `claro validate`, not only the standalone typecheck diagnostic script.