Mapping for Modules

Files

Files implicitly become modules in Rust. Since this is not the case for IDL, files and how they are organized does not affect the generated Rust code.

Includes

Files included by the processed IDL file will be publicly imported in the generated Rust module.

// IDL
#include "LocalInclude.idl"
#include <SystemInclude.idl>

#![allow(unused)]
fn main() {
// Rust
pub mod local_include;
pub mod system_include;
}

Note the different naming scheme: the file names were converted to snake_case.

Modules

To correctly map the scope of each IDL type, IDL modules are mapped to a hierarchy of Rust files. Given a set of IDL files, the compiler should generate the following:

• A lib.rs file suitable for being included directly from Rust crates. It should publicly include all other modules, and it should contain all global top-level definitions.
• For each IDL module, the compiler should generate a single file with the same name as the module. Type definitions that appear directly under this module should be placed in the same file.
• If a module contains nested modules, the compiler should create a directory with the parent module’s name, and put the child module inside said directory. This process should repeat for modules nested inside the child module.

// IDL
struct MyGlobalStruct {};

module my_mod {
    struct MyModStruct {};

    module my_nested_module {
        module foo {
            struct FooStruct {};
        };
    };
};

The above modules will produce the following file hierarchy:

.
├── lib.rs
├── my_mod
│   ├── my_nested_module
│   │   └── foo.rs
│   └── my_nested_module.rs
└── my_mod.rs

MyGlobalStruct will be placed inside lib.rs; MyModStruct will be placed inside my_mod.rs, and all modules nested inside my_mod will be put in the my_mod directory.