This is an archive of the discontinued LLVM Phabricator instance.

libclang-cpp: Add external visibility attribute to all classes
Needs ReviewPublic

Authored by tstellar on Jun 2 2023, 7:42 PM.

Details

Summary

Also compile with -fvisiblity=hidden. This in theory should be NFC,
but it's possible I missed adding LLVM_EXTERNAL_VISIBILITY to some of
the symbols. This is the first step towards reducing the amount of
public symbols exposed in libclang-cpp.so, so in the future we will
be dropping LLVM_EXTERNAL_VISIBILITY from classes and functions that
we don't want to make publicly available.

Before and after symbol counts:

$ nm -gD before/libclang-cpp.so | wc -l
30459
$ nm -gD after/libclang-cpp.so | wc -l
20875

Diff Detail

Event Timeline

tstellar created this revision.Jun 2 2023, 7:42 PM
Herald added a reviewer: NoQ. · View Herald Transcript
Herald added a reviewer: ributzka. · View Herald Transcript
Herald added a reviewer: njames93. · View Herald Transcript
Herald added projects: Restricted Project, Restricted Project, Restricted Project. · View Herald Transcript
tstellar requested review of this revision.Jun 2 2023, 7:42 PM
Herald added projects: Restricted Project, Restricted Project. · View Herald Transcript
NOTE: Clang-Format Team Automated Review Comment

Your review contains a change to clang/include/clang/Format/Format.h but does not contain an update to ClangFormatStyleOptions.rst

ClangFormatStyleOptions.rst is generated via clang/docs/tools/dump_format_style.py, please run this to regenerate the .rst

You can validate that the rst is valid by running.

./docs/tools/dump_format_style.py
mkdir -p html
/usr/bin/sphinx-build -n ./docs ./html
NOTE: Clang-Format Team Automated Review Comment

It looks like your clang-format review does not contain any unit tests, please try to ensure all code changes have a unit test (unless this is an NFC or refactoring, adding documentation etc..)

Add your unit tests in clang/unittests/Format and you can build with ninja FormatTests. We recommend using the verifyFormat(xxx) format of unit tests rather than EXPECT_EQ as this will ensure you change is tolerant to random whitespace changes (see FormatTest.cpp as an example)

For situations where your change is altering the TokenAnnotator.cpp which can happen if you are trying to improve the annotation phase to ensure we are correctly identifying the type of a token, please add a token annotator test in TokenAnnotatorTest.cpp

I was not sure what to do with inline functions and also functions that were implemented in the headers, so I did not add the LLVM_EXTERNAL_VISIBILITY macro to most of those functions.

clang/include/clang/Format/Format.h
4532

This doesn't look formatted.

I was not sure what to do with inline functions and also functions that were implemented in the headers, so I did not add the LLVM_EXTERNAL_VISIBILITY macro to most of those functions.

I think that inline functions should have the attribute applied as well. That should be the equivalent of -fvisibility-inlines-hidden and should allow this to be useable for windows as well.

Please do not use LLVM_EXTERNAL_VISIBILITY but rather introduce a new macro (this will prevent the use on Windows).

I did write a tool to help with this: https://GitHub.com/compnerd/ids

! In D152051#4403167, @compnerd wrote:
Please do not use LLVM_EXTERNAL_VISIBILITY but rather introduce a new macro (this will prevent the use on Windows).

OK, so should I create a clang specific macro for this? And should it behave the same as LLVM_EXTERNAL_VISIBILITLY or do I need to have it expand to different values depending on the OS?

I did write a tool to help with this: https://GitHub.com/compnerd/ids

OK, thanks, I will check this out.

clang/include/clang/Format/Format.h
4532

I ran git-clang-format on the patch and it introduced a lot of unrelated changes, so I ended up dropping that part of the patch. I can go through and manually discard some of the more intrusive format changes. Any suggestions on which kind of formatting changes to keep and which ones to ignore?

I seem to recall this came up in the past and there were issues, so I did some digging around our mail archives and figured I'd share what I found:

https://discourse.llvm.org/t/big-clang-dll-plug-in-mechanism-revision/19376/5
https://discourse.llvm.org/t/distributing-libclang-cpp-dll-for-windows-in-the-pre-built-downloads/54778
https://lists.llvm.org/pipermail/llvm-dev/2017-June/113925.html

However, those concerns seem to be more around dllexport behavior on Windows, so LLVM_LIBRARY_VISIBILITY shouldn't matter there.

CC @rnk @majnemer @compnerd for confirmation that we shouldn't also be thinking about Windows symbol exports.

I chatted with @compnerd on Discord, and I'm going to try to update D109192 and get that committed and then come back to this patch.