You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: Add runtime function overload resolution based on Type information
## Motivation
Currently, CEL-C++ only supports Type-level function overload resolution
during the type-checking phase, while runtime function dispatch is limited
to Kind-level resolution. This limitation prevents runtime selection of
the most appropriate function overload when dealing with complex type
hierarchies or when type information is available but not fully determined
during static analysis.
As described in issue #1484, the FunctionRegistry cannot distinguish overloads
differing only by container parameter types (e.g., `list<int>` vs `list<string>`)
because the current implementation only compares `cel::Kind` rather than precise
`cel::Type` information during function registration and dispatch.
## Objective
Enable runtime function overload resolution based on precise Type information
by propagating overload IDs from the type-checking phase to the runtime
execution phase. This enhancement allows the runtime to make more informed
decisions about which function overload to invoke, improving both correctness
and performance in scenarios where multiple overloads are available.
## Implementation
### Core Changes
1. **Enhanced Function Interface**
- Extended `Function::Invoke()` method signature to accept an optional
`overload_id` parameter (`absl::Span<const std::string>`) with default empty value
- Updated all function adapter classes (Nullary, Unary, Binary, Ternary, Quaternary)
to propagate overload ID information
- Modified `CelFunction` implementation to support the new interface
2. **FlatExpr Builder Integration**
- Added `reference_map_` field to `FlatExprVisitor` to access type-checking
reference information during expression compilation
- Implemented `FindReference()` helper method to retrieve overload IDs
associated with specific expressions
- Updated `CreateFunctionStep()` and `CreateDirectFunctionStep()` calls
to pass overload ID information from the reference map
- Added default parameter values to maintain backward compatibility
3. **Function Step Enhancement**
- Extended `AbstractFunctionStep` constructor to accept overload IDs with move semantics
- Updated both eager (`EagerFunctionStep`) and lazy (`LazyFunctionStep`)
function step implementations to store overload ID information
- Modified direct execution steps (`DirectFunctionStepImpl`) to store
and utilize overload ID information
- Enhanced the `Invoke()` helper function to pass overload IDs to the
underlying function implementation
### Technical Details
- **Backward Compatibility**: All function creation methods provide default
empty overload ID parameters, ensuring existing code continues to work
without modification
## Benefits
1. **Enhanced Precision**: Runtime can select optimal function overloads
based on complete type information rather than just value kinds
2. **Better Performance**: Reduced need for runtime type checks and
fallback mechanisms when precise overload information is available
3. **Improved Extensibility**: Framework for future enhancements requiring
type-aware runtime behavior
4. **Maintained Compatibility**: All existing functionality preserved
while adding new capabilities
5. **Resolves Container Type Disambiguation**: Enables proper handling of
function overloads that differ only in container element types, addressing
the "empty container" problem described in the issue
## Testing
This change maintains full API and ABI compatibility through default parameter
values. All existing tests should continue to pass without modification, and
new tests can be added to verify type-aware overload resolution behavior.
Closes#1484
0 commit comments