https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123830
Bug ID: 123830
Summary: regenerate-opt-urls.py is confused by @opindex entries
for -fno-* or -Wno-* options
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: documentation
Severity: normal
Priority: P3
Component: diagnostics
Assignee: dmalcolm at redhat dot com
Reporter: sandra at gcc dot gnu.org
Target Milestone: ---
As part of addressing PR122243, I added an @opindex for -fno-pack-struct in
commit ed2924c7628343ff8b699f320a05c85bdb9c2837. The subsequent "make
regenerate-opt-urls" broke builds because the urlifier self-tests failed -- it
happened to be using this particular option to test lookup, but it was now
returning the anchor for the -fno- option instead of the positive form. I
committed a quick fix (a6c3c48148dd60a09ffab57019f163180c159d65) to unblock
people's builds, but have spent some more time looking at why it's returning
the anchor for the negative option.
The regenerate-opt-urls.py script processes the entries in the generated HTML
file for the options sequentially -- it's alphabetized, so it sees the entry
for -fno-pack-struct before -fpack-struct, but -finline before -fno-inline.
And it uses the anchor from the first one it sees, even though it always strips
any "no-" from the option name associated with that index entry.
I think what it ought to be doing is always using the anchor for the positive
option with the positive form of the option name and ignoring the no- anchor,
unless there isn't an index entry for the positive form at all. (There are, in
fact, some options that only exist in the negative form, or where the negative
form is the only one documented.) While both anchors ought to be in the same
place in the output text, it's pretty weird for anybody who looks at the links
to see a reference to -fpack-struct pointing at the anchor for -fno-pack-struct
instead.
Once this is fixed properly, my hacky workaround ought to be reverted.
