Skip to content

Support composite types in Any-typed contexts#677

Merged
MikaelMayer merged 12 commits intomainfrom
composite-any-bridge
Mar 26, 2026
Merged

Support composite types in Any-typed contexts#677
MikaelMayer merged 12 commits intomainfrom
composite-any-bridge

Conversation

@MikaelMayer
Copy link
Copy Markdown
Contributor

@MikaelMayer MikaelMayer commented Mar 26, 2026

The pipeline crashes with a type unification error when a composite value flows into an Any-typed position (e.g., str(e) on an exception object in a try/except handler).

This PR fixes the issue by:

  1. Generating $composite_to_string_<type> and $composite_to_string_any_<type> functions for each composite type. These take a composite parameter, so heap parameterization naturally adds a Heap dependency — preventing the verifier from unsoundly assuming referential transparency for str() calls across heap mutations.

  2. When str() is called on a composite-typed variable (e.g., str(e) where e: PythonError), the translation emits $composite_to_string_any_<Type>(e) instead of to_string_any(e), keeping the composite type and routing through the heap-aware function.

Existing tests pass. New test added for try/except with str(e) on PythonError.

@MikaelMayer MikaelMayer force-pushed the composite-any-bridge branch from fb34ab8 to bbdfcf4 Compare March 26, 2026 18:25
Generate composite_to_string_<composite> functions for each composite type.
These take a composite parameter so heap parameterization naturally adds
heap dependency, preventing unsound referential transparency assumptions
for str() calls across heap mutations.

Update exception handler translation to type exception variables as Any
instead of PythonError composite, and assign them via exception(maybe_except).
@MikaelMayer MikaelMayer force-pushed the composite-any-bridge branch from bbdfcf4 to 4202941 Compare March 26, 2026 18:27
@MikaelMayer

This comment was marked as resolved.

@MikaelMayer MikaelMayer force-pushed the composite-any-bridge branch from a93104d to 079c832 Compare March 26, 2026 19:08
@MikaelMayer

This comment was marked as resolved.

@MikaelMayer

This comment was marked as resolved.

@MikaelMayer MikaelMayer marked this pull request as ready for review March 26, 2026 20:29
@MikaelMayer MikaelMayer requested a review from a team March 26, 2026 20:29
@joscoh
Copy link
Copy Markdown
Contributor

joscoh commented Mar 26, 2026

Please remove the extra added files (e.g. LLM review)

joscoh
joscoh previously approved these changes Mar 26, 2026
@MikaelMayer
Copy link
Copy Markdown
Contributor Author

Extracted compositeToStringName and compositeToStringAnyName helpers to avoid hardcoding the name in multiple places.

joscoh
joscoh previously approved these changes Mar 26, 2026
@MikaelMayer MikaelMayer enabled auto-merge March 26, 2026 21:22
Copy link
Copy Markdown
Contributor

@joehendrix joehendrix left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it'd be worth addressing both of these.

@MikaelMayer MikaelMayer disabled auto-merge March 26, 2026 21:36
@MikaelMayer MikaelMayer dismissed stale reviews from thanhnguyen-aws and joscoh via 100003a March 26, 2026 21:47
@MikaelMayer MikaelMayer enabled auto-merge March 26, 2026 21:59
@MikaelMayer MikaelMayer added this pull request to the merge queue Mar 26, 2026
Merged via the queue into main with commit 003ead4 Mar 26, 2026
15 checks passed
@MikaelMayer MikaelMayer deleted the composite-any-bridge branch March 26, 2026 22:41
olivier-aws pushed a commit that referenced this pull request Mar 30, 2026
The pipeline crashes with a type unification error when a composite
value flows into an `Any`-typed position (e.g., `str(e)` on an exception
object in a `try/except` handler).

This PR fixes the issue by:

1. Generating `$composite_to_string_<type>` and
`$composite_to_string_any_<type>` functions for each composite type.
These take a composite parameter, so heap parameterization naturally
adds a `Heap` dependency — preventing the verifier from unsoundly
assuming referential transparency for `str()` calls across heap
mutations.

2. When `str()` is called on a composite-typed variable (e.g., `str(e)`
where `e: PythonError`), the translation emits
`$composite_to_string_any_<Type>(e)` instead of `to_string_any(e)`,
keeping the composite type and routing through the heap-aware function.

Existing tests pass. New test added for try/except with `str(e)` on
PythonError.
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.

4 participants