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
distinct anonymous structs remain distinct despite having similar layout.
This is already ensured by distinguishing based on their placement in the parent
struct, using the function `findAnonymousStructOrUnionIndex`.
The problem is that this function only handles anonymous structs, like
```
class Foo { struct { int a; } }
```
and not untagged structs like
```
class Foo { struct { int a; } var; }
```
Both need to be handled, and this patch fixes that. The test case ensures that this functionality doesn't regress.
Thanks to Manman Ren for review.
https://reviews.llvm.org/D22270
llvm-svn: 275460
Also added named casts and propagation of "implicit" to fix the LLDB testsuite.
This is a fixed commit of r269546, which was reverted by r269575.
Thanks to Aleksei Sidorin for review and advice.
llvm-svn: 269693
Every class as parsed by Clang has a forward declaration of itself as a member:
class A {
class A;
...
}
but when the parser generates this it ensures that the RecordTypes for the two
are the same. This makes (among other things) inheritance work. This patch
fixes a bug where the ASTImporter generated two separate RecordTypes when
importing the class and the contained forward declaration, and adds a test case.
Thanks to Doug Gregor for advice on this.
llvm-svn: 269551
These test updates almost exclusively around the change in behavior
around enum: enums without a definition are considered incomplete except
when targeting MSVC ABIs. Since these tests are interested in the
'incomplete-enum' behavior, restrict them to %itanium_abi_triple.
llvm-svn: 249660
Summary:
Hexagon is being updated, but there is not enough to pass these tests.
These sections are now on top of Colin's list.
Test Plan: Ran changes on hexagon-build-03.
Reviewers: colinl, rfoos
Reviewed By: rfoos
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D9356
llvm-svn: 236173
some bugs in the ASTImporter that this exposed:
- When importing functions, the body (if any) was
previously ignored. This patch ensures that the
body is imported also.
- When a function-local Decl is imported, the first
thing the ASTImporter does is import its context
(via ImportDeclParts()). This can trigger
importing the Decl again as part of the body of
the function (but only once, since the function's
Decl has been added to ImportedDecls). This patch
fixes that problem by extending ImportDeclParts()
to return the imported Decl if it was imported as
part of importing its context, and the patch adds
ASTImporter::GetAlreadyImportedOrNull() to support
this query. All callers of ImportDeclParts return
the imported version of the Decl if ImportDeclParts()
returns it.
- When creating functions, InnerLocStart of the source
function was re-used without importing. This is a
straight up bug, and this patch makes ASTImporter
import the InnerLocStart and use the imported version.
- When importing FileIDs, the ASTImporter previously
always tried to re-load the file for the corresponding
CacheEntry from disk. This doesn't work if the
CacheEntry corresponds to a named memory buffer. This
patch changes the code so that if the UniqueID for the
cache entry is invalid (i.e., it is not a disk file)
the whole entry is treated as if it were invalid, which
forces an in-memory copy of the buffer.
Also added test cases, using the new support committed in
236011.
llvm-svn: 236012
By adding a default config.excludes pattern we can avoid individual
suppressions in subdirectories.
This matches LLVM's lit.cfg which also excludes a few other common non-test
filenames for consistency.
llvm-svn: 194814
VerifyDiagnosticConsumer previously would not check that the diagnostic and
its matching directive referenced the same source file. Common practice was
to create directives that referenced other files but only by line number,
and this led to problems such as when the file containing the directive
didn't have enough lines to match the location of the diagnostic in the
other file, leading to bizarre file formatting and other oddities.
This patch causes VerifyDiagnosticConsumer to match source files as well as
line numbers. Therefore, a new syntax is made available for directives, for
example:
// expected-error@file:line {{diagnostic message}}
This extends the @line feature where "file" is the file where the diagnostic
is generated. The @line syntax is still available and uses the current file
for the diagnostic. "file" can be specified either as a relative or absolute
path - although the latter has less usefulness, I think! The #include search
paths will be used to locate the file and if it is not found an error will be
generated.
The new check is not optional: if the directive is in a different file to the
diagnostic, the file must be specified. Therefore, a number of test-cases
have been updated with regard to this.
This closes out PR15613.
llvm-svn: 179677
produce a note for that diagnostic either with a different DiagnosticEngine or
after calling DiagnosticEngine::Reset(). That didn't make any sense, and did the
wrong thing if the original diagnostic was suppressed.
llvm-svn: 170636
The old behavior was to re-scan any files (like modules) where we may have
directives but won't actually be parsing during the -verify invocation.
Now, we keep the old behavior in Debug builds as a sanity check (though
modules are a known entity), and expect all legitimate directives to come
from comments seen by the preprocessor.
This also affects the ARC migration tool, which captures diagnostics in
order to filter some out. This change adds an explicit cleanup to
CaptureDiagnosticsConsumer in order to let its sub-consumer handle the
real end of diagnostics.
This was originally split into four patches, but the tests do not run
cleanly without all four, so I've combined them into one commit.
Patches by Andy Gibbs, with slight modifications from me.
llvm-svn: 161650
-Add the location of the class name to all objc container decls, not just ObjCInterfaceDecl.
-Make objc decls consistent with the rest of the NamedDecls and have getLocation() point to the
class name, not the location of '@'.
llvm-svn: 141061
required modifying a few tests that specifically use note include stacks
to check the source manager's view of include stacks. I've simply added
the flag to these tests for now, they may have to be more substantially
changed if we decide to remove support for note include stacks
altogether.
Also, add a test for include stacks on notes that was supposed to go in
with the previous commit.
llvm-svn: 128390
Aleksei Sidorin