mosra / m.css

A no-nonsense, no-JavaScript CSS framework, site and documentation theme for content-oriented websites
https://mcss.mosra.cz
MIT License
399 stars 88 forks source link

TypeError: unsupported operand type(s) for +: 'NoneType' and 'str' #217

Closed meme closed 2 years ago

meme commented 2 years ago

Hi again, thanks for resolving: https://github.com/mosra/m.css/issues/123. I am running it again on radare2, but have encountered an issue.

I suspect the cause is because I am using Doxygen version 1.9.1 which as I understand is not yet fully supported, https://github.com/mosra/m.css/issues/215.

Python version: 3.10.1 m.css version: 228c9b8a972a512d033ca28085d0646572878154 radare2 version: f56a9530b00bc32847d4fa876574e91283873b77 Command: ./doxygen.py ../../radare2/Doxyfile-mcss

Doxyfile-mcss (in the root of the radare2 repo, no other changes required):

@INCLUDE                = Doxyfile
GENERATE_HTML           = NO
GENERATE_XML            = YES
XML_PROGRAMLISTING      = NO
M_SHOW_UNDOCUMENTED     = YES

Output:

  File "/code/m.css/documentation/./doxygen.py", line 3955, in <module>
    run(state, templates=os.path.abspath(args.templates), wildcard=args.wildcard, index_pages=args.index_pages, search_merge_subtrees=not args.search_no_subtree_merging, search_add_lookahead_barriers=not args.search_no_lookahead_barriers, search_merge_prefixes=not args.search_no_prefix_merging)
  File "/code/m.css/documentation/./doxygen.py", line 3812, in run
    parsed = parse_xml(state, file)
  File "/code/m.css/documentation/./doxygen.py", line 2895, in parse_xml
    func = parse_func(state, memberdef)
  File "/code/m.css/documentation/./doxygen.py", line 2104, in parse_func
    param.type_name = param.type + ' ' + name.text
TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'
mosra commented 2 years ago

Yay, thanks! I was actually wondering if radare2 still uses the m.css generated docs somewhere to have some monster-project to test the updated version with, but didn't find anything after a bit of clicking around so I gave up :)

I'll set it up locally tomorrow and investigate. The Doxygen 1.9 update turned out to be a bigger hell than anticipated so I had to put it aside, but this doesn't look related -- probably just some corner case I wasn't aware of yet.

mosra commented 2 years ago

OK, fixed, here's a proof:

image

It was due to DEF_STATE_ACTION($) { being interpreted as a function signature by Doxygen and m.css subsequently tripping up on the $ which was not listed as parameter type but rather a name. A very cornery corner case I'd say. Regression test case and a workaround is added in d44d4609099080f881a656d885232bc51bbf101c. A "proper" way to fix this would be to have such blocks excluded from Doxygen processing (or, the nuclear solution, only parsing the header files).

Now your docs will build, but please note it'll fail at first, suggesting you to specify an option to be able to store the large symbol count. With this Doxyfile it'll then work:

@INCLUDE                = Doxyfile
GENERATE_HTML           = NO
GENERATE_XML            = YES
XML_PROGRAMLISTING      = NO
M_SHOW_UNDOCUMENTED     = YES
# There's >70k symbols which wouldn't fit into 16 bits
M_SEARCH_RESULT_ID_BYTES = 3

Depending on your goals, I suppose when you eventually get to having the docs generated just from *.h files (ignoring all file-local symbols that inflate the search data), you could get to a significantly smaller search data again.