Better namespace handling in generated code / ModuleDefs

[kazimuth]

Consider this contrived module.

use spacetime::*;

pub mod gems {
    use super::*;

    #[derive(SpacetimeType)]
    pub enum Gem {
        Diamond,
        WorthlessGlass,
    }

    #[derive(SpacetimeType)]
    pub struct Inventory(Vec<Gem>);
}

pub mod fruit {
    use super::*;

    #[derive(SpacetimeType)]
    pub enum Fruit {
        Apple,
        Banana,
    }

    #[derive(SpacetimeType)]
    pub struct Inventory(Vec<Fruit>);
}

#[spacetimedb(table(public))]
pub struct Person {
    #[primarykey]
    #[autoinc]
    id: u32,
    name: String,
    age: u8,
    gems: gems::Inventory,
    fruit: fruit::Inventory,
}

I believe this module will compile and upload fine. However, if you attempt to generate a client for it, the client will have compile errors.

This is because of how type names are registered on ModuleDef. Types implement SpacetimeType::make_type which calls the TypespaceBuilder::add method. They call this with their name, which is a single identifier, not a sequence of identifiers.

So, both Inventory structs above will register themselves with exactly the same name, Inventory. This may result in name collisions when you generate a client.

[gefjon]

"Compile and upload fine" seems like a strong claim. I don't think it will eagerly error during publish, but neither do I think it will result in a functioning module/db.