| Index: docs/intro/mojom_idl.md
|
| diff --git a/docs/intro/mojom_idl.md b/docs/intro/mojom_idl.md
|
| index bef2d445fe4d0214535314277fcaf1104c6c8347..8b49b675c0268caa95f1e9936f17203314b91e5c 100644
|
| --- a/docs/intro/mojom_idl.md
|
| +++ b/docs/intro/mojom_idl.md
|
| @@ -159,18 +159,66 @@ language-appropriate style.
|
|
|
| ### Module statement
|
|
|
| -**TODO(vtl)**
|
| +The Mojom *module* statement is just a way of logically grouping Mojom
|
| +declarations. For example:
|
| +```mojom
|
| +module my_module;
|
| +```
|
| +Mojom modules are similar to C++ namespaces (and the standard C++ code generator
|
| +would put generated code into the `my_module` namespace), in that there is no
|
| +implication that the file contains the entirety of the "module" definiton;
|
| +multiple files may have the same module statement. (There is also no requirement
|
| +that the module name have anything to do with the file path containing the Mojom
|
| +file.)
|
| +
|
| +Mojom module names are hierarchical in that they can be composed of multiple
|
| +parts separated by `.`. For example:
|
| +```mojom
|
| +module my_module.my_submodule;
|
| +
|
| +struct MyStruct {
|
| +};
|
| +```
|
| +Name look-up is similar to C++: E.g., if the current module is
|
| +`my_module.my_submodule` then `MyStruct`, `my_submodule.MyStruct`, and
|
| +`my_module.my_submodule.MyStruct` all refer to the above struct, whereas if the
|
| +current module is just `my_module` then only the latter two do.
|
|
|
| ### Import declarations
|
|
|
| -**TODO(vtl)**
|
| +An *import* declaration makes the declarations from another Mojom file available
|
| +in the current Mojom file. Moreover, it operates transitively, in the sense that
|
| +it also makes the imports of the imported file available, etc. The "argument" to
|
| +the import statement is a path to a file. Tools that work with Mojom files are
|
| +typically provided with a search path for importing files (just as a C++
|
| +compiler can be provided with an "include path"), for the purposes of resolving
|
| +these paths. (**TODO(vtl)**: This always includes the current Mojom file's path,
|
| +right? Is the current path the first path that's searched?)
|
| +
|
| +For example:
|
| +```mojom
|
| +module my_module;
|
| +
|
| +import "path/to/another.mojom";
|
| +import "path/to/yet/a/different.mojom";
|
| +```
|
| +This makes the contents of the two mentioned Mojom files available, together
|
| +with whatever they import, transitively. (Note that names are resolved in the
|
| +way described in the previous section.)
|
| +
|
| +Import cycles are not permitted (so, e.g., it would be an error if
|
| +`path/to/another.mojom` imported the current Mojom file). However, it is
|
| +entirely valid for Mojom files to be imported (transitively) multiple times
|
| +(e.g., it is fine for `path/to/another.mojom` to also import
|
| +`path/to/yet/a/different.mojom`).
|
|
|
| ### Struct declarations
|
|
|
| -A Mojom struct declaration consists of a finite sequence of *field declaration*,
|
| -each of which consists of a *type*, a *name*, and optionally a *default value*
|
| -(if applicable for the given type). (If no default value is declared, then the
|
| -default is the default value for the field type, typically 0, null, or similar.)
|
| +A Mojom *struct* declaration consists of a finite sequence of *field
|
| +declaration*, each of which consists of a *type*, a *name*, and optionally a
|
| +*default value* (if applicable for the given type). (If no default value is
|
| +declared, then the default is the default value for the field type, typically 0,
|
| +null, or similar.)
|
|
|
| Additionally, a struct may contain enum and const declarations (**TODO(vtl)**:
|
| why not struct/union/interface declarations?). While the order of the field
|
|
|