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
Richard Trieu