ArrayLiteralAsArgument and ArrayReturnCallInExpressionPosition are not type errors — the types are valid in both cases. They are codegen lowering restrictions: the sret calling convention requires a destination pointer (only available from a named variable),
and array literal arguments need a named frame slot.
These belong in core/analysis/ (the analyze() pass), which already documents its scope as "semantic violations that are not type errors" (see core/inference/src/lib.rs line 518-523). The analyze() function is currently a no-op stub.
- Move when:
core/analysis/ crate is created (likely alongside return-path analysis, which is already tracked as a known issue)
- Current locations:
ArrayLiteralAsArgument: core/type-checker/src/errors.rs line 448, checked at 3 argument validation sites in type_checker.rsArrayReturnCallInExpressionPosition: core/type-checker/src/errors.rs line 458, checked at 6 sites in type_checker.rs
- Why it works today: The type checker runs before codegen, so catching these early is functionally correct. The issue is architectural — it couples the type checker to codegen implementation details.
ArrayLiteralAsArgumentandArrayReturnCallInExpressionPositionare not type errors — the types are valid in both cases. They are codegen lowering restrictions: the sret calling convention requires a destination pointer (only available from a named variable),and array literal arguments need a named frame slot.
These belong in
core/analysis/(theanalyze()pass), which already documents its scope as "semantic violations that are not type errors" (seecore/inference/src/lib.rsline 518-523). Theanalyze()function is currently a no-op stub.core/analysis/crate is created (likely alongside return-path analysis, which is already tracked as a known issue)ArrayLiteralAsArgument:core/type-checker/src/errors.rsline 448, checked at 3 argument validation sites intype_checker.rsArrayReturnCallInExpressionPosition:core/type-checker/src/errors.rsline 458, checked at 6 sites intype_checker.rs