maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/Modules/linkage-merge.cpp

17 lines
596 B
C++
Raw Normal View History

Extended VerifyDiagnosticConsumer to also verify source file for diagnostic. 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
2013-04-17 16:06:46 +08:00
// RUN: rm -rf %t
// RUN: %clang_cc1 -verify -fmodules -fmodules-cache-path=%t -I %S/Inputs %s
Add hasExternalLinkageUncached back with the test that Richard provided, but keep the call at the current location. llvm-svn: 178741
2013-04-04 12:40:17 +08:00
#include "linkage-merge-bar.h"
static int f(int);
int f(int);
Add a module testcase with a using declaration. Thanks a lot to Richard Smith for the suggestion. llvm-svn: 178825
2013-04-05 08:52:14 +08:00
Extended VerifyDiagnosticConsumer to also verify source file for diagnostic. 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
2013-04-17 16:06:46 +08:00
static void g(int);
[modules] Rework merging of redeclaration chains on module import. We used to save out and eagerly load a (potentially huge) table of merged formerly-canonical declarations when we loaded each module. This was extremely inefficient in the presence of large amounts of merging, and didn't actually save any merging lookup work, because we still needed to perform name lookup to check that our merged declaration lists were complete. This also resulted in a loss of laziness -- even if we only needed an early declaration of an entity, we would eagerly pull in all declarations that had been merged into it regardless. We now store the relevant fragments of the table within the declarations themselves. In detail: * The first declaration of each entity within a module stores a list of first declarations from imported modules that are merged into it. * Loading that declaration pre-loads those other entities, so that they appear earlier within the redeclaration chain. * The name lookup tables list the most recent local lookup result, if there is one, or all directly-imported lookup results if not. llvm-svn: 231424
2015-03-06 07:24:12 +08:00
// FIXME: Whether we notice the problem here depends on the order in which we
// happen to find lookup results for 'g'; LookupResult::resolveKind needs to
// be taught to prefer a visible result over a non-visible one.
//
Reverting 232853 and 232870 because they depend on 232793, which was reverted because it was causing LLDB test failures llvm-svn: 232907
2015-03-22 16:47:07 +08:00
// FIXME-error@-1 {{functions that differ only in their return type cannot be overloaded}}
// FIXME-note@Inputs/linkage-merge-foo.h:2 {{previous declaration is here}}
// expected-no-diagnostics