maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/InterfaceStubs/hidden-class-inheritance.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

150 lines
6.2 KiB
C++
Raw Normal View History

[NFC] Fix for InterfaceStubs tests (adding REQUIRES: x86-registered-target). clang-hexagon-elf bot was failing with: 'No available targets are compatible with triple "x86_64-unknown-linux-gnu"' Adding a "// REQUIRES: x86-registered-target" to these tests to quiet the bot. llvm-svn: 363963
2019-06-21 02:28:21 +08:00
// REQUIRES: x86-registered-target
[clang][IFS][test][NFC] Tightening up clang-ifs tests to use -cc1 more often. Unless the test is explicitly testing a driver feature if clang interface stubs I have changed the tests to use %clang_cc1. This should make some changes I plan to make to the driver job pipeline cause fewer test changes and breakages.
2019-11-14 12:58:09 +08:00
// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -o - -emit-interface-stubs \
[clang-ifs] Clang Interface Stubs, first version (second landing attempt). This change reverts r363649; effectively re-landing r363626. At this point clang::Index::CodegenNameGeneratorImpl has been refactored into clang::AST::ASTNameGenerator. This makes it so that the previous circular link dependency no longer exists, fixing the previous share lib (-DBUILD_SHARED_LIBS=ON) build issue which was the reason for r363649. Clang interface stubs (previously referred to as clang-ifsos) is a new frontend action in clang that allows the generation of stub files that contain mangled name info that can be used to produce a stub library. These stub libraries can be useful for breaking up build dependencies and controlling access to a library's internal symbols. Generation of these stubs can be invoked by: clang -fvisibility=<visibility> -emit-interface-stubs \ -interface-stub-version=<interface format> Notice that -fvisibility (along with use of visibility attributes) can be used to control what symbols get generated. Currently the interface format is experimental but there are a wide range of possibilities here. Currently clang-ifs produces .ifs files that can be thought of as analogous to object (.o) files, but just for the mangled symbol info. In a subsequent patch I intend to add support for merging the .ifs files into one .ifs/.ifso file that can be the input to something like llvm-elfabi to produce something like a .so file or .dll (but without any of the code, just symbols). Differential Revision: https://reviews.llvm.org/D60974 llvm-svn: 363948
2019-06-21 00:59:48 +08:00
// RUN: -DPARENT_CLASS_VISIBILITY="" -DCHILD_CLASS_VISIBILITY="" \
// RUN: -DPARENT_METHOD_VISIBILITY="" -DCHILD_METHOD_VISIBILITY="" %s | \
// RUN: FileCheck -check-prefix=CHECK-X %s
// RUN: %clang -target x86_64-unknown-linux-gnu -o - -c \
// RUN: -DPARENT_CLASS_VISIBILITY="" -DCHILD_CLASS_VISIBILITY="" \
// RUN: -DPARENT_METHOD_VISIBILITY="" -DCHILD_METHOD_VISIBILITY="" %s | \
// RUN: llvm-readelf -s - 2>&1 | \
// RUN: FileCheck -check-prefix=CHECK-X-RE %s
[clang][IFS][test][NFC] Tightening up clang-ifs tests to use -cc1 more often. Unless the test is explicitly testing a driver feature if clang interface stubs I have changed the tests to use %clang_cc1. This should make some changes I plan to make to the driver job pipeline cause fewer test changes and breakages.
2019-11-14 12:58:09 +08:00
// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -o - -emit-interface-stubs \
[clang-ifs] Clang Interface Stubs, first version (second landing attempt). This change reverts r363649; effectively re-landing r363626. At this point clang::Index::CodegenNameGeneratorImpl has been refactored into clang::AST::ASTNameGenerator. This makes it so that the previous circular link dependency no longer exists, fixing the previous share lib (-DBUILD_SHARED_LIBS=ON) build issue which was the reason for r363649. Clang interface stubs (previously referred to as clang-ifsos) is a new frontend action in clang that allows the generation of stub files that contain mangled name info that can be used to produce a stub library. These stub libraries can be useful for breaking up build dependencies and controlling access to a library's internal symbols. Generation of these stubs can be invoked by: clang -fvisibility=<visibility> -emit-interface-stubs \ -interface-stub-version=<interface format> Notice that -fvisibility (along with use of visibility attributes) can be used to control what symbols get generated. Currently the interface format is experimental but there are a wide range of possibilities here. Currently clang-ifs produces .ifs files that can be thought of as analogous to object (.o) files, but just for the mangled symbol info. In a subsequent patch I intend to add support for merging the .ifs files into one .ifs/.ifso file that can be the input to something like llvm-elfabi to produce something like a .so file or .dll (but without any of the code, just symbols). Differential Revision: https://reviews.llvm.org/D60974 llvm-svn: 363948
2019-06-21 00:59:48 +08:00
// RUN: -DPARENT_CLASS_VISIBILITY=HIDDEN -DCHILD_CLASS_VISIBILITY="" \
// RUN: -DPARENT_METHOD_VISIBILITY="" -DCHILD_METHOD_VISIBILITY="" %s | \
// RUN: FileCheck -check-prefix=CHECK-HP %s
[clang][IFS][test][NFC] Tightening up clang-ifs tests to use -cc1 more often. Unless the test is explicitly testing a driver feature if clang interface stubs I have changed the tests to use %clang_cc1. This should make some changes I plan to make to the driver job pipeline cause fewer test changes and breakages.
2019-11-14 12:58:09 +08:00
// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -o - -emit-interface-stubs \
[llvm][clang][IFS] Enhancing the llvm-ifs yaml format for symbol lists. Prior to this change the clang interface stubs format resembled something ending with a symbol list like this: Symbols: a: { Type: Func } This was problematic because we didn't actually want a map format and also because we didn't like that an empty symbol list required "Symbols: {}". That is to say without the empty {} llvm-ifs would crash on an empty list. With this new format it is much more clear which field is the symbol name, and instead the [] that is used to express an empty symbol vector is optional, ie: Symbols: - { Name: a, Type: Func } or Symbols: [] or Symbols: This further diverges the format from existing llvm-elftapi. This is a good thing because although the format originally came from the same place, they are not the same in any way. Differential Revision: https://reviews.llvm.org/D76979
2020-03-28 16:08:27 +08:00
// RUN: -interface-stub-version=experimental-ifs-v2 \
[clang-ifs] Clang Interface Stubs, first version (second landing attempt). This change reverts r363649; effectively re-landing r363626. At this point clang::Index::CodegenNameGeneratorImpl has been refactored into clang::AST::ASTNameGenerator. This makes it so that the previous circular link dependency no longer exists, fixing the previous share lib (-DBUILD_SHARED_LIBS=ON) build issue which was the reason for r363649. Clang interface stubs (previously referred to as clang-ifsos) is a new frontend action in clang that allows the generation of stub files that contain mangled name info that can be used to produce a stub library. These stub libraries can be useful for breaking up build dependencies and controlling access to a library's internal symbols. Generation of these stubs can be invoked by: clang -fvisibility=<visibility> -emit-interface-stubs \ -interface-stub-version=<interface format> Notice that -fvisibility (along with use of visibility attributes) can be used to control what symbols get generated. Currently the interface format is experimental but there are a wide range of possibilities here. Currently clang-ifs produces .ifs files that can be thought of as analogous to object (.o) files, but just for the mangled symbol info. In a subsequent patch I intend to add support for merging the .ifs files into one .ifs/.ifso file that can be the input to something like llvm-elfabi to produce something like a .so file or .dll (but without any of the code, just symbols). Differential Revision: https://reviews.llvm.org/D60974 llvm-svn: 363948
2019-06-21 00:59:48 +08:00
// RUN: -DPARENT_CLASS_VISIBILITY=HIDDEN -DCHILD_CLASS_VISIBILITY="" \
// RUN: -DPARENT_METHOD_VISIBILITY="" -DCHILD_METHOD_VISIBILITY="" %s | \
// RUN: FileCheck -check-prefix=CHECK-HP2 %s
// RUN: %clang -target x86_64-unknown-linux-gnu -o - -c \
// RUN: -DPARENT_CLASS_VISIBILITY=HIDDEN -DCHILD_CLASS_VISIBILITY="" \
// RUN: -DPARENT_METHOD_VISIBILITY="" -DCHILD_METHOD_VISIBILITY="" %s | \
// RUN: llvm-readelf -s - 2>&1 | \
// RUN: FileCheck -check-prefix=CHECK-HP-RE %s
[clang][IFS][test][NFC] Tightening up clang-ifs tests to use -cc1 more often. Unless the test is explicitly testing a driver feature if clang interface stubs I have changed the tests to use %clang_cc1. This should make some changes I plan to make to the driver job pipeline cause fewer test changes and breakages.
2019-11-14 12:58:09 +08:00
// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -o - -emit-interface-stubs \
[clang-ifs] Clang Interface Stubs, first version (second landing attempt). This change reverts r363649; effectively re-landing r363626. At this point clang::Index::CodegenNameGeneratorImpl has been refactored into clang::AST::ASTNameGenerator. This makes it so that the previous circular link dependency no longer exists, fixing the previous share lib (-DBUILD_SHARED_LIBS=ON) build issue which was the reason for r363649. Clang interface stubs (previously referred to as clang-ifsos) is a new frontend action in clang that allows the generation of stub files that contain mangled name info that can be used to produce a stub library. These stub libraries can be useful for breaking up build dependencies and controlling access to a library's internal symbols. Generation of these stubs can be invoked by: clang -fvisibility=<visibility> -emit-interface-stubs \ -interface-stub-version=<interface format> Notice that -fvisibility (along with use of visibility attributes) can be used to control what symbols get generated. Currently the interface format is experimental but there are a wide range of possibilities here. Currently clang-ifs produces .ifs files that can be thought of as analogous to object (.o) files, but just for the mangled symbol info. In a subsequent patch I intend to add support for merging the .ifs files into one .ifs/.ifso file that can be the input to something like llvm-elfabi to produce something like a .so file or .dll (but without any of the code, just symbols). Differential Revision: https://reviews.llvm.org/D60974 llvm-svn: 363948
2019-06-21 00:59:48 +08:00
// RUN: -DPARENT_CLASS_VISIBILITY="" -DCHILD_CLASS_VISIBILITY=HIDDEN \
// RUN: -DPARENT_METHOD_VISIBILITY="" -DCHILD_METHOD_VISIBILITY="" %s | \
// RUN: FileCheck -check-prefix=CHECK-HC %s
[clang][IFS][test][NFC] Tightening up clang-ifs tests to use -cc1 more often. Unless the test is explicitly testing a driver feature if clang interface stubs I have changed the tests to use %clang_cc1. This should make some changes I plan to make to the driver job pipeline cause fewer test changes and breakages.
2019-11-14 12:58:09 +08:00
// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -o - -emit-interface-stubs \
[clang-ifs] Clang Interface Stubs, first version (second landing attempt). This change reverts r363649; effectively re-landing r363626. At this point clang::Index::CodegenNameGeneratorImpl has been refactored into clang::AST::ASTNameGenerator. This makes it so that the previous circular link dependency no longer exists, fixing the previous share lib (-DBUILD_SHARED_LIBS=ON) build issue which was the reason for r363649. Clang interface stubs (previously referred to as clang-ifsos) is a new frontend action in clang that allows the generation of stub files that contain mangled name info that can be used to produce a stub library. These stub libraries can be useful for breaking up build dependencies and controlling access to a library's internal symbols. Generation of these stubs can be invoked by: clang -fvisibility=<visibility> -emit-interface-stubs \ -interface-stub-version=<interface format> Notice that -fvisibility (along with use of visibility attributes) can be used to control what symbols get generated. Currently the interface format is experimental but there are a wide range of possibilities here. Currently clang-ifs produces .ifs files that can be thought of as analogous to object (.o) files, but just for the mangled symbol info. In a subsequent patch I intend to add support for merging the .ifs files into one .ifs/.ifso file that can be the input to something like llvm-elfabi to produce something like a .so file or .dll (but without any of the code, just symbols). Differential Revision: https://reviews.llvm.org/D60974 llvm-svn: 363948
2019-06-21 00:59:48 +08:00
// RUN: -DPARENT_CLASS_VISIBILITY="" -DCHILD_CLASS_VISIBILITY=HIDDEN \
// RUN: -DPARENT_METHOD_VISIBILITY="" -DCHILD_METHOD_VISIBILITY="" %s | \
// RUN: FileCheck -check-prefix=CHECK-HC2 %s
// RUN: %clang -target x86_64-unknown-linux-gnu -o - -c \
// RUN: -DPARENT_CLASS_VISIBILITY="" -DCHILD_CLASS_VISIBILITY=HIDDEN \
// RUN: -DPARENT_METHOD_VISIBILITY="" -DCHILD_METHOD_VISIBILITY="" %s | \
// RUN: llvm-readelf -s - 2>&1 | \
// RUN: FileCheck -check-prefix=CHECK-HC-RE %s
[clang][IFS][test][NFC] Tightening up clang-ifs tests to use -cc1 more often. Unless the test is explicitly testing a driver feature if clang interface stubs I have changed the tests to use %clang_cc1. This should make some changes I plan to make to the driver job pipeline cause fewer test changes and breakages.
2019-11-14 12:58:09 +08:00
// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -o - -emit-interface-stubs \
[clang-ifs] Clang Interface Stubs, first version (second landing attempt). This change reverts r363649; effectively re-landing r363626. At this point clang::Index::CodegenNameGeneratorImpl has been refactored into clang::AST::ASTNameGenerator. This makes it so that the previous circular link dependency no longer exists, fixing the previous share lib (-DBUILD_SHARED_LIBS=ON) build issue which was the reason for r363649. Clang interface stubs (previously referred to as clang-ifsos) is a new frontend action in clang that allows the generation of stub files that contain mangled name info that can be used to produce a stub library. These stub libraries can be useful for breaking up build dependencies and controlling access to a library's internal symbols. Generation of these stubs can be invoked by: clang -fvisibility=<visibility> -emit-interface-stubs \ -interface-stub-version=<interface format> Notice that -fvisibility (along with use of visibility attributes) can be used to control what symbols get generated. Currently the interface format is experimental but there are a wide range of possibilities here. Currently clang-ifs produces .ifs files that can be thought of as analogous to object (.o) files, but just for the mangled symbol info. In a subsequent patch I intend to add support for merging the .ifs files into one .ifs/.ifso file that can be the input to something like llvm-elfabi to produce something like a .so file or .dll (but without any of the code, just symbols). Differential Revision: https://reviews.llvm.org/D60974 llvm-svn: 363948
2019-06-21 00:59:48 +08:00
// RUN: -DPARENT_CLASS_VISIBILITY=HIDDEN -DCHILD_CLASS_VISIBILITY=HIDDEN \
// RUN: -DPARENT_METHOD_VISIBILITY="" -DCHILD_METHOD_VISIBILITY="" %s | \
// RUN: FileCheck -check-prefix=CHECK-HP-HC %s
// RUN: %clang -target x86_64-unknown-linux-gnu -o - -c \
// RUN: -DPARENT_CLASS_VISIBILITY=HIDDEN -DCHILD_CLASS_VISIBILITY=HIDDEN \
// RUN: -DPARENT_METHOD_VISIBILITY="" -DCHILD_METHOD_VISIBILITY="" %s | \
// RUN: llvm-readelf -s - 2>&1 | \
// RUN: FileCheck -check-prefix=CHECK-HP-HC-RE %s
// CHECK-X-DAG: _ZN1CC2Ev
// CHECK-X-DAG: _ZN1CD0Ev
// CHECK-X-DAG: _ZN1CD2Ev
// CHECK-X-DAG: _ZN1SC2Ev
// CHECK-X-DAG: _ZN1SD0Ev
// CHECK-X-DAG: _ZN1SD2Ev
// CHECK-X-DAG: _ZN1C1mEv
// CHECK-X-DAG: _ZN1S1nEv
// CHECK-X-RE: FUNC WEAK DEFAULT {{[0-9]+}} _ZN1C1mEv
// CHECK-X-RE: FUNC WEAK DEFAULT {{[0-9]+}} _ZN1CC2Ev
// CHECK-X-RE: FUNC WEAK DEFAULT {{[0-9]+}} _ZN1CD0Ev
// CHECK-X-RE: FUNC WEAK DEFAULT {{[0-9]+}} _ZN1CD2Ev
// CHECK-X-RE: FUNC WEAK DEFAULT {{[0-9]+}} _ZN1S1nEv
// CHECK-X-RE: FUNC WEAK DEFAULT {{[0-9]+}} _ZN1SC2Ev
// CHECK-X-RE: FUNC WEAK DEFAULT {{[0-9]+}} _ZN1SD0Ev
// CHECK-X-RE: FUNC WEAK DEFAULT {{[0-9]+}} _ZN1SD2Ev
// CHECK-HP2-DAG: _ZN1CC2Ev
// CHECK-HP2-DAG: _ZN1CD0Ev
// CHECK-HP2-DAG: _ZN1CD2Ev
// CHECK-HP2-DAG: _ZN1C1mEv
// CHECK-HP-NOT: _ZN1S1nEv
// CHECK-HP-NOT: _ZN1SC2Ev
// CHECK-HP-NOT: _ZN1SD0Ev
// CHECK-HP-NOT: _ZN1SD2Ev
// CHECK-HP-RE: FUNC WEAK DEFAULT {{[0-9]+}} _ZN1C1mEv
// CHECK-HP-RE: FUNC WEAK DEFAULT {{[0-9]+}} _ZN1CC2Ev
// CHECK-HP-RE: FUNC WEAK DEFAULT {{[0-9]+}} _ZN1CD0Ev
// CHECK-HP-RE: FUNC WEAK DEFAULT {{[0-9]+}} _ZN1CD2Ev
// CHECK-HP-RE: FUNC WEAK HIDDEN {{[0-9]+}} _ZN1S1nEv
// CHECK-HP-RE: FUNC WEAK HIDDEN {{[0-9]+}} _ZN1SC2Ev
// CHECK-HP-RE: FUNC WEAK HIDDEN {{[0-9]+}} _ZN1SD0Ev
// CHECK-HP-RE: FUNC WEAK HIDDEN {{[0-9]+}} _ZN1SD2Ev
// CHECK-HC2-DAG: _ZN1SC2Ev
// CHECK-HC2-DAG: _ZN1SD0Ev
// CHECK-HC2-DAG: _ZN1SD2Ev
// CHECK-HC2-DAG: _ZN1S1nEv
// CHECK-HC-NOT: _ZN1C1mEv
// CHECK-HC-NOT: _ZN1CC2Ev
// CHECK-HC-NOT: _ZN1CD0Ev
// CHECK-HC-NOT: _ZN1CD2Ev
// CHECK-HC-RE: FUNC WEAK HIDDEN {{[0-9]+}} _ZN1C1mEv
// CHECK-HC-RE: FUNC WEAK HIDDEN {{[0-9]+}} _ZN1CC2Ev
// CHECK-HC-RE: FUNC WEAK HIDDEN {{[0-9]+}} _ZN1CD0Ev
// CHECK-HC-RE: FUNC WEAK HIDDEN {{[0-9]+}} _ZN1CD2Ev
// CHECK-HC-RE: FUNC WEAK DEFAULT {{[0-9]+}} _ZN1S1nEv
// CHECK-HC-RE: FUNC WEAK DEFAULT {{[0-9]+}} _ZN1SC2Ev
// CHECK-HC-RE: FUNC WEAK DEFAULT {{[0-9]+}} _ZN1SD0Ev
// CHECK-HC-RE: FUNC WEAK DEFAULT {{[0-9]+}} _ZN1SD2Ev
// CHECK-HP-HC-NOT: _ZN1CC2Ev
// CHECK-HP-HC-NOT: _ZN1CD0Ev
// CHECK-HP-HC-NOT: _ZN1CD2Ev
// CHECK-HP-HC-NOT: _ZN1SC2Ev
// CHECK-HP-HC-NOT: _ZN1SD0Ev
// CHECK-HP-HC-NOT: _ZN1SD2Ev
// CHECK-HP-HC-NOT: _ZN1C1mEv
// CHECK-HP-HC-NOT: _ZN1S1nEv
// CHECK-HP-HC-RE: FUNC WEAK HIDDEN {{[0-9]+}} _ZN1C1mEv
// CHECK-HP-HC-RE: FUNC WEAK HIDDEN {{[0-9]+}} _ZN1CC2Ev
// CHECK-HP-HC-RE: FUNC WEAK HIDDEN {{[0-9]+}} _ZN1CD0Ev
// CHECK-HP-HC-RE: FUNC WEAK HIDDEN {{[0-9]+}} _ZN1CD2Ev
// CHECK-HP-HC-RE: FUNC WEAK HIDDEN {{[0-9]+}} _ZN1S1nEv
// CHECK-HP-HC-RE: FUNC WEAK HIDDEN {{[0-9]+}} _ZN1SC2Ev
// CHECK-HP-HC-RE: FUNC WEAK HIDDEN {{[0-9]+}} _ZN1SD0Ev
// CHECK-HP-HC-RE: FUNC WEAK HIDDEN {{[0-9]+}} _ZN1SD2Ev
// TODO: clang+llvm does not materialize complete ctors and dtors for the
// Itanium abi. Figure out why and add the check-not for these:
// _ZN1CC1Ev
// _ZN1CD1Ev
// _ZN1SC1Ev
// _ZN1SD1Ev
#define HIDDEN __attribute__((__visibility__("hidden")))
#define DEFAULT __attribute__((__visibility__("default")))
struct PARENT_CLASS_VISIBILITY S {
virtual ~S() {}
virtual PARENT_METHOD_VISIBILITY void n() {}
};
class CHILD_CLASS_VISIBILITY C : public S {
public:
virtual CHILD_METHOD_VISIBILITY void m() {}
};
void f() {
C c;
c.m();
c.n();
}