llvm-project.git/clang/test/InterfaceStubs/template-constexpr.cpp, branch main Unnamed repository; edit this file 'description' to name the repository. [ifs] Prepare llvm-ifs for elfabi/ifs merging. 2021-07-19T18:23:00+00:00 Haowei Wu haowei@google.com 2021-04-07T22:50:12+00:00 61fa9afe4c5b014181ce41a35c84fb0f3be975db This diff changes llvm-ifs to use unified IFS file format and perform other renaming changes in preparation for the merging between elfabi/ifs. Differential Revision: https://reviews.llvm.org/D99810 
This diff changes llvm-ifs to use unified IFS file format
and perform other renaming changes in preparation for the
merging between elfabi/ifs.

Differential Revision: https://reviews.llvm.org/D99810
[llvm][clang][IFS] Enhancing the llvm-ifs yaml format for symbol lists. 2020-04-01T14:49:06+00:00 Puyan Lotfi puyan@puyan.org 2020-03-28T08:08:27+00:00 e3033c0ce5517efddbf92a079ad1e0ca4868591f 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 
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
[clang][IFS][test][NFC] Tightening up clang-ifs tests to use -cc1 more often. 2019-11-14T07:25:22+00:00 Puyan Lotfi puyan@puyan.org 2019-11-14T04:58:09+00:00 e782192d5e6540b0cbb957a6b738d98e24c88ee3 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. 
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.
[clang][IFS][test] Fixing buildbot test fails for clang-ifs. 2019-11-09T02:06:23+00:00 Puyan Lotfi puyan@puyan.org 2019-11-09T02:06:23+00:00 1257146eb41485e91cb13a6b0ccc2fb7faa68b75 Checking for the exact triple fails on many bots. Leaving the triple check blank. 
Checking for the exact triple fails on many bots. Leaving the triple
check blank.
[clang][IFS] Adds support for more decl types in clang interface stubs. 2019-11-09T01:27:25+00:00 Puyan Lotfi puyan@puyan.org 2019-11-09T01:21:28+00:00 79e345fbcc822e914fac4838dd7a4f2ddbb5fcad Adding support for processing the following Decls: NonTypeTemplateParmDecl, CXXConversionDecl, UnresolvedUsingValueDecl, UsingDecl, UsingShadowDecl, TypeAliasTemplateDecl, TypeAliasDecl, VarTemplateDecl, VarTemplateSpecializationDecl, UsingDirectiveDecl, TemplateTemplateParmDecl, ClassTemplatePartialSpecializationDecl, IndirectFieldDecl. Also, this allows for processing NamedDecls that don't have an identifier and skips over VarDecls that are dependent on template types. Differential Revision: https://reviews.llvm.org/D69995 
Adding support for processing the following Decls: NonTypeTemplateParmDecl,
CXXConversionDecl, UnresolvedUsingValueDecl, UsingDecl, UsingShadowDecl,
TypeAliasTemplateDecl, TypeAliasDecl, VarTemplateDecl,
VarTemplateSpecializationDecl, UsingDirectiveDecl, TemplateTemplateParmDecl,
ClassTemplatePartialSpecializationDecl, IndirectFieldDecl.

Also, this allows for processing NamedDecls that don't have an identifier and
skips over VarDecls that are dependent on template types.

Differential Revision: https://reviews.llvm.org/D69995