Repository navigation
fix: using declaration names and anchors - #1317
Open
gennaroprota wants to merge 2 commits into
Open
gennaroprota wants to merge 2 commits into
gennaroprota wants to merge 2 commits into
Conversation
Contributor
✨ Highlights
🧾 Changes by Scope
🔝 Top Files
|
gennaroprota
changed the title
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #1317 +/- ##
===========================================
+ Coverage 83.12% 83.21% +0.09%
===========================================
Files 35 35
Lines 3662 3670 +8
Branches 844 845 +1
===========================================
+ Hits 3044 3054 +10
Misses 410 410
+ Partials 208 206 -2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
An automated preview of the documentation is available at https://1317.mrdocs.prtest2.cppalliance.org/index.html If more commits are pushed to the pull request, the docs will rebuild at the same URL. 2026-10-14 14:33:48 UTC |
gennaroprota
force-pushed
the
fix/using_declaration_names_and_anchors
branch
from
October 14, 2026 11:07
9cb003c to
66b8d74
Compare
This was referenced Oct 14, 2026
This fixes a bug for which an inheriting constructor was documented under the wrong name, or under no name at all. The synopsis of `using Base::Base;` read `using Base::Derived;`, and the heading and the member table gave the declaration the derived class's name, so several of them in one class were indistinguishable. With a base that depends on a template parameter the name came out empty instead, reaching the page as "Unnamed using" and the synopsis as `using Base<T>::;`. Clang stores the first as a constructor of the derived class, and the second as a constructor of a type that has no class behind it at all. We now take the name from the last component of the qualifier, which spells the class as written, be it a class, a class template specialization, an alias or a template parameter. A declaration named after the base would hide the base from references written in the derived class or in its members, such as `@ref Base` or `@copydoc Base`, since lookup searches the members of a class before the enclosing scopes. Lookup now passes over an inheriting constructor, so these references still resolve to the base class. I've added tests. Refs cppalliance#1276.
This fixes a bug for which a using-declaration that names an operator produced a page no link could reach, and sometimes no page at all. `operator[]` broke the link, because AsciiDoc ends a link target at the first bracket. `operator->` and `operator<=>` broke more quietly, because AsciiDoc rewrites `->` and `=>` inside the target as arrow characters, and the link then points at a page that does not exist. `operator/` put the page inside a directory of its own, because a slash is a path separator. A conversion such as `operator bool` got a space in the file name and in the link. On Windows a file name cannot hold `"`, `*`, `<`, `>` or `|` at all, so every operator spelled with one of those could not be opened and generation stopped with an error. The anchor is what a page file name and a link are built from, so it has to be a plain identifier. A using-declaration does not make one up: it takes the anchor of its first shadow declaration, which is safe already, an operator having gone through the table of safe operator names. There are no shadow declarations when the base depends on a template parameter, since the name cannot be looked up before the template is instantiated, nor when the filters removed the target. The anchor then fell back to the declaration's own name, punctuation and all. All of them now take the anchor the operator itself would get (e.g. `operator_subs` for `operator[]`), and a conversion takes the one that every conversion shares. A literal operator such as `operator""_km` drops its double quotes, as the anchor of the literal operator itself already does. I've added tests. Fixes cppalliance#1276.
gennaroprota
force-pushed
the
fix/using_declaration_names_and_anchors
branch
from
October 14, 2026 14:19
66b8d74 to
f7215bc
Compare
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR fixes the two defects #1276 reports in the "Using Declarations" table: an entry labeled "Unnamed using", and a link that renders as raw AsciiDoc. Both show up with a base that depends on a template parameter, or with a target the filters removed.
Inheriting constructors are named after their base.
using Base::Base;was named after the derived class, with the synopsisusing Base::Derived;, or, with a dependent base, not named at all ("Unnamed using",using Base<T>::;). The name now comes from the last component of the qualifier, as written: a class, a class template specialization, an alias or a template parameter. Lookup passes over these declarations, so a@ref Baseor@copydoc Basewritten in the derived class still finds the class.Operators named by a using-declaration get a usable anchor. Without a shadow declaration to take its anchor from, such a declaration used its own name, punctuation included:
operator[]broke the AsciiDoc link,operator->linked to a page that doesn't exist,operator/created a subdirectory, and, on Windows, an operator spelled with",*,<,>or|stopped the generation. It now gets the anchor the operator itself would get, such asoperator_subs; a conversion gets the shared2conversion, and a literal operator drops its quotes. The anchor is derived from the operator's name rather than from an operator kind recorded on the declaration, which would change the public data model and the schema for this one fallback.Changes
ASTVisitornames an inheriting constructor from its qualifier,Corpuslookup passes over it, andAnchorFinalizergives a using-declaration of an operator the operator's anchor.@refand@copydocnaming the base.Testing
The golden fixtures above. The existing using-member-function.xml now names its inheriting constructors after their bases. For a pack,
using Bases::Bases...;, the fixture pins only the name and the heading, because the synopsis doesn't show the...yet (#1357).Documentation
None needed: no option, command or documented behavior changes.
Closes #1276.