| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
This is long-since overdue, and matches GCC 5.0. This should also be
backwards-compatible, because we already supported all of C11 as an extension
in C99 mode.
llvm-svn: 220244
|
| |
|
|
|
|
|
| |
This is at least good documentation, but also opens the possibility of
using pipefail.
llvm-svn: 185652
|
| |
|
|
| |
llvm-svn: 179142
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The GNU line marker directive was sharing code with the #line directive, but some of the warnings/errors were reporting as #line directive diagnostics in both cases.
Previously:
#line 11foo1 ==> "#line directive requires a simple digit sequence"
# 11foo1 ==> "#line directive requires a simple digit sequence"
Now, we get:
#line 11foo1 ==> "#line directive requires a simple digit sequence"
# 11foo1 ==> "GNU line marker directive requires a simple digit sequence"
llvm-svn: 179139
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is accomplished by making VerifyDiagnosticsConsumer a CommentHandler,
which then only reads the -verify directives that are actually in live
blocks of code. It also makes it simpler to handle -verify directives that
appear in header files, though we still have to manually reparse some files
depending on how they are generated.
This requires some test changes. In particular, all PCH tests now have their
-verify directives outside the "header" portion of the file, using the @line
syntax added in r159978. Other tests have been modified mostly to make it
clear what is being tested, and to prevent polluting the expected output with
the directives themselves.
Patch by Andy Gibbs! (with slight modifications)
The new Frontend/verify-* tests exercise the functionality of this commit,
as well as r159978, r159979, and r160053 (Andy's other -verify enhancements).
llvm-svn: 160068
|
| |
|
|
|
|
|
|
| |
as a gcc supported extension with usual treatment
with -pedantic (warn) and -pedantic-errors (error).
// rdar://11550996
llvm-svn: 159226
|
| |
|
|
| |
llvm-svn: 149566
|
| |
|
|
|
|
|
| |
downgrade the default-error warning to an ExtWarn in
C90/99. <rdar://problem/10668057>
llvm-svn: 147925
|
| |
|
|
|
|
|
|
|
| |
- 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
|
| |
|
|
|
|
| |
going away).
llvm-svn: 90066
|
| |
|
|
|
|
| |
- 'for i in $(find . -type f); do sed -e 's#\(RUN:.*[^ ]\) *&& *$#\1#g' $i | FileUpdate $i; done', for the curious.
llvm-svn: 86430
|
| |
|
|
| |
llvm-svn: 85236
|
| |
|
|
|
|
|
|
| |
before r69391: typedef redefinition is an error by default, but if
*either* the old or new definition are from a system header, we silence
it.
llvm-svn: 70177
|
| |
|
|
|
|
| |
to error, doing this breaks too many programs (e.g. Adium).
llvm-svn: 70170
|
| |
|
|
| |
llvm-svn: 69485
|
| |
|
|
|
|
|
| |
as decimal, even if it starts with 0. Also, since things like 0x1 are
completely illegal, don't even bother using numericliteralparser for them.
llvm-svn: 69454
|
| |
|
|
| |
llvm-svn: 69422
|
| |
|
|
| |
llvm-svn: 69403
|
| |
|
|
| |
llvm-svn: 69401
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. We had logic in sema to decide whether or not to emit the error
based on manually checking whether in a system header file.
2. we were allowing redefinitions of typedefs in class scope in C++
if in header file.
3. there was no way to force typedef redefinitions to be accepted
by the C compiler, which annoys me when stripping linemarkers out
of .i files.
The fix is to split the C++ class typedef redefinition path from the
C path, and change the C path to be a warning that normally maps to
error. This causes it to properly be ignored in system headers,
etc. and gives us a way to control it. Passing
-Wtypedef-redefinition now turns the error into a warning.
One behavior change is that we now diagnose cases where you redefine
a typedef in your .c file that was defined in a header file. This
seems like reasonable behavior, and the diagnostic now indicates that
it can be controlled with -Wtypedef-redefinition.
llvm-svn: 69391
|
| |
|
|
|
|
| |
Tests and drivers updated, still need to shuffle dirs.
llvm-svn: 67602
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
line markers, including maintenance of the virtual include stack.
For something like this:
# 42 "bar.c" 1
# 142 "bar2.c" 1
#warning zappa
# 92 "bar.c" 2
#warning gonzo
# 102 "foo.c" 2
#warning bonkta
we now produce these three warnings:
#1:
In file included from foo.c:3:
In file included from bar.c:42:
bar2.c:143:2: warning: #warning zappa
#warning zappa
^
#2:
In file included from foo.c:3:
bar.c:92:2: warning: #warning gonzo
#warning gonzo
^
#3:
foo.c:102:2: warning: #warning bonkta
#warning bonkta
^
llvm-svn: 63722
|
| |
|
|
| |
llvm-svn: 63721
|
| |
|
|
|
|
| |
play around with the 'is system header' bit now function correctly.
llvm-svn: 63720
|
| |
|
|
| |
llvm-svn: 63713
|
| |
|
|
| |
llvm-svn: 63003
|
| |
|
|
| |
llvm-svn: 63001
|
|
|
we just discard them.
llvm-svn: 62999
|
