Skip to content
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

[clang] Document the type_visibility attribute #79157

Merged
merged 3 commits into from
Feb 9, 2024

Conversation

ldionne
Copy link
Member

@ldionne ldionne commented Jan 23, 2024

I was looking for the documentation of that attribute, and the best I could find was a Stackoverflow answer or the commit message that originally introduced the attribute. I figured I might as well document what I find to save everyone time in the future.

I was looking for the documentation of that attribute, and the best
I could find was a Stackoverflow answer or the commit message that
originally introduced the attribute. I figured I might as well document
what I find to save everyone time in the future.
@llvmbot llvmbot added clang Clang issues not falling into any other category clang:frontend Language frontend issues, e.g. anything involving "Sema" labels Jan 23, 2024
@llvmbot
Copy link
Collaborator

llvmbot commented Jan 23, 2024

@llvm/pr-subscribers-clang

Author: Louis Dionne (ldionne)

Changes

I was looking for the documentation of that attribute, and the best I could find was a Stackoverflow answer or the commit message that originally introduced the attribute. I figured I might as well document what I find to save everyone time in the future.


Full diff: https://github.com/llvm/llvm-project/pull/79157.diff

2 Files Affected:

  • (modified) clang/include/clang/Basic/Attr.td (+2-2)
  • (modified) clang/include/clang/Basic/AttrDocs.td (+15)
diff --git a/clang/include/clang/Basic/Attr.td b/clang/include/clang/Basic/Attr.td
index 58838b01b4fd7ca..e47107d8edcb378 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -3220,8 +3220,8 @@ def TypeVisibility : InheritableAttr {
   let Args = [EnumArgument<"Visibility", "VisibilityType",
                            ["default", "hidden", "internal", "protected"],
                            ["Default", "Hidden", "Hidden", "Protected"]>];
-//  let Subjects = [Tag, ObjCInterface, Namespace];
-  let Documentation = [Undocumented];
+  let Subjects = SubjectList<[Tag, ObjCInterface, Namespace], ErrorDiag>;
+  let Documentation = [TypeVisibilityDocs];
 }
 
 def VecReturn : InheritableAttr {
diff --git a/clang/include/clang/Basic/AttrDocs.td b/clang/include/clang/Basic/AttrDocs.td
index 7e633f8e2635a9a..703f7cd314b727c 100644
--- a/clang/include/clang/Basic/AttrDocs.td
+++ b/clang/include/clang/Basic/AttrDocs.td
@@ -5557,6 +5557,21 @@ See :doc:`LTOVisibility`.
   }];
 }
 
+def TypeVisibilityDocs : Documentation {
+  let Category = DocCatType;
+  let Content = [{
+The ``type_visibility`` attribute allows the ELF visibility of a type and its vague
+linkage objects (vtable, typeinfo, typeinfo name) to be controlled separately from
+the visibility of functions and data members of the type.
+
+For example, this can be used to give default visibility to the typeinfo and the vtable
+of a type while still keeping hidden visibility on its member functions and static data
+members.
+
+This attribute can only be applied to types and namespaces.
+  }]
+}
+
 def RenderScriptKernelAttributeDocs : Documentation {
   let Category = DocCatFunction;
   let Content = [{

@@ -3220,8 +3220,8 @@ def TypeVisibility : InheritableAttr {
let Args = [EnumArgument<"Visibility", "VisibilityType",
["default", "hidden", "internal", "protected"],
["Default", "Hidden", "Hidden", "Protected"]>];
// let Subjects = [Tag, ObjCInterface, Namespace];
let Documentation = [Undocumented];
let Subjects = SubjectList<[Tag, ObjCInterface, Namespace], ErrorDiag>;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not certain if this is correct, and whether this means I need to add some tests.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would separate out this change because it's not really related to documenting the attribute (this is used to generate automatic checks for the subject, so it corresponds to this code that was manually written and can possibly be removed:

if (isTypeVisibility && !(isa<TagDecl>(D) || isa<ObjCInterfaceDecl>(D) ||
)

of a type while still keeping hidden visibility on its member functions and static data
members.

This attribute can only be applied to types and namespaces.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we also want to document the behavior of adding both clang::type_visibility and gnu::visibility to a namespace? (I think clang::type_visibility overrides gnu::visibility)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You seem to be right based on https://godbolt.org/z/bbs7478sv. I'll add the documentation.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This applies to classes too: https://godbolt.org/z/673qsnxsP

@gribozavr gribozavr requested review from martinboehme and removed request for martinboehme January 23, 2024 17:26
Copy link
Collaborator

@AaronBallman AaronBallman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the improved documentation! In general, heading in the right direction. There might be some more details we'd like to add, but if you don't know those details, that's totally fine (this at least moves the needle in the right direction).

@@ -3220,8 +3220,8 @@ def TypeVisibility : InheritableAttr {
let Args = [EnumArgument<"Visibility", "VisibilityType",
["default", "hidden", "internal", "protected"],
["Default", "Hidden", "Hidden", "Protected"]>];
// let Subjects = [Tag, ObjCInterface, Namespace];
let Documentation = [Undocumented];
let Subjects = SubjectList<[Tag, ObjCInterface, Namespace], ErrorDiag>;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would separate out this change because it's not really related to documenting the attribute (this is used to generate automatic checks for the subject, so it corresponds to this code that was manually written and can possibly be removed:

if (isTypeVisibility && !(isa<TagDecl>(D) || isa<ObjCInterfaceDecl>(D) ||
)

def TypeVisibilityDocs : Documentation {
let Category = DocCatType;
let Content = [{
The ``type_visibility`` attribute allows the ELF visibility of a type and its vague
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this only impact ELF or does this also impact say PE32?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know the answer to that question since I have no familiarity with PE32. However, looking at the original patch it looks to me like this impacts all places where a normal visibility attribute is relevant. I think I should just remove ELF here from the docs, since this makes it look unnecessarily specific to ELF.

Copy link
Collaborator

@AaronBallman AaronBallman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thank you for the improved documentation!

@ldionne ldionne merged commit 228e9d5 into llvm:main Feb 9, 2024
4 of 5 checks passed
@ldionne ldionne deleted the review/document-type-visibility branch February 9, 2024 20:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clang:frontend Language frontend issues, e.g. anything involving "Sema" clang Clang issues not falling into any other category
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants