package claro.module_system.module_serialization

Get desktop application:
View/edit binary Protocol Buffers messages

Next id: 15

• optional SerializedClaroModule.UniqueModuleDescriptor module_descriptor = 1

• repeated string command_line_args = 9

  In order for this build to be repeatable (or perhaps, in the future, statically analyzed in some way), here are the exact command line args that were passed to the compiler to build this module.

• optional SerializedClaroModule.ExportedTypeDefinitions exported_type_definitions = 2

  This is essentially a serialized symbol table containing just the newtypes and aliases exported by this module.

• repeated string exported_atom_definitions = 3

• optional SerializedClaroModule.ExportedFlagDefinitions exported_flag_definitions = 13

• repeated SerializedClaroModule.ExportedStaticValue exported_static_values = 12

• repeated SerializedClaroModule.Procedure exported_procedure_definitions = 4

• repeated SerializedClaroModule.ExportedContractDefinition exported_contract_definitions = 10

• repeated SerializedClaroModule.ExportedContractImplementation exported_contract_implementations = 11

• repeated SerializedClaroModule.ExportedHttpServiceDefinition exported_http_service_definitions = 5

• repeated SerializedClaroModule.ExportedTransitiveDepModule exported_transitive_dep_modules = 6

  Exported transitive types are types that are actually defined by this Module's deps but referenced in the exported procedures/types of this Module's api. This is necessary to communicate explicitly what types are being talked about here, as this is technically ambiguous from looking at the api file alone as readers couldn't know what concrete deps the module was compiled against. This field resolves that ambiguity by specifying the concrete disambiguator for each exported transitive type.

• bytes static_java_codegen = 7

  This field contains the codegen pertaining to any static definitions that are guaranteed to be provided by this module. In less opaque terms, this contains codegen for any non-generic procedure definitions that are exported by this module. This *does not* include any codegen for generic procedure monomorphizations (except for those monomorphizations that are explicitly called from exported procedures *within* this module). Later on, when this module is depended on in a Claro Binary, the concrete monomorphizations needed by the overall will be codegen'd at the last minute.

• repeated SerializedClaroModule.ClaroSourceFile module_impl_files = 8

  As Claro will need to postpone codegen of generic procedure monomorphizations until after the entire program is assembled into a Claro Binary, this serialized module actually needs to maintain the original Claro source files that contain all exported procedure implementations. This way, once all concrete monomorphizations are known, it's possible to re-parse the source file to find the necessary generic procedure defs to codegen monomorphizations for.

• map<string, SerializedClaroModule.CodegendMonomorphizationsList> codegend_monomorphizations_transitive_closure_by_unique_module_name = 14

  Mapping of the transitive closure of all monomorphizations already codegen'd by this module and its entire dep graph. This will be used by any compilation unit depending on this module to determine when it's safe to completely short-circuit codegen of monomorphizations that will certainly already be included in the final Jar by depending on this module. This should have a significant compile-time performance benefit while not having any effect on the running program.

Used in: SerializedClaroModule

• string original_filename = 1

• bytes source_utf8 = 2

Used in: SerializedClaroModule

• repeated CodegendMonomorphizationsList.CodegendMonomorphization monomorphizations = 1

Used in: CodegendMonomorphizationsList

• string procedure_name = 1

  The name of the generic procedure for which monomorphization is being requested.

• repeated claro_types.TypeProto concrete_type_params = 2

  The ordered list of concrete types the procedure's generic type params are being bound to.

Used in: SerializedClaroModule

• string name = 1

• repeated string type_param_names = 2

• repeated Procedure signatures = 3

Used in: SerializedClaroModule

• string implemented_contract_name = 1

• repeated claro_types.TypeProto concrete_type_params = 2

• repeated Procedure concrete_signatures = 3

  Strictly speaking, these concrete signatures should be derivable from the signatures listed in the contract definition itself. However, as that would require some significantly complex logic to be duplicated, I'm making the design decision to instead directly encode the concrete signatures to just decode them instead of re-derive them from scratch.

Used in: SerializedClaroModule

• repeated ExportedFlagDefinitions.ExportedFlag direct_exported_flags = 1

  These are the flags actually directly exported by this module. These are separated out from the transitive flags literally just to enable ClaroDocs to correctly attribute flags to their defining module.

• map<string, ExportedFlagDefinitions.ExportedFlagsList> transitive_exported_flags_by_defining_module = 2

  These are the flags exported by the transitive closure of all of this module's deps. These need to be collected in order for Claro to collect them all at the top-level claro_binary() to codegen parsing logic.

Used in: ExportedFlagDefinitions, ExportedFlagsList

• string name = 1

• optional claro_types.TypeProto type = 2

Used in: ExportedFlagDefinitions

• repeated ExportedFlag flags = 1

Used in: SerializedClaroModule

• string http_service_name = 1

• repeated ExportedHttpServiceDefinition.Endpoint endpoints = 2

Used in: ExportedHttpServiceDefinition

• string endpoint_name = 1

• string path = 2

• optional Procedure procedure = 3

Used in: SerializedClaroModule

• string name = 1

• optional claro_types.TypeProto type = 2

• bool is_lazy = 3

This message breaks down an exported transitive dep type as follows: For the type reference `FooDep::SomeType` in a .claro_module_api file: - module_name = "FooDep" - unique_module_name = "src$com$some$concrete$dep$module" - this is assuming tha the concrete claro_module() dep implementing FooDep::SomeType is located at the bazel - path "//src/com/some/concrete/dep:module".

Used in: SerializedClaroModule

• string module_name = 1

• string unique_module_name = 2

Used in: SerializedClaroModule

• map<string, claro_types.TypeProto> exported_alias_defs_by_name = 1

• map<string, ExportedTypeDefinitions.NewTypeDef> exported_newtype_defs_by_name = 2

• map<string, ExportedTypeDefinitions.ProcedureList> initializers_by_type_name = 3

• map<string, ExportedTypeDefinitions.ProcedureList> unwrappers_by_type_name = 4

Used in: ExportedTypeDefinitions

• optional claro_types.UserDefinedType user_defined_type = 1

• optional claro_types.TypeProto wrapped_type = 2

• repeated string type_param_names = 3

• optional Procedure constructor = 4

Literally just a simple wrapper type in order to have a map with list values.

Used in: ExportedTypeDefinitions

• repeated Procedure procedures = 1

Used in: SerializedClaroModule, ExportedContractDefinition, ExportedContractImplementation, ExportedHttpServiceDefinition.Endpoint, ExportedTypeDefinitions.NewTypeDef, ExportedTypeDefinitions.ProcedureList

• string name = 1

• oneof procedure_type

  • claro_types.FunctionType function = 2

  • claro_types.ConsumerType consumer = 3

  • claro_types.ProviderType provider = 4

Used in: SerializedClaroModule

• string project_package = 1

  Claro doesn't utilize a "package visibility" system like Java does, instead it assumes that you'll control code visibility using Bazel's builtin target visibility controls. However, it does need some mechanism for ensuring that cross-project .claro_modules do not produce artifacts that collide in the same Java namespace. So, Claro will utilize a concept of "project package" as a global (internet-wide) disambiguator. When building using Claro's Bazel rules, this string will be automatically derived from the Bazel workspace's name. This is in an effort towards utilizing Bazel's native Bazelmod as Claro's "package manager".

• string unique_module_name = 2

  When building using Claro's Bazel rules, this string will be automatically formatted to be something like `examples$claro_programs$module_test` for a `claro_module(name = "module_test", ...)` located at the bazel path //examples/claro_programs:module_test. This ensures that this Module name is unique across the entire Bazel project in which this module is being compiled.