feat: export hash map reference

Summary

This PR adds the ability to export a reference to a hash map field. So far only HashMap<u8, u8> has been tested in order to have the generals worked out. More types will be added later as this PR is now large enough :)

First Use of Recursive rid Macro Expansion

In order to allow iterating the keys of the hash_map we use the first case of applying [rid::export] recursively. Thus this access is simply implemented by emitting the following:

let keys_impl = quote_spanned! { fn_keys_ident.span() =>
    #[rid::export]
    fn #fn_keys_ident(map: &HashMap<#key_ty, #val_ty>) -> Vec<&#key_ty> {
        map.keys().collect()
    }
};

I first tried a different route (visible from some of the commits) to fully render the method returning a RidVec and rendering the access to RidVecs via nested accesses.

However the final solution turned out to be so much simpler and basically is the first example of using rid features we can already render like a Lego piece in order to render higher level types and implementations. I plan to use this approach in more cases going forward.

Standalone Export as part of this PR

However to make this happen I had to implement standalone [rid::export]s. Up til now only exports that were part of an impl were allowed since I couldn't think of a clean way to prevent a rid::export to be rendered twice (once as part of the impl and once treated separately).

I now track exports that we rendered as an impl method and skip rendering it again, see 631701d.

Potential Future Issues

This works, but would hide a user error in which a method/function with the same name is once exported as an impl and then again as a separate method, i.e. it doesn't raise an error, but just ignores the second one, as in this example:


#[rid::export]
impl Store {
    #[rid::export]
    pub fn get_u8(&self) -> u8 {
        self.s_id
    }
}

// The below method is not exported, i.e. no rid ffi wrapper generated, nor any error/warning
// for the user is emitted.
#[rid::export]
pub fn get_u8() -> u8 {
  1 
}

If this causes lots of issues (which I don't really doubt) we'll have to take the tokens of the function into account in order to alert the user when two functions have a name colission.

Follow Up PR

As mentioned above this PR will be followed up with one that adds support for more HashMap key/val types.

Related Future Features

After that the following related features are on my radar.

support exporting HashSet, BTreeMap and BTreeSet (shouldn't be too difficult as they are very similar to HashMap
allow exporting an owned hash map, i.e. one created when calling the function (similar to what is now possible for Vecs via RidVec

However before I'll implement another sample app, this time to show off and battle test exporting HashMaps.

Commits

rid-macro: hash-map main methods working for <u8, u8>
rid-macro: separate module to render collection accesses
rid-macro: const/mut pointer alias factory methods
rid-macro: nested accesses to prepare rendering hash_map keys vec
rid-macro: rendering correct accesses for hash_map
chore: fix broken tests
rid-macro: export function takes HashMap arg
rid-macro: prototyped using rid::export to render hash_map keys access
rid-macro: separating processing and tokenizing of function export
rid-macro: removing rendering of free from export
rid-macro: supporting standalone function exports
rid_macro: ensuring that impl methods are not exported twice
test: adding function export tests for owned primitives
rid-macro: using function export for hash_map keys
test: including hash_map tests
rid-macro: removing nested accesses since no longer needed

thlorenz / rid