Add dynamic and streaming-mode data to FieldType

[ba11b0y]

Important

Add dynamic and streaming-mode data to FieldType by modifying TypeGeneric and updating partialize function to handle new fields.

• Behavior:
  • Add dynamic and mode fields to Enum and Class variants in TypeGeneric in mod.rs.
  • Introduce StreamingMode enum in mod.rs to represent streaming states.
  • Update partialize function in mod.rs to handle new dynamic and mode fields.
• Functions:
  • Modify is_type() in baml_value.rs to check dynamic and mode fields.
  • Update partialize_helper() in mod.rs to apply streaming behavior based on dynamic and mode.
• Tests:
  • Add tests for partialize function in mod.rs to verify handling of dynamic and mode fields.
• Misc:
  • Update r#enum() and class() in builder.rs to initialize dynamic and mode fields.

^{This description was created by for 076ed75. You can customize this summary. It will automatically update as commits are pushed.}

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
baml	❌ Failed (Inspect)			Jun 2, 2025 5:29pm

[ellipsis-dev]

Caution

Changes requested ❌

Reviewed everything up to 076ed75 in 2 minutes and 28 seconds. Click for details.

• Reviewed 602 lines of code in 4 files
• Skipped 0 files when reviewing.
• Skipped posting 3 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. engine/baml-lib/baml-types/src/ir_type/mod.rs:738

• Draft comment:
  Consider adding clarifying comments in the partialize function’s optional-wrapping branch (lines 739–748) to explain the metadata swap logic and why the inner metadata is reset before wrapping the type as optional.
• Reason this comment was not posted:
  Confidence changes required: 50% <= threshold 50% None

2. engine/baml-lib/baml-types/src/baml_value.rs:450

• Draft comment:
  Typographical issue: the condition enum_value == enum_value compares the same variable to itself. It appears that this may be a mistake; consider verifying if it should instead compare the enum_value from BamlValueWithMeta::Enum with a corresponding value from the FieldType::Enum variant.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50% Looking at the code more carefully, the left enum_value comes from the BamlValueWithMeta::Enum variant (line 449) while the right enum_value is a pattern variable from the FieldType::Enum match pattern (line 450). These are actually two different variables that happen to have the same name, not the same variable being compared to itself. The comment is incorrect. Could there be a reason why comparing enum values is important for type checking? Could removing this check break something? Yes, comparing enum values is important - an enum type check should verify both the enum name and value match. Removing the value comparison would make the type checking too permissive. The comment is incorrect - this is not comparing a variable to itself, but rather comparing two different enum values that happen to have the same variable name. The comparison is intentional and correct.

3. engine/baml-lib/baml-types/src/ir_type/mod.rs:196

• Draft comment:
  Typographical issue: It looks like there's a missing comma after the block for the UnionTypeViewGeneric::OneOf(field_types) match arm. Please add a trailing comma after the closing brace to separate it correctly from the following arm.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While consistent comma style can be nice, this is a very minor stylistic issue. The code works perfectly fine without the trailing comma. The Rust compiler doesn't require it. This kind of minor style nitpick creates noise in PR reviews and distracts from more important issues. Additionally, many teams use automated formatters like rustfmt which would handle this automatically if it was part of their style guide. Could inconsistent comma style lead to git diff noise in future changes? Could it violate team style guidelines? Even if there are style guidelines, this is better handled by automated tools like rustfmt rather than manual PR comments. The potential git diff impact is minimal for such a small style issue. This comment should be deleted as it's too minor of a style issue to warrant a PR comment. Style consistency is better handled by automated tools.

Workflow ID: wflow_CLpG6BwG2WRw5Zxw

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[ellipsis-dev]

Bug: In the Enum arm of is_type, the condition uses enum_value == enum_value which always evaluates to true. Likely this should compare the stored enum value against an expected value from the field type (or simply be removed).

Suggested change

	FieldType::Enum { name: enm, .. } => enum_name == enm && enum_value == enum_value,
	FieldType::Enum { name: enm, .. } => enum_name == enm,