r230921 broke backend-optimization-failure.cpp: after
r230921, LLVM no longer emits an expression to compute 'Length - 1'
and this perturbs LoopSimplify enough to emit the warning on line 10
instead of line 9. This is a review request to fix the test case once
I re-land r230921.
llvm-svn: 231020
Fix for PR22017. Integer template arguments are automatically bit extended to
the size of the integer type. In template diffing, evaluated expressions were
not having their results extending, leading to comparing two APSInt's with
different widths. Apply the proper bit extending when evaluating template
arguments. This mainly affected bool template arguments.
llvm-svn: 230603
based on whether "redundant" braces are ever reasonable as part of the
initialization of the entity, rather than whether the initialization is
"top-level". In passing, add a warning flag for it.
llvm-svn: 228896
and only update the orginal list on a valid arugment list. When checking an
individual expression template argument, and conversions are required, update
the expression in the template argument. Since template arguments are
speculatively checked, the copying of the template argument list prevents
updating the template arguments when the list does not match the template.
Additionally, clean up the integer checking code in the template diffing code.
The code performs unneccessary conversions from APSInt to APInt.
Fixes PR21758.
This essentially reverts r224770 to recommits r224667 and r224668 with extra
changes to prevent the template instantiation problems seen in PR22006.
A test to catch the discovered problem is also added.
llvm-svn: 226983
Things that are OK:
extern int var1 __attribute((alias("v1")));
static int var2 __attribute((alias("v2")));
Things that are not OK:
int var3 __attribute((alias("v3")));
extern int var4 __attribute((alias("v4"))) = 4;
We choose to accpet:
struct S { static int var5 __attribute((alias("v5"))); };
This code causes assertion failues in GCC 4.8 and ICC 13.0.1, we have
no reason to reject it.
This partially fixes PR22217.
llvm-svn: 226436
r185773 added an assert that checked that a CXXUnresolvedConstructExpr either
has a valid rparen, or exactly one argument. This doesn't have to be true for
invalid inputs. Convert the assert to an if, and add a test for this case.
Found by SLi's afl bot.
llvm-svn: 225140
When a non-type template argument expression needs a conversion to change it
into the argument type, preserve that information by remaking the
TemplateArgument with an expression that has those conversions. Also a small
fix to template type diffing to handle the extra conversions in some cases.
llvm-svn: 224667
Instead of manually maintaining a flag indicating whether we're about to print
out the last child of the parent node (to determine whether we print "`" or
"|"), capture a callable to print that child and defer printing it until we
either see a next child or finish the parent.
No functionality change intended.
llvm-svn: 220930
Currently, when --serialize-diagnostics is passed this only includes
the diagnostics from clang -cc1, and driver diagnostics are
dropped. This causes issues for tools that use the serialized
diagnostics, since stderr is lost and these diagnostics aren't seen at
all.
We handle this by merging the diagnostics from the CC1 process and the
driver diagnostics into a single file when the driver invokes CC1.
Fixes rdar://problem/10585062
llvm-svn: 220525
Previously loop hints such as #pragma loop vectorize_width(#) required a constant. This patch allows a constant expression to be used as well. Such as a non-type template parameter or an expression (2 * c + 1).
Reviewed by Richard Smith
llvm-svn: 219589
When reading a serialized diagnostic location with no file ID, we were
failing to increment the cursor past the rest of the location. This
would lead to the flags and category always appearing blank in such
diagnostics.
This changes the function to unconditionally increment the cursor and
updates the test to check for the correct output instead of testing
that we were doing this wrong. I've also updated the error check to
check for the correct number of fields.
llvm-svn: 219538
in availability attribute by preserving this info.
in VersionTuple and using it in pretty printing of attributes
and yet using '.' as separator when diagnosing unavailable
message calls. rdar://18490958
llvm-svn: 219124
The warning warns on TypedefNameDecls -- typedefs and C++11 using aliases --
that are !isReferenced(). Since the isReferenced() bit on TypedefNameDecls
wasn't used for anything before this warning it wasn't always set correctly,
so this patch also adds a few missing MarkAnyDeclReferenced() calls in
various places for TypedefNameDecls.
This is made a bit complicated due to local typedefs possibly being used only
after their local scope has closed. Consider:
template <class T>
void template_fun(T t) {
typename T::Foo s3foo; // YYY
(void)s3foo;
}
void template_fun_user() {
struct Local {
typedef int Foo; // XXX
} p;
template_fun(p);
}
Here the typedef in XXX is only used at end-of-translation unit, when YYY in
template_fun() gets instantiated. To handle this, typedefs that are unused when
their scope exits are added to a set of potentially unused typedefs, and that
set gets checked at end-of-TU. Typedefs that are still unused at that point then
get warned on. There's also serialization code for this set, so that the
warning works with precompiled headers and modules. For modules, the warning
is emitted when the module is built, for precompiled headers each time the
header gets used.
Finally, consider a function using C++14 auto return types to return a local
type defined in a header:
auto f() {
struct S { typedef int a; };
return S();
}
Here, the typedef escapes its local scope and could be used by only some
translation units including the header. To not warn on this, add a
RecursiveASTVisitor that marks all delcs on local types returned from auto
functions as referenced. (Except if it's a function with internal linkage, or
the decls are private and the local type has no friends -- in these cases, it
_is_ safe to warn.)
Several of the included testcases (most of the interesting ones) were provided
by Richard Smith.
(gcc's spelling -Wunused-local-typedefs is supported as an alias for this
warning.)
llvm-svn: 217298
anyway. If -ast-dump *is* also provided, then dump the AST declarations as well
as the lookup results. This is invaluable for cross-correlating the lookup
information with the declarations actually found.
llvm-svn: 215393
being declared, not at the end. When pretty-printing a non-type template
parameter, put the name of the parameter in the middle of the type, not at the
end.
llvm-svn: 213718
ExtWarn/Warnings. Mostly the name of the warning was changed to match the
semantics, but in the PR20356 cases, the warning was about valid code, so the
diagnostic was changed from ExtWarn to Warning instead.
llvm-svn: 213443
Clang uses a diagnostic handler to grab diagnostic messages so it can print them
with the line of source code they refer to. This patch extends this to handle
optimization failures that were added to llvm to produce a warning when
loop vectorization is explicitly specified (using a pragma clang loop directive)
but fails.
Update renames warning flag name to avoid indicating the flag's severity and
adds a test.
Reviewed by Alp Toker
llvm-svn: 213400
We've decided to make the core rewriter class and PP rewriters mandatory.
They're only a few hundred lines of code in total and not worth supporting as a
distinct build configuration, especially since doing so disables key compiler
features.
This reverts commit r213150.
Revert "clang/test: Introduce the feature "rewriter" for --enable-clang-rewriter."
This reverts commit r213148.
Revert "Move clang/test/Frontend/rewrite-*.c to clang/test/Frontend/Rewriter/"
This reverts commit r213146.
llvm-svn: 213159
This restores the original behaviour of -fmsc-version. The older option
remains as a mechanism for specifying the basic version information. A
secondary option, -fms-compatibility-version permits the user to specify an
extended version to the driver.
The new version takes the value as a dot-separated value rather than the
major * 100 + minor format that -fmsc-version format. This makes it easier to
specify the value as well as a more flexible manner for specifying the value.
Specifying both values is considered an error.
The older parameter is left solely as a driver option, which is normalised into
the newer parameter. This allows us to retain a single code path in the
compiler itself whilst preserving the semantics of the old parameter as well as
avoid having to determine which of two formats are being used by the invocation.
The test changes are due to the fact that the compiler no longer supports the
old option, and is a direct conversion to the new option.
llvm-svn: 213119
Although this is nominally a -W option, we actually handle it in the driver
exactly as an f-group flag that's translated directly to -mllvm.
That means f_Group (and unintuitively, not W_Group) has the semantics we want
to make it behave like a standard warning flag: no automatic forwarding, no
warning for link invocations and compile-only.
Silences diagnostics like:
[691/1545] Linking CXX executable bin/llvm-diff
clang-3.5: warning: argument unused during compilation: '-Wframe-larger-than=2048'
(Hopefully we can move towards handling these in the frontend but that'll
require some infrastructure work.)
llvm-svn: 212670
When adding the implicit compound statement (required for Codegen?), the
end location was previously overridden by the start location, probably
based on the assumptions:
* The location of the compound statement should be the member's location
* The compound statement if present is the last element of a FunctionDecl
This patch changes the location of the compound statement to the
member's end location.
Code review: http://reviews.llvm.org/D4175
llvm-svn: 211344
CL permits static redeclarations to follow extern declarations. The
storage specifier on the latter declaration has no effect.
This fixes PR20034.
Differential Revision: http://reviews.llvm.org/D4149
llvm-svn: 211238
hint attributes. Includes tests for pragma printing and for attribute order
which is incorrectly reversed by ParsedAttributes.
Reviewed by Aaron Ballman
llvm-svn: 210925
The changes in r204978 broke win32-macho targets. There were checks added for
MSVC and Itanium environments as special cases, and win32-macho needs to be
treated the same way.
llvm-svn: 210584
Doing so would be inconsistent with the common fallback case where backend
diagnostics without source locations are emitted unconditionally.
llvm-svn: 210515
It turns out the trailing '=' really is part of the option name spelling and
treating it as such gets us compatible with GCC's -Werror= and pragmas.
(GCC doesn't appear to support any -Wno- form for this diagnostic but we do.)
llvm-svn: 210503
Add driver and frontend support for the GCC -Wframe-larger-than=bytes warning.
This is the first GCC-compatible backend diagnostic built around LLVM's
reporting feature.
This commit adds infrastructure to perform reverse lookup from mangled names
emitted after LLVM IR generation. We use that to resolve precise locations and
originating AST functions, lambdas or block declarations to produce seamless
codegen-guided diagnostics.
An associated change, StringMap now maintains unique mangled name strings
instead of allocating copies. This is a net memory saving in C++ and a small
hit for C where we no longer reuse IdentifierInfo storage, pending further
optimisation.
llvm-svn: 210293
Also move the attribute-specific dumping to after dumping this and
the Implicit flag.
Differential Revision: http://reviews.llvm.org/D3971
llvm-svn: 209965
Let's see how far this gets on the build servers. The application requires
native JIT and uses the C standard library, but hopefully we can get this
tested on at least some configurations.
Taking a lead from the clang-format tests, we'll just expect the executable to
get picked up from the build output path for now.
llvm-svn: 207950
These are somewhat arbitrary tests that check if "thing goes fine" when
processing various platform-specific headers.
Also move warn-sysheader.cpp to Misc where the other diagnostics infrastructure
tests live.
File moves only.
llvm-svn: 207936
order by the number of missing or extra parameters. This is useful if
there are more than a few overload candidates with arity mismatches,
particularly in the presence of -fshow-overloads=best.
llvm-svn: 207796
This is consistent with -Wbuiltin-macro-redefined, and puts this common
extension warning under a flag.
Reviewers: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D3283
llvm-svn: 205591
While investigating some debug info issues, Eric and I came across a
particular template case where the location of a decl was quite
different from the range of the same decl. It might've been rather
helpful if the dumper had actually showed us this.
llvm-svn: 205396
(for an integer too large for any signed type) from Warning to ExtWarn -- it's
ill-formed in C++11 and C99 onwards, and UB during translation in C89 and
C++98. Add diagnostic groups for two relevant diagnostics.
llvm-svn: 203974
the clang diagnostic has to report a column number one less than the correct
value in order for the IDE to move the cursor to the expected location. This
behavior is changed in VS2012 and VS2013 so that the IDE is now expecting the
column number to match the actual source location.
Before: source(line, column-1): type: message
After: source(line, column): type: message
This patch changes -fdiagnostics-format=msvc to match the new VS2012 and VS2013
when fmsc-version is 1700 or greater.
Differential Revision: http://llvm-reviews.chandlerc.com/D2949
llvm-svn: 203183
Serialized diagnostics were accidentally using the AST diagnostic level values
rather than a dedicated stable enum, so the addition of "remark" broke the
reading of existing serialized diagnostics files. I've added a .dia file
generated from Xcode 5's Clang to make sure we don't break this in the future.
llvm-svn: 202733
This starts to switch ARCMT to use proper diagnostic messages. The old use was
based on incorrect example code from the documentation.
The logic of the previous report() functions has been retained to support any
external consumers that might be intercepting diagnostic messages through the
old interface.
Note that the change in test/Misc/warning-flags.c isn't a new warning without a
flag, rather one that was previously invisible to the test. Adding a flag might
be a good idea though.
llvm-svn: 200124
'%clang -verify' will now issue an error instead of succeeding without
verification. This should catch flawed tests like r199347.
Followup to r199451.
llvm-svn: 199455
Additionally, remove the optional nature of the spelling list index when creating attributes. This is supported by table generating a Spelling enumeration when the spellings for an attribute are distinct enough to warrant it.
llvm-svn: 199378
Since this warning was generalized, it was also given a sensible warning group flag and the corresponding test was updated to reflect this.
llvm-svn: 198053
This patch was submitted to the list for review and didn't receive a LGTM.
(In fact one explicit objection and one query were raised.)
This reverts commit r197295.
llvm-svn: 197299
Previously, a line like
// expected-error-re {{foo}}
treats the entirety of foo as a regex. This is inconvenient when matching type
names containing regex characters. For example, to match
"void *(class test8::A::*)(void)" inside such a regex, one would have to type
"void \*\(class test8::A::\*\)\(void\)".
This patch changes the semantics of expected-error-re to only treat the parts
of the directive wrapped in double curly braces as regexes. This avoids the
escaping problem and leads to nicer patterns for those cases; see e.g. the
change to test/Sema/format-strings-scanf.c.
(The balanced search for closing }} of a directive also makes us handle the
full directive in test\SemaCXX\constexpr-printing.cpp:41 and :53.)
Differential Revision: http://llvm-reviews.chandlerc.com/D2388
llvm-svn: 197092
the GNU documentation: the attribute only appertains to the label if it is
followed by a semicolon. Based on a patch by Aaron Ballman!
llvm-svn: 194869
In the test case one type is coming from a typedef with no default arg, the
other has the default arg. Taking the default arg from the typedef crashes, so
always use the real template paramter declaration. PR17510.
llvm-svn: 192202
This solves two problems:
1) MSBuild will not flag the build as unsuccessful just because we print
an error in the output, since "error(clang):" doesn't seem to match
the regex it's using.
2) It becomes more clear that the diagnostic is coming from clang as
supposed to cl.exe.
Differential Revision: http://llvm-reviews.chandlerc.com/D1735
llvm-svn: 191250
This patch adds the following, more specific warning flags:
gnu-anonymous-struct
gnu-compound-literal-initializer
gnu-empty-struct
gnu-flexible-array-initializer
gnu-flexible-array-union-member
gnu-folding-constant
redeclared-class-member
gnu-redeclared-enum
gnu-union-cast
gnu-variable-sized-type-not-at-end
Patch by Peter Lewis.
llvm-svn: 190972
"long long" which is currently technically only "reserved for future" use in OpenCL, but
since clang in OpenCL mode supports it we may as well test the modifications to
the settings made for that type.
llvm-svn: 190297
Summary: I added the display of the VarDecl contained in the statement.
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1596
llvm-svn: 189941
Various tests had sprung up over the years which had --check-prefix=ABC on the
RUN line, but "CHECK-ABC:" later on. This happened to work before, but was
strictly incorrect. FileCheck is getting stricter soon though.
Patch by Ron Ofir.
llvm-svn: 188174
It turns out that Plum Hall depends on us not emitting an error on
integer literals which fit into long long, but fit into
unsigned long long. So C99 conformance requires not conforming to C99. :)
llvm-svn: 187172
Switch some warnings over to errors which should never have been warnings
in the first place. (Also, a minor fix to the preprocessor rules for
integer literals while I'm here.)
llvm-svn: 186903
attach, rather than merging all comments on the declaration chain. This gives a
more faithful dump, and has the side benefit of unbreaking uses of dump() from
within AST deserialization (where the redeclaration chain may not be sane).
llvm-svn: 182350
ASTDumper was already trying to do this & instead got an implicit bool
conversion by surprise (thus printing out 0 or 1 instead of the name of
the declaration). To avoid that issue & simplify call sites, simply make
it the normal/expected operator<<(raw_ostream&, ...) overload & simplify
all the existing call sites. (bonus: this function doesn't need to be a
member or friend, it's just using public API in DeclarationName)
llvm-svn: 181832
This is a fix for PR15895, where Clang will crash when trying to print a
template diff and the template uses an address of operator. This resulted
from expecting a DeclRefExpr when the Expr could have also been
UnaryOperator->DeclRefExpr.
llvm-svn: 181365
a comment, grab the first comment found in its class
heirarchy. Also, when a category is mossing a comment,
grab comment of its primary class. // rdar://13647476
llvm-svn: 180629
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
expressions are integer. It can also be ValueDecl expressions
Use the type information from the TemplateParameterList instead
Patch by Olivier Goffart!
llvm-svn: 178611
When support was added for declaration arguments, the case of variadic
declaration arguments was not supported. This patch fixes that problem by
not crashing when certain ValueDecl's are null.
Patch by Olivier Goffart!
llvm-svn: 178610
Value depenedent expressions for default arguments cannot be evaluated.
Instead, use the desugared template type to get an argument expression that
can be used. This is needed for both integer and declaration arguements.
Also, move this common code into a separate function.
Patch by Olivier Goffart!
llvm-svn: 178609
When the template argument is both default and value dependent, the expression
retrieved for the default argument cannot be evaluated, thus never matching
any argument value. To get the proper value, get the template argument
from the desugared template specialization. Also, output the original
expression to provide more information about the argument mismatch.
llvm-svn: 177209
continue parsing the directive rather than silently discarding it.
Allowing undef or redef of __TIME__ and __DATE__ is important to folks
who want stable, reproducible builds.
llvm-svn: 176540
This may not always be valid, but we were previously just
emitting them raw.
While here, s/isprint/isPrintable/ (using the new CharInfo).
llvm-svn: 174766
them the same if they are actually the same; having the same name isn't enough.
Similar to r174013, template template arguments were also mistakenly considered
the same when they had the same name but were in different namespaces.
In addition, when printing template template arguments, use the qualified name
if the regular name is the same.
llvm-svn: 174029
Indents were given the color blue when outputting with color.
AST dumping now looks like this:
Node
|-Node
| `-Node
`-Node
`-Node
Compared to the previous:
(Node
(Node
(Node))
(Node
(Node)))
llvm-svn: 174022
Specifically, don't print snippets, caret diagnostics, or ranges for
lines over 4096 characters. We copy the line around a few times in our
diagnostics machinery, and we have to print a caret line that's just as
long. This uses a lot of memory just to create a poor user experience as
we print out a line much too long for anyone to read...or spend extra
energy trying to fit it to -fmessage-length.
<rdar://problem/13106850>
llvm-svn: 173976
-f(no-)color-diagnostics. In addition, dumpColor() function calls are added
to force color printing. No structural changes to -ast-dump.
llvm-svn: 173548
Presumably, if the printf format has the sign explicitly requested, the user
wants to treat the data as signed.
This is a fix-up for r172739, and also includes several test changes that
didn't make it into that commit.
llvm-svn: 172762
This is inspired by a number of false positives in real code, including
PR14968. I've added test cases reduced from these false positives to
test/Sema/unused-expr.c, as well as corresponding test cases that pass the
offending expressions as arguments to a no-op macro to ensure that we do warn
there.
This also removes my previous tweak from r166522/r166534, so that we warn on
unused cast expressions in macro arguments.
There were several test cases that were using -Wunused-value to test general
diagnostic emission features; I changed those to use other warnings or warn on
a macro argument expression. I stared at the test case for PR14399 for a while
with Richard Smith and we believe the new test case exercises the same
codepaths as before.
llvm-svn: 172696
http://llvm-reviews.chandlerc.com/D269
"Added dumping of declaration comments in ASTDumper. This required moving the
comment dumping code from CommentDumper so that the indentation is correct."
Patch by Philip Craig!
llvm-svn: 172409
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
This still isn't quite right, but it fixes a crash.
I factored out findCommonParent because we need it on the result of
getImmediateExpansionRange: for a function macro, the beginning
and end of an expansion range can come out of different
macros/macro arguments, which means the resulting range is a complete
mess to handle consistently.
I also made some changes to how findCommonParent works; it works somewhat
better in some cases, and somewhat worse in others, but I think overall
it's a better balance. I'm coming to the conclusion that mapDiagnosticRanges
isn't using the right algorithm, though: chasing the caret is fundamentally
more complicated than any algorithm which only considers one FileID for the
caret can handle because each SourceLocation doesn't really have a single parent.
We need to follow the same path of choosing expansion locations and spelling
locations which the caret used to come up with the correct range
in the general case.
Fixes <rdar://problem/12847524>.
llvm-svn: 170049
Fixes a crash printing diagnostics on the gcc testsuite, and also makes
diagnostic range printing print nicer results for token pastes.
llvm-svn: 169068
working with preprocessed testcases. This causes source locations in
diagnostics to point at the spelling location instead of the presumed location,
while still keeping the semantic effects of the line directives (entering and
leaving system-header mode, primarily).
llvm-svn: 168004
caret locations and source ranges in macros. Makes ranges more accurate
in some cases, and fixes an assertion failure.
Fixes <rdar://problem/12472249>.
llvm-svn: 167353
we had the -ccc-clang-cxx and -ccc-no-clang-cxx options to force them
on or off for testing.
Clang c++ support is now production quality and these options are dead.
llvm-svn: 166986
clang itself. This dates back to clang's early days and while it looks like
some of it is still used (for kext for example), other parts are probably dead.
Remove the -ccc-clang-archs option and associated code. I don't think there
is any remaining setup where clang doesn't support an architecture but it can
expect an working gcc cross compiler to be available.
A nice side effect is that tests no longer need to differentiate architectures
that are included in production builds of clang and those that are not.
llvm-svn: 165545
warning to an error. C++ bans it, and both GCC and EDG diagnose it as
an error. Microsoft allows it, so we still warn in Microsoft
mode. Fixes <rdar://problem/11135644>.
llvm-svn: 163831
middle of UTF-8 characters, and avoid walking to such positions when adjusting
column ranges for display. Fixes a couple of hangs when rendering diagnostics.
llvm-svn: 163820
While -Wpedantic was reasonable, -Wno-pedantic would turn off a bunch of warnings that
are on by default. This counters the intention of this warning flag.
To fix this, -Wpedantic now includes extentions that are not on by default. The
remaining warnings will manifest anyway, and won't accidentally get turned off
by -Wno-pedantic.
Fixes <rdar://problem/12076105>
llvm-svn: 161695
'clang-cpp'.
For now, the test uses "REQUIRES: shell" to determine if the host system
supports "ln -s", which it uses to create a 'clang-cpp' symlink. This is a bit
hacky and should likely be directly supported by lit.cfg.
llvm-svn: 161317
scope to -Wc++11-extensions. Move extra semicolon after member function
definition diagnostic out of -pedantic, since C++ allows a single semicolon
there. Keep it in -Wextra-semi, though, since it's still questionable.
llvm-svn: 160618
- Split pedantic driver flag test into separate test file, and XFAIL on cygwin,mingw32
- Fix bug in tablegen logic where a missing '{' caused errors to be included in -Wpedantic.
llvm-svn: 159892
I suspect FileCheck might match assertion failure, even if clang/test/Misc/warning-flags.c passed the test.
> 0. Program arguments: bin/./clang -### -pedantic -Wpedantic clang/test/Driver/warning-options.cpp
llvm-svn: 159886
This patch introduces some magic in tablegen to create a "Pedantic" diagnostic
group which automagically includes all warnings that are extensions. This
allows a user to suppress specific warnings traditionally under -pedantic used
an ordinary warning flag. This also allows users to use #pragma to silence
specific -pedantic warnings, or promote them to errors, within blocks of text
(just like any other warning).
-Wpedantic is NOT an alias for -pedantic. Instead, it provides another way
to (a) activate -pedantic warnings and (b) disable them. Where they differ
is that -pedantic changes the behavior of the preprocessor slightly, whereas
-Wpedantic does not (it just turns on the warnings).
The magic in the tablegen diagnostic emitter has to do with computing the minimal
set of diagnostic groups and diagnostics that should go into -Wpedantic, as those
diagnostics that already members of groups that themselves are (transitively) members
of -Wpedantic do not need to be included in the Pedantic group directly. I went
back and forth on whether or not to magically generate this group, and the invariant
was that we always wanted extension warnings to be included in -Wpedantic "some how",
but the bookkeeping would be very onerous to manage by hand.
-no-pedantic (and --no-pedantic) is included for completeness, and matches many of the
same kind of flags the compiler already supports. It does what it says: cancels out
-pedantic. One discrepancy is that if one specifies --no-pedantic and -Weverything or
-Wpedantic the pedantic warnings are still enabled (essentially the -W flags win). We
can debate the correct behavior here.
Along the way, this patch nukes some code in TextDiagnosticPrinter.cpp and CXStoredDiagnostic.cpp
that determine whether to include the "-pedantic" flag in the warning output. This is
no longer needed, as all extensions now have a -W flag.
This patch also significantly reduces the number of warnings not under flags from 229
to 158 (all extension warnings). That's a 31% reduction.
llvm-svn: 159875
is selected. This will allow more flexibility when converting diagnostics to
use template type diffing.
Also updated the internal manual and test cases for correctly keeping the bold
attribute and for tree printing.
llvm-svn: 159463
undefined behaviour, and move the diagnostic for '' from an Error into
an ExtWarn in this group. This is important for some users of the preprocessor,
and is necessary for gcc compatibility.
llvm-svn: 159335
comparison between two templated types when they both appear in a diagnostic.
Type elision will remove indentical template arguments, which can be disabled
with -fno-elide-type. Cyan highlighting is applied to the differing types.
For more formatting, -fdiagnostic-show-template-tree will output the template
type as an indented text tree, with differences appearing inline. Template
tree works with or without type elision.
llvm-svn: 159216
because it expects a reference and receives a non-l-value.
For example, given:
int foo(int &);
template<int x> void b() { foo(x); }
clang will now print "expects an l-value for 1st argument" instead of
"no known conversion from 'int' to 'int &' for 1st argument". The change
in wording (and associated code to detect the case) was prompted by
comment #5 in PR3104, and should be the last bit of work needed for the
bug.
llvm-svn: 158691
The preprocessor's handling of diagnostic push/pops is stateful, so
encountering pragmas during a re-parse causes problems. HTMLRewrite
already filters out normal # directives including #pragma, so it's
clear it's not expected to be interpreting pragmas in this mode.
This fix adds a flag to Preprocessor to explicitly disable pragmas.
The "right" fix might be to separate pragma lexing from pragma
parsing so that we can throw away pragmas like we do preprocessor
directives, but right now it's important to get the fix in.
Note that this has nothing to do with the "hack" of re-using the
input preprocessor in HTMLRewrite. Even if we someday copy the
preprocessor instead of re-using it, the copy would (and should) include
the diagnostic level tables and have the same problems.
llvm-svn: 158214
In standard C since C89, a 'translation-unit' is syntactically defined to have
at least one "external-declaration", which is either a decl or a function
definition. In Clang the latter gives us a declaration as well.
The tricky bit about this warning is that our predefines can contain external
declarations (__builtin_va_list and the 128-bit integer types). Therefore our
AST parser now makes sure we have at least one declaration that doesn't come
from the predefines buffer.
Also, remove bogus warning about empty source files. This doesn't catch source
files that only contain comments, and never fired anyway because of our
predefines.
PR12665 and <rdar://problem/9165548>
llvm-svn: 158085
Before:
test.cc:2:18: note: place parentheses around the == expression to silence this warning
if (0 == flags & 0xdd)
^
( )
Now:
test.cc:2:18: note: place parentheses around the == expression to silence this warning
if (0 == flags & 0xdd)
^
( )
llvm-svn: 157897
show-enabled uses the command line you give it to build a CompilerInstance,
so any flags you pass will be processed as if running clang proper.
llvm-svn: 157842
a warning for an extra semi-colon after function definitions. Added logic
so that a block of semi-colons on a line will only get one warning instead
of a warning for each semi-colon.
llvm-svn: 156934
from the frontend when the location is invalid and the SourceManager null.
Instead of keeping the SourceManager object in DiagnosticRenderer, propagate it
to the calls accordingly (as reference when it is expected to not be null, or pointer
when it may be null).
This effectively makes DiagnosticRenderer not tied to a specific SourceManager,
removing a hack from TextDiagnosticPrinter.
rdar://11386874
llvm-svn: 156536
Unprintable source in diagnostics is transformed to a printable form and then
displayed with reversed colors if possible. Unprintable characters are
displayed as <U+NNNN> while bytes that do not represent valid characters are
shown as <XX>.
Column adjustments to diagnostic carets, highlighted ranges, and fixups are
made both for characters escaped as above and for characters which are
printable but take up more than a single column.
llvm-svn: 154980
This reverts commit e9a3b76ba589a8a884e978273beaed0d97cf9861.
Revert "fix display of source lines with null characters"
This reverts commit 70712b276e40bbe11e5063dfc7e82ce3209929cd.
llvm-svn: 154950
Unprintable source in diagnostics is transformed to a printable form and then
displayed with reversed colors if possible. Unprintable characters are
displayed as <U+NNNN> while bytes that do not represent valid characters are
shown as <XX>.
Column adjustments to diagnostic carets, highlighted ranges, and fixups are
made both for characters escaped as above and for characters which are
printable but take up more than a single column.
llvm-svn: 154946
This is not quite sufficient for libstdc++'s <atomic>: we still need
__atomic_test_and_set and __atomic_clear, and may need a more complete
__atomic_is_lock_free implementation.
We are also missing an implementation of __atomic_always_lock_free,
__atomic_nand_fetch, and __atomic_fetch_nand, but those aren't needed
for libstdc++.
llvm-svn: 154579
get the diagnostic category name from a serialized diagnostic when the version of libclang used
to read the diagnostic file is newer than the clang that emitted the diagnostic file.
llvm-svn: 154567
list of identifiers that that 'public' names at the end of the
translation unit, e.g., defined macros or identifiers with top-level
names, in sorted order. Meant to support <rdar://problem/10921596>.
llvm-svn: 153522
Err on the side of brevity and rename (while providing aliases for the original
name) -Wbool-conversions, -Wint-conversions, and -Wvector-conversions for
consistency with constant, literal, string, and sign conversion warnings. And
name the diagnostic groups explicitly while I'm here rather than rewriting the
string in the groups and sema td files.
Curiously, vector-conversion is not under -Wconversion. Perhaps it should be.
llvm-svn: 152776
The bug that was caught by Apple's internal buildbots was valid and also showed another bug in my implementation.
These are now fixed, with regression tests added to catch them both (not Darwin-specific).
Original log:
====================
Revert r151638 because it causes assertion hit on PCH creation for Cocoa.h
Original log:
---------------------
Correctly track tags and enum members defined in the prototype of a function, and ensure they are properly scoped.
This fixes code such as:
enum e {x, y};
int f(enum {y, x} n) {
return 0;
}
This finally fixes PR5464 and PR5477.
---------------------
I also reverted r151641 which was enhancement on top of r151638.
====================
llvm-svn: 151712
Original log:
---------------------
Correctly track tags and enum members defined in the prototype of a function, and ensure they are properly scoped.
This fixes code such as:
enum e {x, y};
int f(enum {y, x} n) {
return 0;
}
This finally fixes PR5464 and PR5477.
---------------------
I also reverted r151641 which was enhancement on top of r151638.
llvm-svn: 151667
not integer constant expressions. In passing, fix the 'folding is an extension'
diagnostic to not claim we're accepting the code, since that's not true in
-pedantic-errors mode, and add this diagnostic to -Wgnu.
llvm-svn: 148209
scope, when no other indication is provided that the user intended to declare a
function rather than a variable.
Remove some false positives from the existing 'parentheses disambiguated as a
function' warning by suppressing it when the declaration is marked as 'typedef'
or 'extern'.
Add a new warning group -Wvexing-parse containing both of these warnings.
The new warning is enabled by default; despite a number of false positives (and
one bug) in clang's test-suite, I have only found genuine bugs with it when
running it over a significant quantity of real C++ code.
llvm-svn: 147599
diagnostic message are compared. If either is a substring of the other, then
no error is given. This gives rise to an unexpected case:
// expect-error{{candidate function has different number of parameters}}
will match the following error messages from Clang:
candidate function has different number of parameters (expected 1 but has 2)
candidate function has different number of parameters
It will also match these other error messages:
candidate function
function has different number of parameters
number of parameters
This patch will change so that the verification string must be a substring of
the diagnostic message before accepting. Also, all the failing tests from this
change have been corrected. Some stats from this cleanup:
87 - removed extra spaces around verification strings
70 - wording updates to diagnostics
40 - extra leading or trailing characters (typos, unmatched parens or quotes)
35 - diagnostic level was included (error:, warning:, or note:)
18 - flag name put in the warning (-Wprotocol)
llvm-svn: 146619
-Allow it to be used with multiple BeginSourceFile/EndSourceFile calls; for this introduce
a "finish" callback method in the DiagnosticConsumer. SDiagsWriter finishes up the serialization
file inside this method.
-Make it independent of any particular DiagnosticsEngine; make it use the SourceManager of the
Diagnostic object.
-Ignore null source ranges.
llvm-svn: 146020
of the first type is the same as the aka string of the second type, but both
types are different. Update the logic to print an aka for the first type to
show that they are different.
llvm-svn: 144558
FixIts might be exposed as C string via clang_getCString(), though the zero terminator is not allocated in CXLoadedDiagnosticSetImpl::makeString.
llvm-svn: 144379
FIXME: For now, " = 0Parse Issueexpected ';' after expression{{XXX}}" would not be matched due to unexpected garbage{{XXX} on some hosts.
llvm-svn: 144374
a single issue. Along the way, tweak c-index-test -read-diagnostics output so it is easier to tell what diagnostics are
child diagnostics.
llvm-svn: 144349
__int128_t and __uint128_t. Short and unsigned short integer literals support
is only to work around a crasher as reported in PR11179 and will be removed
once Clang no longer builds short integer literals.
llvm-svn: 143977
formatting as any other diagnostic, they will be properly line wrapped and
otherwise pretty printed. Let's take advantage of that and the new factoring to
add some helpful information to them (much like template backtrace notes and
other notes): the name of the macro whose expansion is being noted. This makes
a world of difference if caret diagnostics are disabled, making the expansion
notes actually useful in this case. It also helps ensure that in edge cases the
information the user needs is present. Consider:
% nl -ba t5.cc
1 #define M(x, y, z) \
2 y
3
4 M(
5 1,
6 2,
7 3);
We now produce:
% ./bin/clang -fsyntax-only t5.cc
t5.cc:6:3: error: expected unqualified-id
2,
^
t5.cc:2:3: note: expanded from macro: M
y
^
1 error generated.
Without the added information in the note, the name of the macro being expanded
would never be shown.
This also deletes a FIXME to use the diagnostic formatting. It's not yet clear
to me that we *can* do this reasonably, and the production of this message was
my primary goal here anyways.
I'd love any comments or suggestions on improving these notes, their wording,
etc. Currently, I need to make them provide more helpful information in the
presence of a token-pasting buffer, and I'm pondering adding something along
the lines of "expanded from argument N of macro: ...".
llvm-svn: 142127
standing deficiency: we were providing no macro backtrace information
whenever caret diagnostics were turned off. This sinks the logic for
suppressing the code snippet and caret to the code that actually prints
tho code snippet and caret. Along the way, clean up the naming of
functions, remove some now fixed FIXMEs, and generally improve the
wording and logic of this process.
Add a test case exerecising this functionality. It is notable that the
resulting messages are extremely low quality. I'm working on a follow-up
patch that should address this and have left a FIXME in the test case.
llvm-svn: 142120
the important code in this test to make the test more stable. Now adding
further tests won't shift the line numbers occuring in the diagnostic
output.
llvm-svn: 142118
message. Specifically, we now only line-wrap the first line of te
diagnostic message and assume the remainder is manually formatted. While
adding it back, simplify the logic for doing this.
Finally, add a test that ensures we actually preserve this feature. =D
*Now* its not dead code. Thanks to Doug for the test case.
llvm-svn: 140538
would have caught a bug I introduced during refactoring. Silly me
thinking this was all well tested already...
If any of this is already covered by other tests, let me know. I looked
around and didn't see any.
llvm-svn: 140522
loads the named module. The syntax itself is intentionally hideous and
will be replaced at some later point with something more
palatable. For now, we're focusing on the semantics:
- Module imports are handled first by the preprocessor (to get macro
definitions) and then the same tokens are also handled by the parser
(to get declarations). If both happen (as in normal compilation),
the second one is redundant, because we currently have no way to
hide macros or declarations when loading a module. Chris gets credit
for this mad-but-workable scheme.
- The Preprocessor now holds on to a reference to a module loader,
which is responsible for loading named modules. CompilerInstance is
the only important module loader: it now knows how to create and
wire up an AST reader on demand to actually perform the module load.
- We search for modules in the include path, using the module name
with the suffix ".pcm" (precompiled module) for the file name. This
is a temporary hack; we hope to improve the situation in the
future.
llvm-svn: 138679
and 'expansions' rather than 'instantiated' and 'contexts'.
This is the first of several patches migrating Clang's terminology
surrounding macros from 'instantiation' to 'expansion'.
llvm-svn: 135135
When two different types has the same text representation in the same
diagnostic message, print an a.k.a. after the type if the a.k.a. gives extra
information about the type.
class versa_string;
typedef versa_string string;
namespace std {template <typename T> class vector;}
using std::vector;
void f(vector<string> v);
namespace std {
class basic_string;
typedef basic_string string;
template <typename T> class vector {};
void g() {
vector<string> v;
f(v);
}
}
Old message:
----------------
test.cc:15:3: error: no matching function for call to 'f'
f(&v);
^
test.cc:7:6: note: candidate function not viable: no known conversion from
'vector<string>' to 'vector<string>' for 1st argument
void f(vector<string> v);
^
1 error generated.
New message:
---------------
test.cc:15:3: error: no matching function for call to 'f'
f(v);
^
test.cc:7:6: note: candidate function not viable: no known conversion from
'vector<string>' (aka 'std::vector<std::basic_string>') to
'vector<string>' (aka 'std::vector<versa_string>') for 1st argument
void f(vector<string> v);
^
1 error generated.
llvm-svn: 134904
argument expansion to use the macro argument source locations as well.
Add a few tests to exercise this. There is still a bit more work needed
here though.
llvm-svn: 134674
instantiation and improve diagnostics which are stem from macro
arguments to trace the argument itself back through the layers of macro
expansion.
This requires some tricky handling of the source locations, as the
argument appears to be expanded in the opposite direction from the
surrounding macro. This patch provides helper routines that encapsulate
the logic and explain the reasoning behind how we step through macros
during diagnostic printing.
This fixes the rest of the test cases originially in PR9279, and later
split out into PR10214 and PR10215.
There is still some more work we can do here to improve the macro
backtrace, but those will follow as separate patches.
llvm-svn: 134660
This is a one line fix here:
+ // Don't print recursive instantiation notes from an instantiation note.
+ Loc = SM.getSpellingLoc(Loc);
While here, fix the testcase to be more precise (it got filecheck'ized
brutally), and fix EmitCaretDiagnostic to be private and to not pass down
the unused 'Level' argument.
llvm-svn: 133993
prints the file, line, and column of a diagnostic. We currently
support Clang's normal format, MSVC, and Vi formats.
Note that we no longer change the diagnostic format based on
-fms-extensions.
Patch by Andrew Fish!
llvm-svn: 131794
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
When -working-directory is passed in command line, file paths are resolved relative to the specified directory.
This helps both when using libclang (where we can't require the user to actually change the working directory)
and to help reproduce test cases when the reproduction work comes along.
--FileSystemOptions is introduced which controls how file system operations are performed (currently it just contains
the working directory value if set).
--FileSystemOptions are passed around to various interfaces that perform file operations.
--Opening & reading the content of files should be done only through FileManager. This is useful in general since
file operations will be abstracted in the future for the reproduction mechanism.
FileSystemOptions is independent of FileManager so that we can have multiple translation units sharing the same
FileManager but with different FileSystemOptions.
Addresses rdar://8583824.
llvm-svn: 118203
printed in a diagnostic, similar to the limit we already have on the
depth of the template instantiation backtrace. The macro instantiation
backtrace is limited to 10 "instantiated from:" diagnostics; when it's
longer than that, we'll show the first half, then say how many were
suppressed, then show the second half. The limit can be changed with
-fmacro-instantiation-limit=N, and turned off with N=0.
This eliminates a lot of note spew with libraries making use of the
Boost.Preprocess library.
llvm-svn: 103014
source line wider than the terminal where the associated fix-it line
is longer than the caret line. Previously, we would crash in this
case, which was rather unfortunate. Fixes <rdar://problem/7856226>.
llvm-svn: 101426
that adds parentheses from the main diagnostic down to a new
note. This way, when the fix-it represents a choice between two
options, each of the options is associted with a note. There is no
default option in such cases. For example:
/Users/dgregor/t.c:2:9: warning: & has lower precedence than ==; ==
will be
evaluated first [-Wparentheses]
if (x & y == 0) {
^~~~~~~~
/Users/dgregor/t.c:2:9: note: place parentheses around the &
expression to
evaluate it first
if (x & y == 0) {
^
( )
/Users/dgregor/t.c:2:9: note: place parentheses around the ==
expression to
silence this warning
if (x & y == 0) {
^
( )
llvm-svn: 101249
we'd add an offset from the spelling location space to the
instantiation location, which doesn't make sense and would
lead up to the text diagnostics crashing when presented with
non-sensical locations.
This fixes rdar://7597492, a crash on 255.vortex.
llvm-svn: 96004
- This is designed to make it obvious that %clang_cc1 is a "test variable"
which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it
can be useful to redefine what gets run as 'clang -cc1' (for example, to set
a default target).
llvm-svn: 91446
file. This is accomplished by introducing the notion of a "virtual"
file into the file manager, which provides a FileEntry* for a named
file whose size and modification time are known but which may not
exist on disk.
Added a cute little test that remaps both a .c file and a .h file it
includes to alternative files.
llvm-svn: 90329
-remap-file=from;to
which takes the file "from" and transparently replaces its contents
with the contents of the file "to" from the source manager's
perspective. This is the moral equivalent of
cp from saved
cp to from
<call clang>
cp saved from
rm saved
without all of the pesky file copying.
llvm-svn: 90307
column computation isn't correct and could exceed the line length, which
resulted in a buffer overflow later.
- Chris, is there a better way for this code to compute the final column used
by the caret?
llvm-svn: 84475
delta tree.
The issue is roughly a conflict in ReplaceText between two kinds of
uses. One, it should be possible to replace a replacement: for example, the
ObjC rewriter calls ReplaceStmt for an expression, then replaces the resulting
expression with another expression. Two, it should be possible to
replace text that already has text inserted before it: for example, the
HTML rewriter inserts a bunch of tags at the beginning of the line, then
tries to escape the first character on the line. This patch
distinguishes the two cases by storing the deltas separately;
essentially, replacements and insertions no longer interfere with
each other.
Another possibility would be to add some sort of flag to ReplaceText, but
this seems a bit more intuitive and flexible.
There are a few downsides to the current solution: one is that there isn't
any way to remove/replace an insertion without touching additional
surrounding text; if such an operation turns out to be useful, an
additional method or flag can be added. Another is that an insertion
and replacing a string of length zero are distinct operations; I'm not
sure how to resolve this, or whether it will be confusing in practice.
This is relatively sensitive code, so please test and tell me if
anything breaks.
llvm-svn: 72000
The "instantiated from" messages coming from the caret diagnostics system are
basically walking the macro expansion tree, emitting each level as it goes. However, it was
skipping certain leaves in the tree by skipping up the entire instantiation arm every time
it went up one spelling arm. This caused it to miss some things. For example, in this
testcase:
#define M1(x) x
#define M2 1;
void foo() {
M1(M2)
}
we now print:
/Users/sabre/Desktop/clang-unused-value-macro.c:6:2: warning: expression result unused
M1(M2)
^~~~~~
/Users/sabre/Desktop/clang-unused-value-macro.c:6:5: note: instantiated from:
M1(M2)
^~
/Users/sabre/Desktop/clang-unused-value-macro.c:3:12: note: instantiated from:
#define M2 1;
^
Previously we didn't print the last line, so we never emitted the caret pointing to the 1!
Incidentally, the spaces between the lines is really noisy, I think we should reconsider
this heuristic (which adds them when the printed code starts too close to the start of the
line).
The regression test can't use -verify, because -verify doesn't catch notes for macro
instantiation history.
llvm-svn: 71025
- The diagnostic is still poor, however. Doug, can you investigate?
- Improved the test case to not depend on the file name, now it can
be extended to actually check the formatting of the diagnostics
(I'm hoping grep -A is portable here).
llvm-svn: 70807
might be wider than we're supposed to print. In this case, we try to
select the "important" subregion of the source line, which contains
everything that we want to show (e.g., with underlining and the caret
itself) and tries to also contain some of the context.
From the fantastically long line in the test case, we get an error
message that slices down to this:
message-length.c:18:120: warning: comparison of distinct pointer types
('int *' and 'float *')
a_func_to_call(ip == FloatPointer, ip[ALongIndexName],
~~ ^ ~~~~~~~~~~~~
There are a bunch of gee-it-sounds-good heuristics in here, which seem
to do well on the various simple tests I've thrown at it. However,
we're going to need to look at a bunch more diagnostics to tweak these
heuristics.
This is the second part of <rdar://problem/6711348>. Almost there!
llvm-svn: 70597
Also, put a line of whitespace between the diagnostic and the source
code/caret line when the start of the actual source code text lines up
(or nearly lines up) with the most recent line of the diagnostic. For
example, here it's okay for the last line of the diagnostic to be
(vertically) next to the source line, because there is horizontal
whitespace to separate them:
decl-expr-ambiguity.cpp:12:16: error: function-style cast to a builtin
type can only take one argument
typeof(int)(a,5)<<a;
However, here is a case where we need the vertical separation (since
there is no horizontal separation):
message-length.c:10:46: warning: incompatible pointer types initializing 'void
(int, float, char, float)', expected 'int (*)(int, float, short,
float)'
int (*fp1)(int, float, short, float) = f;
This is part one of <rdar://problem/6711348>.
llvm-svn: 70578
by marking the predefines buffer as a system header. The problem
with stdint is that it was getting problems like this:
/Volumes/Projects/cvs/llvm/Debug/lib/clang/1.0/include/stdint.h:43:9: warning: 'long long' is an extension when C99 mode is not enabled
typedef __INT64_TYPE__ int64_t;
^
<built-in>:73:29: note: instantiated from:
#define __INT64_TYPE__ long long
^
We correctly silence warnings in system headers, but only if the
spelling location of the token came from the system header. This is
designed so that if you use a system macro in your code that you don't
get punished for its definition. This is all cool except that the
predefines buffer wasn't considered a system header.
llvm-svn: 69770
with other diagnostic mapping. In the new scheme, -Wfoo or -Wno-foo or
-Werror=foo all override the -pedantic options, and __extension__
robustly silences all extension diagnostics in their scope.
An added bonus of this change is that MAP_DEFAULT goes away, meaning that
per-diagnostic mapping information can now be stored in 2 bits, doubling
the density of the Diagnostic::DiagMapping array. This also
substantially simplifies Diagnostic::getDiagnosticLevel.
OTOH, this temporarily introduces some "macro intensive" code in
Diagnostic.cpp. This will be addressed in a later patch.
llvm-svn: 69154
wine sources. This was happening because HighlightMacros was
calling EnterMainFile multiple times on the same preprocessor
object and getting an assert due to the new #line stuff (the
file in question was bison output with #line directives).
The fix for this is to not reenter the file. Instead,
relex the tokens in raw mode, swizzle them a bit and repreprocess
the token stream. An added bonus of this is that rewrite macros
will now hilight the macro definition as well as its uses. Woo.
llvm-svn: 64480
using "-parse-ast -verify".
Updated all test cases (using a sed script) that invoked -parse-ast-check to
now use -parse-ast -verify.
Fixed a bug where using "-verify" instead of "-parse-ast-check" would not
correctly create the DiagClient needed to accumulate diagnostics.
llvm-svn: 42365
preprocessor state, causing bogus diagnostics when the file is parsed for real. This
implements Misc/diag-checker.c. Thanks to Ted for noticing this.
llvm-svn: 41000
Reid Kleckner