feat: Add constraints via Jinja expressions

[imalsogreg]

Important

This PR adds support for constraints using Jinja expressions, updates models and validation logic, and enhances testing to ensure constraint functionality across the codebase.

• Constraints:
  • Add Jinja expression support for constraints in baml-core.
  • Implement evaluate_predicate in internal_baml_jinja for constraint evaluation.
  • Update FieldType to support Constrained type with constraints.
• Models:
  • Add Constraint and ConstraintLevel in baml-types.
  • Update NodeAttributes to include constraints.
• Validation:
  • Add validation for constraints in validation_pipeline.
  • Ensure constraints are not allowed as function parameters.
• Testing:
  • Add tests for constraints in test_constraints.rs.
  • Update integration tests to check constraint functionality.
• Misc:
  • Add itertools dependency in Cargo.lock.
  • Update shell.nix to include necessary tools for development.

^{This description was created by for fa53e49. 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)			Oct 23, 2024 6:05am

[ellipsis-dev]

👍 Looks good to me! Reviewed everything up to 2898a39 in 3 minutes and 9 seconds

More details

• Looked at 8495 lines of code in 121 files
• Skipped 1 files when reviewing.
• Skipped posting 1 drafted comments based on config settings.

1. engine/baml-lib/baml-core/src/validate/validation_pipeline/validations/types.rs:87

• Draft comment:
  Consider handling errors in validate_type_constraints more gracefully instead of panicking. Provide a meaningful error message to the user if a constraint is not well-formed.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable:
  The comment seems to be suggesting an improvement that is already implemented. The function uses ctx.push_error to handle errors, which is a standard way to report issues without panicking. The comment does not provide strong evidence of an issue that needs addressing.
  I might be missing some context about how errors are handled in the broader system. Perhaps the comment is suggesting a different kind of error handling that is not evident from the code alone.
  The code clearly shows that errors are being handled by pushing them to the context, which is a common pattern for non-panicking error handling. Without additional context, the comment seems unnecessary.
  The comment should be deleted as it suggests an improvement that is already implemented in the code.

Workflow ID: wflow_yxofyQgVkFL7G1Cc

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[ellipsis-dev]

👍 Looks good to me! Incremental review on 82a19f0 in 2 minutes and 49 seconds

More details

• Looked at 8722 lines of code in 124 files
• Skipped 1 files when reviewing.
• Skipped posting 2 drafted comments based on config settings.

1. engine/baml-lib/baml-core/src/ir/ir_helpers/to_baml_arg.rs:343

• Draft comment:
  Consider handling the error explicitly instead of using unwrap_or_else in evaluate_predicate to avoid unexpected behavior.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable:
  The use of unwrap_or_else is a common pattern in Rust for handling errors in a concise way. The current implementation pushes an error message to the scope, which seems to be an appropriate way to handle errors in this context. The comment suggests an alternative approach but does not provide strong evidence that the current approach is incorrect or causes unexpected behavior.
  The comment does not provide specific reasons why the current use of unwrap_or_else would lead to unexpected behavior. It is more of a suggestion than a necessary change.
  While the comment suggests an alternative, it does not demonstrate that the current implementation is problematic. Without evidence of an issue, the comment may not be necessary.
  The comment is more of a suggestion than a necessary change, and there is no strong evidence that the current implementation is incorrect. Therefore, the comment should be deleted.

2. engine/baml-lib/baml-core/src/ir/ir_helpers/to_baml_arg.rs:340

• Draft comment:
  Consider handling the error explicitly instead of using unwrap_or_else to avoid unexpected behavior.
• Reason this comment was not posted:
  Marked as duplicate.

Workflow ID: wflow_gHUOxKuHoqrWS0ME

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[ellipsis-dev]

👍 Looks good to me! Incremental review on 8320347 in 1 minute and 12 seconds

More details

• Looked at 34 lines of code in 2 files
• Skipped 0 files when reviewing.
• Skipped posting 1 drafted comments based on config settings.

1. engine/language_client_codegen/src/ruby/generate_types.rs:175

• Draft comment:
  Ensure that the removal of checks_type_ref from the format! function is consistent with the intended functionality of Baml::Checked. Verify that Baml::Checked is designed to only take base_type_ref.
• Reason this comment was not posted:
  Comment did not seem useful.

Workflow ID: wflow_VBsSSWl6hKXQCcmF

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[imalsogreg]

• stabilize order of type literals
• cleanup
• rebase

[ellipsis-dev]

👍 Looks good to me! Incremental review on edd98f8 in 1 minute and 13 seconds

More details

• Looked at 502 lines of code in 20 files
• Skipped 0 files when reviewing.
• Skipped posting 1 drafted comments based on config settings.

1. integ-tests/typescript/baml_client/types.ts:265

• Draft comment:
  The order of the literals in the Checked type for species has been changed. Ensure that this change is intentional and does not affect any logic that depends on the order of these literals.
• Reason this comment was not posted:
  Confidence changes required: 50%
  The test report indicates that all tests have passed, which is a good sign. However, the code changes should still be reviewed for potential issues.

Workflow ID: wflow_rWGLfcLI7GSFcpTW

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[ellipsis-dev]

👍 Looks good to me! Incremental review on c04aa26 in 2 minutes and 42 seconds

More details

• Looked at 9636 lines of code in 127 files
• Skipped 1 files when reviewing.
• Skipped posting 3 drafted comments based on config settings.

1. engine/baml-lib/baml-core/src/ir/jinja_helpers.rs:13

• Draft comment:
  Consider logging or handling the error when regex compilation fails in regex_match to provide more context for debugging.
• Reason this comment was not posted:
  Confidence changes required: 50%
  The function regex_match in jinja_helpers.rs returns false if the regex compilation fails. It would be better to log or handle this error to provide more context for debugging.

2. engine/baml-lib/baml-core/src/ir/jinja_helpers.rs:14

• Draft comment:
  Consider logging or handling the error from Regex::new instead of returning false, to avoid silently ignoring regex compilation errors.
• Reason this comment was not posted:
  Confidence changes required: 50%
  The function regex_match in jinja_helpers.rs does not handle errors from Regex::new properly. It returns false on error, which might hide issues. It should log or handle the error appropriately.

3. engine/baml-lib/baml-core/src/ir/jinja_helpers.rs:15

• Draft comment:
  Consider logging or handling the regex compilation error instead of silently returning false.
• Reason this comment was not posted:
  Confidence changes required: 50%
  The function regex_match in jinja_helpers.rs returns false if the regex compilation fails. It might be more informative to log or handle this error differently.

Workflow ID: wflow_fCgKpMEyC64QxDxr

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[ellipsis-dev]

👍 Looks good to me! Incremental review on 508703e in 1 minute and 17 seconds

More details

• Looked at 62 lines of code in 4 files
• Skipped 0 files when reviewing.
• Skipped posting 2 drafted comments based on config settings.

1. engine/language_client_codegen/src/python/generate_types.rs:172

• Draft comment:
  The use of sorted() here may not be necessary and could alter the intended order of checks. Consider removing it if order matters.
• Reason this comment was not posted:
  Confidence changes required: 50%
  The use of sorted() in the type_name_for_checks function is unnecessary since the order of checks might be intentional and should be preserved.

2. engine/language_client_codegen/src/typescript/generate_types.rs:128

• Draft comment:
  The use of sorted() here may not be necessary and could alter the intended order of checks. Consider removing it if order matters.
• Reason this comment was not posted:
  Confidence changes required: 50%
  The use of sorted() in the type_name_for_checks function is unnecessary since the order of checks might be intentional and should be preserved.

Workflow ID: wflow_g2nkzvVNfT2STDtw

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[ellipsis-dev]

❌ Changes requested. Incremental review on fa53e49 in 2 minutes and 55 seconds

More details

• Looked at 9578 lines of code in 126 files
• Skipped 1 files when reviewing.
• Skipped posting 3 drafted comments based on config settings.

1. engine/baml-lib/baml-core/src/ir/ir_helpers/mod.rs:185

• Draft comment:
  Consider using Result::Err with a custom error type instead of anyhow::bail! for better performance, as anyhow::bail! captures a backtrace which can be expensive.
• Reason this comment was not posted:
  Confidence changes required: 50%
  The use of anyhow::bail! and anyhow::anyhow! for error handling is not ideal for performance. These macros can be expensive because they capture a backtrace. It's better to use Result::Err with a custom error type when performance is a concern.

2. engine/baml-lib/baml-core/src/ir/jinja_helpers.rs:15

• Draft comment:
  Consider returning an error instead of false when regex compilation fails to avoid silently ignoring issues.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable:
  The comment is suggesting a change in error handling strategy, which is a valid code quality improvement. Returning an error instead of false would make the function's behavior more explicit and prevent silent failures. This is a clear and actionable suggestion.
  The current implementation might be intentionally designed to return false on error to simplify usage. Without more context on how this function is used, it's hard to say if changing the error handling is appropriate.
  Even if the current design is intentional, the suggestion to handle errors explicitly is a common best practice and could improve code robustness.
  The comment is a valid suggestion for improving error handling in the regex_match function. It should be kept as it proposes a clear and actionable code quality improvement.

3. engine/baml-lib/baml-core/src/ir/jinja_helpers.rs:33

• Draft comment:
  Remove the eprintln! statement or replace it with a proper logging mechanism.
• Reason this comment was not posted:
  Marked as duplicate.

Workflow ID: wflow_thp3vrb5WlJ3JqFn

---

Want Ellipsis to fix these issues? Tag @ellipsis-dev in a comment. You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[ellipsis-dev]

Remove the eprintln! statement or replace it with proper logging.