-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
rST: add warning about duplicate anonymous hyperlink targets #13400
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
rST: add warning about duplicate anonymous hyperlink targets #13400
Conversation
The changes in 4df6239 seem to introduce a large number of false-positive warnings; numbered footnotes, for example, are frequently a source of distraction with this in place. I'll move this pull request back into draft status until I can resolve that problem. |
…tions Re-uses some existing filtering for footnotes and other acceptable duplicates. Some false-positives continue to occur with this change in place; for example, internal hyperlink targets that are subsequently `include`d into other docs.
Todo: extend the test coverage to add an example of document that is |
.. _ambiguous_shared_hyperlink: | ||
|
||
This hyperlink target is declared once and is included by multiple documents. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@AA-Turner @picnixz is there a way to determine a unique declaration identifier/path -- e.g. where a hyperlink was defined, instead of where it is used?
When reporting warnings about duplicated anonymous hyperlinks, it'd be nice to be able to indicate clearly that the duplication originates from multiple include
s of a common document, instead of weird/confusing warnings about the hyperlinks appearing in multiple documents.
Purpose
The goal of this pull request is to identify duplicate internal hyperlink targets -- the presence of these can cause documentation hyperlinks to resolve ambiguously (e.g. sometimes incorrectly) at build-time.
References