maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/PCH/check-deserializations.cpp

38 lines
745 B
C++
Raw Normal View History

MS ABI: Add triple to test relying on key functions llvm-svn: 230447
2015-02-25 10:16:15 +08:00
// RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-pch -o %t.1 %s
// RUN: %clang_cc1 -triple x86_64-linux-gnu -error-on-deserialized-decl S1_keyfunc -error-on-deserialized-decl S3 -include-pch %t.1 -emit-pch -o %t.2 %s
// RUN: %clang_cc1 -triple x86_64-linux-gnu -error-on-deserialized-decl S1_method -error-on-deserialized-decl S3 -include-pch %t.2 -emit-llvm-only %s
Allow deserialization of just the fields of a record, when we want to iterate over them, instead of deserializing the complete declaration context of the record. Iterating over the fields of a record is very common (e.g to determine the layout), unfortunately we needlessly deserialize every declaration that the declaration context of the record contains; this can be bad for large C++ classes that contain a lot of methods. Fix this by allow deserialization of just the fields when we want to iterate over them. Progress for rdar://7260160. llvm-svn: 116507
2010-10-15 04:14:34 +08:00
Fix bots failing on an explicit triple Why do we need a registered target for this? llvm-svn: 230450
2015-02-25 10:32:00 +08:00
// FIXME: Why does this require an x86 target?
// REQUIRES: x86-registered-target
Be lazier when loading KeyFunctions from PCH/modules. We don't need to load these in eagerly if we're not actually processing a translation unit. The added laziness here also avoids us loading in parts of a CXXRecordDecl earlier than an upcoming class template specialization merging patch would like. Ideally, we should mark the vtable as used when we see a definition for the key function, rather than having a separate pass over dynamic classes at the end of the TU. The existing approach is pretty bad for PCH/modules, since it forcibly loads the declarations of all key functions in all imported modules, whether or not those key functions are defined. llvm-svn: 189627
2013-08-30 07:59:27 +08:00
#ifndef HEADER1
#define HEADER1
Allow deserialization of just the fields of a record, when we want to iterate over them, instead of deserializing the complete declaration context of the record. Iterating over the fields of a record is very common (e.g to determine the layout), unfortunately we needlessly deserialize every declaration that the declaration context of the record contains; this can be bad for large C++ classes that contain a lot of methods. Fix this by allow deserialization of just the fields when we want to iterate over them. Progress for rdar://7260160. llvm-svn: 116507
2010-10-15 04:14:34 +08:00
// Header.
struct S1 {
Be lazier when loading KeyFunctions from PCH/modules. We don't need to load these in eagerly if we're not actually processing a translation unit. The added laziness here also avoids us loading in parts of a CXXRecordDecl earlier than an upcoming class template specialization merging patch would like. Ideally, we should mark the vtable as used when we see a definition for the key function, rather than having a separate pass over dynamic classes at the end of the TU. The existing approach is pretty bad for PCH/modules, since it forcibly loads the declarations of all key functions in all imported modules, whether or not those key functions are defined. llvm-svn: 189627
2013-08-30 07:59:27 +08:00
void S1_method();
Store in PCH the key function of C++ class to avoid deserializing the complete declaration context in order to compute it. Progress for rdar://7260160. llvm-svn: 116508
2010-10-15 04:14:38 +08:00
virtual void S1_keyfunc();
Allow deserialization of just the fields of a record, when we want to iterate over them, instead of deserializing the complete declaration context of the record. Iterating over the fields of a record is very common (e.g to determine the layout), unfortunately we needlessly deserialize every declaration that the declaration context of the record contains; this can be bad for large C++ classes that contain a lot of methods. Fix this by allow deserialization of just the fields when we want to iterate over them. Progress for rdar://7260160. llvm-svn: 116507
2010-10-15 04:14:34 +08:00
};
Don't eagerly load all conversion operators when loading a class declaration from a PCH/module. llvm-svn: 189646
2013-08-30 12:46:40 +08:00
struct S3 {};
struct S2 {
operator S3();
};
Be lazier when loading KeyFunctions from PCH/modules. We don't need to load these in eagerly if we're not actually processing a translation unit. The added laziness here also avoids us loading in parts of a CXXRecordDecl earlier than an upcoming class template specialization merging patch would like. Ideally, we should mark the vtable as used when we see a definition for the key function, rather than having a separate pass over dynamic classes at the end of the TU. The existing approach is pretty bad for PCH/modules, since it forcibly loads the declarations of all key functions in all imported modules, whether or not those key functions are defined. llvm-svn: 189627
2013-08-30 07:59:27 +08:00
#elif !defined(HEADER2)
#define HEADER2
// Chained PCH.
Don't eagerly load all conversion operators when loading a class declaration from a PCH/module. llvm-svn: 189646
2013-08-30 12:46:40 +08:00
S1 *s1;
S2 *s2;
Allow deserialization of just the fields of a record, when we want to iterate over them, instead of deserializing the complete declaration context of the record. Iterating over the fields of a record is very common (e.g to determine the layout), unfortunately we needlessly deserialize every declaration that the declaration context of the record contains; this can be bad for large C++ classes that contain a lot of methods. Fix this by allow deserialization of just the fields when we want to iterate over them. Progress for rdar://7260160. llvm-svn: 116507
2010-10-15 04:14:34 +08:00
#else
Be lazier when loading KeyFunctions from PCH/modules. We don't need to load these in eagerly if we're not actually processing a translation unit. The added laziness here also avoids us loading in parts of a CXXRecordDecl earlier than an upcoming class template specialization merging patch would like. Ideally, we should mark the vtable as used when we see a definition for the key function, rather than having a separate pass over dynamic classes at the end of the TU. The existing approach is pretty bad for PCH/modules, since it forcibly loads the declarations of all key functions in all imported modules, whether or not those key functions are defined. llvm-svn: 189627
2013-08-30 07:59:27 +08:00
// Using the headers.
Allow deserialization of just the fields of a record, when we want to iterate over them, instead of deserializing the complete declaration context of the record. Iterating over the fields of a record is very common (e.g to determine the layout), unfortunately we needlessly deserialize every declaration that the declaration context of the record contains; this can be bad for large C++ classes that contain a lot of methods. Fix this by allow deserialization of just the fields when we want to iterate over them. Progress for rdar://7260160. llvm-svn: 116507
2010-10-15 04:14:34 +08:00
Don't eagerly load all conversion operators when loading a class declaration from a PCH/module. llvm-svn: 189646
2013-08-30 12:46:40 +08:00
void test(S1*, S2*) {
Allow deserialization of just the fields of a record, when we want to iterate over them, instead of deserializing the complete declaration context of the record. Iterating over the fields of a record is very common (e.g to determine the layout), unfortunately we needlessly deserialize every declaration that the declaration context of the record contains; this can be bad for large C++ classes that contain a lot of methods. Fix this by allow deserialization of just the fields when we want to iterate over them. Progress for rdar://7260160. llvm-svn: 116507
2010-10-15 04:14:34 +08:00
}
#endif