Closed vaughnbetz closed 1 month ago
@duck2 : nag, nag ...
@duck2: nag, nag again ...
@duck2 : this seems to be in even more places in the documentation than I thought (just found it all over VtrNdMatrix as well. I think it's important to get this fixed soon. Adding @soheilshahrouz in case he has time to fix it.
Other nit in case @soheilshahrouz has the time to look at this: we should re-order the classes in things like vtr::NdMatrix so the main (end-user) classes like NdMatrix, NdOffsetMatrix etc. are listed first in their web pages, and the implementation detail classes are lower down.
We took a quick look. vtr_optional.h is missing the @file and @brief lines:
I fixed this ... also figured out I could commit to the master branch by accident (I just tightened the branch protection rules to make sure that doesn't happen again). Closing this. Not sure if we can control the order in which classes appear in the VTRUTIL API section, but it would still be a good idea to have the most important classes at the top if @soheilshahrouz has the energy for it.
The container documention under VTRUtil has an initial header that seems to be from an optional type that has been imported.
Expected Behaviour
This information should be under its own tab in the VTRUtil web documentation, not as a preface to unrelated data types.
Possible Solution
I suspect something is wrong in the settings for building info from various classes and .h/.cpp files into the VTR Utility documentation.
Steps to Reproduce
See https://docs.verilogtorouting.org/en/latest/api/vtrutil/containers/#vtr-vector-map for an example. The first part of the documentation is unrelated to vector_map, and seems to be for a variant of