[Feature Request][docgen] Docgen should output attributes

[wrwg]

Attribute support does not exist in docgen today, which makes its output rather unusable (if not confusing) for resource groups and view functions. Adding support should not be too difficult, as the move-model already supports attributes.

[wrwg]

Some more details about how to fix this:

• The functions which need to be extended are gen_module, gen_function and gen_struct in docgen.rs.
• There are already xxx_env.get_attributes() for modules, functions and structs which allow to access the attributes attached to the language construct.

One example where this has effect on the existing frameworks is the new object.move which has attributes to define resource groups. Another example are multiple #[view] annotations throughout the framework.

[brmataptos]

Thanks for the suggestions. Looks pretty doable.

[brmataptos]

I note from existing attribute_placement.move test case that attributes are also allowed on address/package scope, use statement, const definition, and spec, but you didn't mention it above and the appropriate formatting in docgen output is unclear. Skip them for now or come up with something?

Also, I note that symbolic package names (e.g., std) are converted to address numbers (e.g., 0x1) in docgen. I was using object.move to debug this code (although I didn't leave it as a test case due to the dependencies) and noted that the resulting .md file converts #[resource_group_member(group = aptos_framework::object::ObjectGroup)] to #[resource_group_member(group = 0x1::object::ObjectGroup)], which seems less useful. (Not just in attributes, though: the header module aptos_framework::object becomes Module 0x1::object).

Do we need a followup issue for that?

[wrwg]

I note from existing attribute_placement.move test case that attributes are also allowed on address/package scope, use statement, const definition, and spec, but you didn't mention it above and the appropriate formatting in docgen output is unclear. Skip them for now or come up with something?

Also, I note that symbolic package names (e.g., std) are converted to address numbers (e.g., 0x1) in docgen. I was using object.move to debug this code (although I didn't leave it as a test case due to the dependencies) and noted that the resulting .md file converts #[resource_group_member(group = aptos_framework::object::ObjectGroup)] to #[resource_group_member(group = 0x1::object::ObjectGroup)], which seems less useful. (Not just in attributes, though: the header module aptos_framework::object becomes Module 0x1::object).

Do we need a followup issue for that?

Yes, we should definitely create followup issues for both problems. (1) is not used by any 'official' attribute right now, but for completeness, we should fix this (not urgent). (2) is an issue which can hopefully be resolved after refactoring of move-model and new compiler are done. Until recently, move-model did not support symbolic addresses, as those were added later in the game. With my recent larger refactoring PR this was changed, but still symbolic addresses do not yet reach docgen. This should be the case with compiler v2.