A significant number of our tests in C accidentally use functions
without prototypes. This patch converts the function signatures to have
a prototype for the situations where the test is not specific to K&R C
declarations. e.g.,
void func();
becomes
void func(void);
This is the fifth batch of tests being updated (there are a significant
number of other tests left to be updated).
Note, the behavior of -ast-print is broken. It prints functions with a
prototype (void) as if they have no prototype () in C. Some tests need
to disable strict prototype checking when recompiling the results of an
-ast-print invocation.
The modified tests fail because 64-bit XCOFF object files are not currently supported on AIX. This patch disables these tests on 64-bit AIX for now.
This patch is similar to D111887 except the failures on this patch are on a 64-bit build.
Reviewed By: shchenz, #powerpc
Differential Revision: https://reviews.llvm.org/D113049
Based on post-commit review discussion on
2bd8493847 with Richard Smith.
Other uses of forcing HasEmptyPlaceHolder to false seem OK to me -
they're all around pointer/reference types where the pointer/reference
token will appear at the rightmost side of the left side of the type
name, so they make nested types (eg: the "int" in "int *") behave as
though there is a non-empty placeholder (because the "*" is essentially
the placeholder as far as the "int" is concerned).
This was originally committed in 277623f4d5
Reverted in f9ad1d1c77 due to breakages
outside of clang - lldb seems to have some strange/strong dependence on
"char [N]" versus "char[N]" when printing strings (not due to that name
appearing in DWARF, but probably due to using clang to stringify type
names) that'll need to be addressed, plus a few other odds and ends in
other subprojects (clang-tools-extra, compiler-rt, etc).
Looks like lldb has some issues with this - somehow it causes lldb to
treat a "char[N]" type as an array of chars (prints them out
individually) but a "char [N]" is printed as a string. (even though the
DWARF doesn't have this string in it - it's something to do with the
string lldb generates for itself using clang)
This reverts commit 277623f4d5.
Based on post-commit review discussion on
2bd8493847 with Richard Smith.
Other uses of forcing HasEmptyPlaceHolder to false seem OK to me -
they're all around pointer/reference types where the pointer/reference
token will appear at the rightmost side of the left side of the type
name, so they make nested types (eg: the "int" in "int *") behave as
though there is a non-empty placeholder (because the "*" is essentially
the placeholder as far as the "int" is concerned).
Currently TypePrinter lumps anonymous classes and unnamed classes in one group "anonymous" this is not correct and can be confusing in some contexts.
Differential Revision: https://reviews.llvm.org/D96807
Currently TypePrinter lumps anonymous classes and unnamed classes in one group "anonymous" this is not correct and can be confusing in some contexts.
Differential Revision: https://reviews.llvm.org/D96807
This allows ASTs to be merged when they contain GenericSelectionExpr
nodes (this is _Generic from C11). This is needed, for example, for
CTU analysis of C code that makes use of _Generic, like the Linux
kernel.
The node is already supported in the AST, but it didn't have a matcher
in ASTMatchers. So, this change adds the matcher and adds support to
ASTImporter. Additionally, this change adds support for structural
equivalence of _Generic in the AST.
Reviewed By: martong, aaron.ballman
Differential Revision: https://reviews.llvm.org/D92600
Changes:
- initializer expressions of constexpr variable are now wraped in a ConstantExpr. this is mainly used for testing purposes. the old caching system has not yet been removed.
- Add all the missing Serialization and Importing for APValue.
- Improve dumping of APValue when ASTContext isn't available.
- Cleanup leftover from last patch.
- Add Tests for Import and serialization.
Differential Revision: https://reviews.llvm.org/D63640
During the import of attributes we forgot to set the spelling list
index. This caused a segfault when we wanted to traverse the AST
(e.g. by the dump() method).
Differential Revision: https://reviews.llvm.org/D89318
During the import of FormatAttrs we forgot to import the type (e.g
`__scanf__`) of the attribute. This caused a segfault when we wanted to
traverse the AST (e.g. by the dump() method).
Differential Revision: https://reviews.llvm.org/D89319
Summary:
Clang uses the location identifier should be inserted for declarator
decls when a decl is unnamed. But for type template and template template
paramaters it uses the location of "typename/class" keyword, which makes it hard
for tooling to insert/change parameter names.
This change tries to unify these two cases by making template parameter
parsing and sourcerange operations similar to function params/declarator decls.
Reviewers: ilya-biryukov
Subscribers: arphaman, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D68143
llvm-svn: 373340
Summary:
We add a new member which is a mapping from the already-imported
declarations in the "from" context to the error status of the import of
that declaration. This map contains only the declarations that were not
correctly imported. The same declaration may or may not be included in
ImportedDecls. This map is updated continuously during imports and never
cleared (like ImportedDecls). In Import(Decl*) we use this mapping, so
if there was a previous failed import we return with the existing error.
We add/remove from the Lookuptable in consistency with ImportedFromDecls.
When we map a decl in the 'to' context to something in the 'from'
context then and only then we add it to the lookup table. When we
remove a mapping then and only then we remove it from the lookup table.
This patch is the first in a series of patches whose aim is to further
strengthen the error handling in ASTImporter.
Reviewers: a_sidorin, a.sidorin, shafik
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D62373
llvm-svn: 364279
I belive many of these diagnostics changed from errors to warnings in
r357394. I've simply mechanically updated the tests, but whoever owns
this code should probably audit for unintented behavior changes. I
wasn't able to find a flag to make these warnings errors again.
llvm-svn: 360701
I think there must be a bug in git-llvm causing parent directories to be
deleted when the diff deletes files in a subdirectory. Perhaps it is
Windows-only.
There has been a behavior change, so some of these tests now fail. I
have marked them XFAIL and will fix them in a follow-up to separate the
changes.
llvm-svn: 360699
Summary:
This allows ASTs to be merged when they contain ChooseExpr (the GNU
__builtin_choose_expr construction). This is needed, for example, for
cross-CTU analysis of C code that makes use of __builtin_choose_expr.
The node is already supported in the AST, but it didn't have a matcher
in ASTMatchers. So, this change adds the matcher and adds support to
ASTImporter.
This was originally reviewed and approved in
https://reviews.llvm.org/D58292 and submitted as r354832. It was
reverted in r354839 due to failures on the Windows CI builds.
This version fixes the test failures on Windows, which were caused by
differences in template expansion between versions of clang on different
OSes. The version of clang built with MSVC and running on Windows never
expands the template in the C++ test in ImportExpr.ImportChooseExpr in
clang/unittests/AST/ASTImporter.cpp, but the version on Linux does for
the empty arguments and -fms-compatibility.
So, this version of the patch drops the C++ test for
__builtin_choose_expr, since that version was written to catch
regressions of the logic for isConditionTrue() in the AST import code
for ChooseExpr, and those regressions are also caught by
ASTImporterOptionSpecificTestBase.ImportChooseExpr, which does work on
Windows.
Reviewers: shafik, a_sidorin, martong, aaron.ballman, rnk, a.sidorin
Subscribers: cfe-commits, jdoerfert, rnkovacs, aaron.ballman
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58663
llvm-svn: 354916
Summary:
This allows ASTs to be merged when they contain ChooseExpr (the GNU
__builtin_choose_expr construction). This is needed, for example, for
cross-CTU analysis of C code that makes use of __builtin_choose_expr.
The node is already supported in the AST, but it didn't have a matcher
in ASTMatchers. So, this change adds the matcher and adds support to
ASTImporter.
Reviewers: shafik, a_sidorin, martong, aaron.ballman
Subscribers: aaron.ballman, rnkovacs, jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58292
llvm-svn: 354832
Summary:
At equality check of fields without name the index of fields is compared.
At determining the index of a field all fields of the parent context
should be loaded from external source to find the field at all.
Reviewers: a.sidorin, a_sidorin, r.stahl
Reviewed By: a.sidorin
Subscribers: martong, cfe-commits
Differential Revision: https://reviews.llvm.org/D49796
llvm-svn: 339226
Summary:
With this patch when any `FunctionDecl` of a redeclaration chain is imported
then we bring in the whole declaration chain. This involves functions and
function template specializations. Also friend functions are affected. The
chain is imported as it is in the "from" tu, the order of the redeclarations
are kept. I also changed the lookup logic in order to find friends, but first
making them visible in their declaration context. We may have long
redeclaration chains if all TU contains the same prototype, but our
measurements shows no degradation in time of CTU analysis (Tmux, Xerces,
Bitcoin, Protobuf). Also, as further work we could squash redundant
prototypes, but first ensure that functionality is working properly; then
should we optimize.
This may seem like a huge patch, sorry about that. But, most of the changes are
new tests, changes in the production code is not that much. I also tried to
create a smaller patch which does not affect specializations, but that patch
failed to pass some of the `clang-import-test`s because there we import
function specializations. Also very importantly, we can't just change the
import of `FunctionDecl`s without changing the import of function template
specializations because they are handled as `FunctionDecl`s.
Reviewers: a.sidorin, r.stahl, xazax.hun, balazske, a_sidorin
Reviewed By: a_sidorin
Subscribers: labath, aprantl, a_sidorin, rnkovacs, dkrupp, cfe-commits
Differential Revision: https://reviews.llvm.org/D47532
Re-apply commit rC335480
llvm-svn: 335731
Summary:
At import of a record describing a template set its type to
InjectedClassNameType (instead of RecordType).
Reviewers: a.sidorin, martong, r.stahl
Reviewed By: a.sidorin, martong, r.stahl
Subscribers: a_sidorin, rnkovacs, martong, cfe-commits
Differential Revision: https://reviews.llvm.org/D47450
Patch by Balazs Keri!
llvm-svn: 335600
Summary:
With this patch when any `FunctionDecl` of a redeclaration chain is imported
then we bring in the whole declaration chain. This involves functions and
function template specializations. Also friend functions are affected. The
chain is imported as it is in the "from" tu, the order of the redeclarations
are kept. I also changed the lookup logic in order to find friends, but first
making them visible in their declaration context. We may have long
redeclaration chains if all TU contains the same prototype, but our
measurements shows no degradation in time of CTU analysis (Tmux, Xerces,
Bitcoin, Protobuf). Also, as further work we could squash redundant
prototypes, but first ensure that functionality is working properly; then
should we optimize.
This may seem like a huge patch, sorry about that. But, most of the changes are
new tests, changes in the production code is not that much. I also tried to
create a smaller patch which does not affect specializations, but that patch
failed to pass some of the `clang-import-test`s because there we import
function specializations. Also very importantly, we can't just change the
import of `FunctionDecl`s without changing the import of function template
specializations because they are handled as `FunctionDecl`s.
Reviewers: a.sidorin, r.stahl, xazax.hun, balazske
Subscribers: rnkovacs, dkrupp, cfe-commits
Differential Revision: https://reviews.llvm.org/D47532
llvm-svn: 335480
There are only a few cases of importing a frienddecl which is currently supported.
This patch aims to improve the friend import process.
Set FriendObjectKind in case of decls, insert friend into the friend chain
correctly, checks structurally equivalent in a more advanced manner.
Test cases added as well.
llvm-svn: 330847
Found via codespell -q 3 -I ../clang-whitelist.txt
Where whitelist consists of:
archtype
cas
classs
checkk
compres
definit
frome
iff
inteval
ith
lod
methode
nd
optin
ot
pres
statics
te
thru
Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few
files that have dubious fixes reverted.)
Differential revision: https://reviews.llvm.org/D44188
llvm-svn: 329399
Also, a number of style and bug fixes was done:
* ASTImporterTest: added sanity check for source node
* ExternalASTMerger: better lookup for template specializations
* ASTImporter: don't add templated declarations into DeclContext
* ASTImporter: introduce a helper, ImportTemplateArgumentListInfo getting SourceLocations
* ASTImporter: proper set ParmVarDecls for imported FunctionProtoTypeLoc
Differential Revision: https://reviews.llvm.org/D42301
llvm-svn: 323519
When the SearchName is already calculated we should use that for the lookup.
Patch by Peter Szecsi!
Differential Revision: https://reviews.llvm.org/D30877
llvm-svn: 299354
As outlined in a previous RFC, the test/ASTMerge/Inputs folder is getting full and the tests are starting to become interdependent. This is undesirable because
- it makes it harder to write new tests
- it makes it harder to figure out at a glance what old tests are doing, and
- it adds the risk of breaking one test while changing a different one, because of the interdependencies.
To fix this, according to the conversation in the RFC, I have changed the layout from
a.c
Inputs/a1.c
Inputs/a2.c
to
a/test.c
a/Inputs/a1.c
a/Inputs/a2.c
for all existing tests. I have also eliminated interdependencies by replicating the input files for each test that uses them.
https://reviews.llvm.org/D26571
llvm-svn: 287129
expansions by calling getSpellingLoc(). That's great in most cases, but for
macros defined in the '<built-in>' source file, the source file is invalid
and does not import correctly, causing an assertion failure (the assertion
is Invalid SLocOffset or bad function choice).
A more reliable way to avoid this is to use getFileLoc(), which does not
return built-in locations. This avoids the crash but still preserves valid
source locations.
I've added a testcase that covers the previously crashing scenario.
https://reviews.llvm.org/D26054
llvm-svn: 286144
Aaron Ballman