Thanks to visit codestin.com
Credit goes to github.com

Skip to content

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
merged 111 commits into from
Jun 7, 2022
Merged

Internal change #155

merged 111 commits into from
Jun 7, 2022

Conversation

kyessenov
Copy link
Collaborator

@kyessenov kyessenov commented Jun 6, 2022

Internal change

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
CEL Dev Team and others added 27 commits June 6, 2022 23:55
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
PiperOrigin-RevId: 433368987
PiperOrigin-RevId: 433487364
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
jcking and others added 23 commits June 7, 2022 00:04
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
…sn't include any reflection utilities or assume that values are implementing the full message interface.

PiperOrigin-RevId: 446305046
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
@kyessenov kyessenov changed the title Add CEL/C++ support for hermetic descriptor pools Internal change Jun 7, 2022
@kyessenov
Copy link
Collaborator Author

FYI GCC warning logs.

@kyessenov kyessenov added the cla: yes CLA present label Jun 7, 2022
@kyessenov kyessenov merged commit 1e0fd3d into master Jun 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla: yes CLA present
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants