rune-rs / rune

An embeddable dynamic programming language for Rust.
https://rune-rs.github.io
Apache License 2.0
1.7k stars 85 forks source link

Feature request: More accurate types in generated rune API documentation #757

Closed VorpalBlade closed 1 month ago

VorpalBlade commented 1 month ago

Currently when a generic type (e.g. Option<MyCustomType>) is part of a function signature in an external function. the rune docs only show the outermost type (e.g. Option). It would be very useful to be able to see the full type.

I'm not sure how hard this would be to add, I would be interested in looking into this if this is a "relatively easy" thing.

udoprog commented 1 month ago

Might be relatively straight forward albeit a bit tedious. You'd have to add the generic wherever they are referenced like here for the return type:

https://github.com/rune-rs/rune/blob/7fd96d290e1c1a307558b947c2828fcec328a6fd/crates/rune/src/doc/context.rs#L41

And populate them from the context.

Finally you'd have to pass them into the link function here and modify it to take and recursively build links for generic parameters.

I'm thinking it might be appropriate to define a higher level type which captures both the base type and its generic parameters instead of just exposing a bare hash like we do now. Something like this:

#[cfg(feature = "doc")]
struct FullType {
    base: Option<Hash>,
    generics: Box<[Option<Hash>]>,
}

And then pass that into the link function, replacing any unknown Hash:es with ?.

udoprog commented 1 month ago

After landing #759, what we need to do next is to provide the necessary metadata through the MaybeTypeOf trait and pass it along so it can be used by the new context structures.

This also affects Any macro expansion.

VorpalBlade commented 1 month ago

That was amazingly quick! Didn't even have time to start looking into doing it myself.

udoprog commented 1 month ago

Cheers. Yeah, I think with #765 it's pretty much as good as it can be. Thanks for pointing this out!