[zeek/spicy] 959004: Fix unresolved struct `self` in replacement

[Evan Typanski]

Branch: refs/heads/topic/etyp/fp-cycle-type
Home: https://github.com/zeek/spicy
Commit: 959004ec78a56b6f5e2e2a4cbf43dff48c7201ea
https://github.com/zeek/spicy/commit/959004ec78a56b6f5e2e2a4cbf43dff48c7201ea
Author: Evan Typanski <evan.t...@corelight.com>
Date: 2026-07-15 (Wed, 15 Jul 2026)

Changed paths:
M hilti/toolchain/src/compiler/optimizer/passes/dead-code-cfg.cc
M tests/Baseline/hilti.cfg.dead-write-shadowed/output
M tests/Baseline/hilti.cfg.unreachable-return/output
M tests/Baseline/hilti.optimization.dataflow-unreachable/output
M tests/Baseline/hilti.optimization.unreachable-code/log
M tests/Baseline/spicy.optimization.default-parser-functions/log
M tests/Baseline/spicy.optimization.feature_requirements/log
M tests/Baseline/spicy.optimization.unused-functions/log
M tests/Baseline/spicy.optimization.unused-types/log
A tests/hilti/optimization/dead-code-cfg-resolve.hlt

Log Message:
-----------
Fix unresolved struct `self` in replacement

If a hilti struct got the local decl replaced by its RHS when removing
the dead store, the new RHS would not be resolved. This would mean that
`self` does not properly resolve anymore. Instead, make sure the RHS gets
resolved if anything is replaced.

This would trigger an internal error between optimizer passes, with an
AST dump of the offending node first:

[internal-error] declaration without canonical ID found: self


Commit: 59be0d17655f3da238f157043cac991a131cf1d5
https://github.com/zeek/spicy/commit/59be0d17655f3da238f157043cac991a131cf1d5
Author: Evan Typanski <evan.t...@corelight.com>
Date: 2026-07-15 (Wed, 15 Jul 2026)

Changed paths:
M hilti/toolchain/src/compiler/type-unifier.cc
A tests/spicy/types/function/cycle-params.spicy

Log Message:
-----------
Fix FP cycle in types with sequential, same types

Fixes #2433

This would cause an error:

cycle detected in definition of type 'Test::S'

Since there's logic for QualifiedTypes to use the unification if it
exists, the operand list should use it, too. Before, it would always
use the unqualified check (with the occurs check), which meant that it
would report cycles for sequential types that were the same (ie two
parameters with the same struct type).


Compare: https://github.com/zeek/spicy/compare/b7c1a8e8038b...59be0d17655f

To unsubscribe from these emails, change your notification settings at https://github.com/zeek/spicy/settings/notifications