Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
feat: export hash map reference (#21)
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 :) 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: ```rs 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 `RidVec`s 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. 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. 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: ```rs 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. 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.
- Loading branch information