-
Notifications
You must be signed in to change notification settings - Fork 60
Internal change #155
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Internal change #155
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
So far, CEL C++ always used only the generated descriptor pool (and message factory). This means only protos that are compiled into the binary using CEL can be used. In our scenario, we have a database providing certain entities that can be added in our system at run-time and which use proto to describe output data. We want to use CEL to formulate expressions over this output. Since we know only at run-time what protos these are, we need to create a hermtic descriptor pool and dynamic message factory for that transitively closed file descriptor set. This CL adds the capability to CEL/C++ to use a custom descriptor poold and message factory. From the users' perspective this is entirely optional and the generated descriptor pool and message factory will be used if not explicitly overridden. PiperOrigin-RevId: 427701926
Allow users to register non-strict functions, which are functions that could take `CelError` or `UnknownSet` as arguments. - Add a field `is_strict` to `CelFunctionDescriptor`. - Change `CelFunctionRegistry` so that it ensure if the function has any non-strict overload, it has only one overload. - Modify `IsNonStrict` in `function_step.cc` to check `is_strict` field. PiperOrigin-RevId: 427817399
PiperOrigin-RevId: 428042273
PiperOrigin-RevId: 428518876
PiperOrigin-RevId: 428531745
PiperOrigin-RevId: 428545658
PiperOrigin-RevId: 428639120
…nstead of directly using proto2::Arena api. PiperOrigin-RevId: 429366046
PiperOrigin-RevId: 429395768
…sible. This helps move toward making proto2::arena an optional dependency and enabling alternative memory management strategies. PiperOrigin-RevId: 430473093
…traction. Update create map step to use builder allocated by the memory manager. PiperOrigin-RevId: 431842547
PiperOrigin-RevId: 431990497
PiperOrigin-RevId: 432018873
PiperOrigin-RevId: 432468397
… for implementations of comparison operations. PiperOrigin-RevId: 432540100
PiperOrigin-RevId: 433227593
…key lookups. PiperOrigin-RevId: 433308944
PiperOrigin-RevId: 433349120
PiperOrigin-RevId: 433368987
PiperOrigin-RevId: 433487364
PiperOrigin-RevId: 433489389
AddStandardMessageTypesToDescriptorPool() cannot be called on descriptor pools backed by a database. Yet users may need to add the relevant types. The new function GetStandardMessageTypesFileDescriptorSet() gives a file descriptor set of those types so that users can add those by themselves. PiperOrigin-RevId: 433757758
The json_name field of the FieldDescriptorProto may be set differently (or not at all) depending on the compiler used. We saw differences in just this field leading to the differencer detecting a difference, but the messages would still be compatible. Hence ignore this field. PiperOrigin-RevId: 433757941
PiperOrigin-RevId: 433865216
PiperOrigin-RevId: 434537767
…onality to cel::Types. This introduces a transitional API to refactor the evaluator to be structurally compatible with new Type APIs without forcing a swap to the new type system. PiperOrigin-RevId: 435127247
PiperOrigin-RevId: 435418602
… messages based on the configured descriptor pool. PiperOrigin-RevId: 435544477
PiperOrigin-RevId: 446193337
PiperOrigin-RevId: 446214501
…example type provider and legacy type adapters. PiperOrigin-RevId: 446302462
…pe adapters instead of directly consulting a proto DescriptorPool. PiperOrigin-RevId: 446304673
PiperOrigin-RevId: 446304791
…ion steps. PiperOrigin-RevId: 446304898
…sn't include any reflection utilities or assume that values are implementing the full message interface. PiperOrigin-RevId: 446305046
PiperOrigin-RevId: 446484239
…tion adapter. PiperOrigin-RevId: 446514900
PiperOrigin-RevId: 447089041
PiperOrigin-RevId: 448029301
PiperOrigin-RevId: 448302268
PiperOrigin-RevId: 448308815
PiperOrigin-RevId: 449819425
PiperOrigin-RevId: 450063543
PiperOrigin-RevId: 450776472
…ls when underlying std::unique_ptr<*> is unset. PiperOrigin-RevId: 451211992
PiperOrigin-RevId: 451524495
… native type representations of the AST. PiperOrigin-RevId: 452047564
PiperOrigin-RevId: 453225470
PiperOrigin-RevId: 453261653
PiperOrigin-RevId: 453272140
PiperOrigin-RevId: 453300107
FYI GCC warning logs. |
TristonianJones
approved these changes
Jun 7, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Internal change