* Remove ModuleCompiledFunction The same information can be retrieved using ctx.compiled_code().unwrap().code_info().total_size In addition for Module implementations that don't immediately compile the given function there is no correct value that can be returned. * Don't give anonymous functions and data objects an internal name This internal name can conflict if a module is serialized and then deserialized into another module. It also wasn't used by any of the Module implementations anyway. * Allow serializing all cranelift-module data structures This allows a Module implementation to serialize it's internal state and deserialize it in another compilation session. For example to implement LTO or to load the module into cranelift-interpreter. * Use expect
This crate provides module-level functionality, which allow multiple functions and data to be emitted with Cranelift and then linked together.
This crate is structured as an optional layer on top of cranelift-codegen. It provides additional functionality, such as linking, however users that require greater flexibility don't need to use it.
A module is a collection of functions and data objects that are linked
together. The Module trait that defines a common interface for various kinds
of modules. Most users will use one of the following Module implementations:
JITModule, provided by cranelift-jit, which JITs code to memory for direct execution.ObjectModule, provided by cranelift-object, which emits native object files.