feat(checker): require type arguments on dict, list and tuple

[SandeepaHWP]

Bare dict, list and tuple are now a hard error rather than a warning.

What changed

A generic written without type arguments used to draw W1036 and quietly behave as if any had been written for its element types. So dict and dict[str, any] meant the same thing while reading differently, and the checker fed any into the native path where a real type would have been cheaper.

Writing dict, list or tuple bare is now E1036, and the bare-generic fallback in build_type_var_solution resolves to Unknown instead of any, so values read out of such a container are reported rather than silently accepted.

d: dict = src();
return d["a"]["b"];        # E1036 on the annotation, Unknown through the reads

d: dict[str, any] = src();
return d["a"]["b"];        # fine, and says what it means

The compiler-side diff is small: 5 files, 25 insertions, 10 deletions. Everything else in this PR is the migration that the new rule forces.

Scoping

Both the diagnostic and the fallback are gated on a shared BARE_GENERIC_REQUIRED = ["dict", "list", "tuple"].

The fallback matters more than it looks. It runs on every generic member lookup, not just annotations, so an unscoped change made this fail:

with tempfile.TemporaryDirectory() as d {
    p = Path(d) / "x.txt";     # Unknown, and no annotation exists to fix it
}

TemporaryDirectory is generic and instantiated without type arguments, so its __enter__ type variable went unsolved and recovered as Unknown. Scoping keeps any for everything outside the three types, so set, frozenset, Queue and unparameterised generic classes are untouched.

Nested generics

_check_bare_generic now descends into type arguments. Previously list[dict] and dict[str, dict] emitted nothing, because the outer generic was parameterised, but the inner one still resolved to Unknown and surfaced later as an unrelated E1055/E1053 elsewhere in the file. Three of the harder bugs in this branch traced back to exactly that. There were about 200 such sites.

The migration

Roughly 395 annotation sites across ~140 files, typed from how each value is actually used rather than widened to any:

• list[float] for flattened 4x4 matrices, list[list[float]] for the matrix stacks
• dict[int, int] for keycode state
• dict[str, SemTokManager], tuple[bool, set[tuple[str, str]]], list[tuple[int, int, list[str]]]
• dict[str, any] only where the payload is genuinely heterogeneous JSON

Four failure modes needed more than a substitution:

• isinstance narrowing to a bare generic. isinstance(tcs, list) narrows to bare list, so elements become Unknown. Fixed by binding a typed local.
• Constructor calls. list(getattr(...)) has nothing to infer from; fixed by annotating the receiving variable.
• Cross-file cascades. Several files that were never edited went red because a bare generic in a different file leaked into them, including from .jacignored files.
• Inference quirks. [text] if text else [] inferred list[LiteralString] and rejected a plain str; restructuring to an explicit if fixed it.

The native seal

This was the bulk of the late work and the least obvious part of the change: .jacignore does not protect the native seal. The seal compiles the compiler's own sources into the binary, so E1036 there is fatal even in files jac check skips entirely, and it fails fast on the first broken module. That surfaced 217 sites across ~25 files in jac0core that no other gate could see, in native_marshal.jac, pyast_gen_pass, codeinfo.jac, runtime.jac, modresolver.jac and the parser.

Three of those needed judgement rather than an annotation:

• unitree.jac's py_ast_targets and the py_ast field behind it are list[any], not a concrete AST type: neither module imports ast3, and every consumer already casts to list[ast3.expr], so any preserves the exact prior behaviour without inventing an import.
• jir_registry.jac is generated. Typing it by hand made it diverge from gen_jir_registry.jac and fail jac gen-jir-registry --verify, so both annotations moved into the generator. Regenerating now reproduces the committed file byte for byte.
• parser.impl.jac had acc_list: (list[Ability] | None) assigned an empty literal. An empty literal cannot take its element type from a union target, so it resolved to Unknown once bare generics stopped defaulting to any. It now accumulates in a plain list[Ability] and assigns that, which keeps None and [] distinct because HasVar.accessors is (Sequence[Ability] | None).

That last one is worth flagging to reviewers. Two earlier attempts fixed it in the type evaluator instead, by reading expected container types through unions and then by defaulting uninferrable empty literals to any. Both fixed the target error and broke a different one, because changing how empty literals are typed changes what the native backend is handed everywhere: the first turned self.__sub_node_tab = {} into an un-lowerable dict[type, list[UniNode]], the second turned self.hub = {...} if x else {} into an un-lowerable union. Both are reverted. Type inference is untouched by this PR.

Docs

Nine skill guides taught the old style in jac-fenced examples, which test_guide.jac requires to pass jac check. Fifteen sites, several of them nested (list[dict]) or inside a union (dict | None), forms the old warning never reached.

Tests

test_checker_pass.jac:

• bare_generic_hard_error_at_every_site, return type, param type, local annotation, and nested inside a parameterised generic
• bare_generic_iteration_is_a_hard_error, replaces bare_generic_iteration_yields_any, whose premise this change removes
• bare_generic_in_signatures_emits_e1036, 6 sites now, down from 8, since set and frozenset are out of scope
• explicit_any_propagates_through_operations, the escape hatch keeps working through chained subscript, attribute access and iteration

test_unpack_any_element.jac was written on the PEP 484 rule that a bare tuple is tuple[Any, ...], which is precisely what this change removes. Its fixture now uses the explicit tuple[any, any] / list[any] spellings, which reach the same _extract_tuple_element_type path the test guards.

Three native fixtures keep a bare generic behind an inline # jac:ignore[E1036] with the reason recorded next to it, because there is currently no way to spell what they test. See the next section.

prod b1-b5 in test_checker_production.jac still pass; they assert that Unknown is not a universal any, which this change reinforces.

Pre-existing gaps this surfaces

None of these are caused by this PR, and each reproduces on main once the fixture is typed. They matter because list[any] is the spelling a bare list migrates to, and these are the cases it fails on:

• repr() has no native lowering for list[any] or dict[str, any], though it lowers bare containers fine.
• list[any] elements are not reclaimed under --gc none; the nogc churn fixture measured 2.5 MB of growth per window once typed.
• Destructuring an element of an explicitly any container bound Unknown. This one is now fixed upstream by Epic: typed OOP front end. Retire the syntax arena, construct unitree directly, seal the front end natively (supersedes #7970) #8039's follow-up, which made the E1020 guard and _extract_tuple_element_type use is_any_instance(); it is merged into this branch.

The first two share the root that an explicit any annotation is a ClassType for builtin Any rather than a types.AnyType, the same split #7961 fixed on the consumer side. Worth deciding whether to close that before or after this lands, since it sets how loud the migration is for people who genuinely hold mixed values.

Known gaps

.jacignored files such as na_ir_gen_pass.jac still carry bare generics that jac check cannot see. Those that leak into non-ignored files, or into the native seal, were fixed; the rest are left for follow-up.

jac fmt is not idempotent in a single pass on this change: wrapping one signature can push the next one over the line limit, so it needs running until it converges.

[greptile-apps]

Too many files changed for review (1055 files, 100 file limit).

[marsninja]

Closing: no activity in 10+ days. Reopen if still relevant.