walks through DeclContexts properly, and prints more of the
information available in the AST. The functionality is still available
via -ast-print, -ast-dump, etc., and also via the new member functions
Decl::dump() and Decl::print().
llvm-svn: 72597
printing logic to help customize the output. For now, we use this
rather than a special flag to suppress the "struct" when printing
"struct X" and to print the Boolean type as "bool" in C++ but "_Bool"
in C.
llvm-svn: 72590
specifier resulted in the creation of a new TagDecl node, which
happens either when the tag specifier was a definition or when the tag
specifier was the first declaration of that tag type. This information
has several uses, the first of which is implemented in this commit:
1) In C++, one is not allowed to define tag types within a type
specifier (e.g., static_cast<struct S { int x; } *>(0) is
ill-formed) or within the result or parameter types of a
function. We now diagnose this.
2) We can extend DeclGroups to contain information about any tags
that are declared/defined within the declaration specifiers of a
variable, e.g.,
struct Point { int x, y, z; } p;
This will help improve AST printing and template instantiation,
among other things.
3) For C99, we can keep track of whether a tag type is defined
within the type of a parameter, to properly cope with cases like,
e.g.,
int bar(struct T2 { int x; } y) {
struct T2 z;
}
We can also do similar things wherever there is a type specifier,
e.g., to keep track of where the definition of S occurs in this
legal C99 code:
(struct S { int x, y; } *)0
llvm-svn: 72555
within a template now have a link back to the enumeration from which
they were instantiated. This means that we can now find the
instantiation of an anonymous enumeration.
llvm-svn: 72482
an integral constant expression, maintain a cache of the value and the
is-an-ICE flag within the VarDecl itself. This eliminates
exponential-time behavior of the Fibonacci template metaprogram.
llvm-svn: 72428
compiled with -fobjc-sender-dependent-dispatch. This is used in AOP, COP, implementing object
planes, and a few other things.
Patch by David Chisnall.
llvm-svn: 72275
- Skip semantic analysis of the "if" condition if it is type-dependent.
- Added the location of the "else" keyword into IfStmt, so that we can
provide it for type-checking after template instantiation.
llvm-svn: 71875
buffer. This caused exciting nonsense like this:
$ clang t.c -fsyntax-only -UMACRO
In file included from <built-in>:104:
<command line>:1:14: warning: extra tokens at end of #undef directive [-Wextra-tokens]
#undef MACRO 1
^
//
1 diagnostic generated.
rdar://6891800
llvm-svn: 71860
template to the FunctionDecls from which they were instantiated. This
is a necessary first step to support instantiation of the definitions
of such functions, but by itself does essentially nothing.
llvm-svn: 71792
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
'objc_ownership_cfretain' -> 'cf_ownership_retain'
'objc_ownership_cfrelease' -> 'cf_ownership_release'
Motivation: Core Foundation objects can be used in isolation from Objective-C,
and this forces users to reason about the separate semantics of CF objects. More
Sema support pending.
llvm-svn: 70884
1) First of all, we treat _ as part of an identifier and not as
punctuation (oops).
2) Second of all, always make sure that the token that the ^ is
pointing at is fully within the "interesting" part of the range.
llvm-svn: 70831
- 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
fix-it hint is much worse than no fix-it hint. (Fixes PR4084).
When we need to truncate a source line to fix in the terminal, make
sure to take the width of the fix-it information into account, too.
llvm-svn: 70656
show an ellipsis where we have removed text. An example:
/Users/dgregor/Projects/llvm/tools/clang/test/Misc/message-length.c:18:120:
warning:
comparison of distinct pointer types ('int *' and 'float *')
...a_func_to_call(ip == FloatPointer, ip[ALongIndexName], ...
~~ ^ ~~~~~~~~~~~~
llvm-svn: 70655
word-wrapping by default in Emacs; yay!). Thanks, Daniel.
Use LLVM's System layer rather than calling isatty() directly.
Fix a thinko in printing the indentation string that was causing some
weird output.
llvm-svn: 70654
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
compatible with VC++ and GCC. The codegen/mangling angle hasn't
been fully ironed out yet. Note that we accept int128_t even in
32-bit mode, unlike gcc.
llvm-svn: 70464
- Add an (optional) short description for BugReports for clients that want
to distinguish between long and short descriptions for bugs
- Make the bug report for VLA less obscene for Plist diagnostics by using
the short description
llvm-svn: 70415
which eliminates the storage for IdentifierInfo in the "uninteresting
identifier" cases. Sadly, this only brought back 7k of the 500k we
lost :(
llvm-svn: 70325
line when using a PCH that were not provided when building the PCH
file. If those names were used as identifiers somewhere in the PCH
file, reject the PCH file.
llvm-svn: 70321
for identifiers to separate "interesting" from "uninteresting"
identifiers. However, to cope with compiler invocations where the
predefines buffers mismatch, we need to be able to search the complete
identifier table. Cocoa.h.pch is now about 500k larger that it used to
be :(
llvm-svn: 70320
PCH file and the predefines buffer used when including the PCH
file. We (explicitly) detect conflicting macro definitions (rejecting
the PCH file) and about missing macro definitions (they'll be
automatically pulled from the PCH file anyway).
We're missing some checking to make sure that new macro definitions
won't have any impact on the PCH file itself (e.g., #define'ing an
identifier that the PCH file used).
llvm-svn: 70316
Clang version value rather than hard-coding "1.0".
Add PCH and Clang version information into the PCH file. Reject PCH
files with the wrong version information.
llvm-svn: 70264
essentially the same thing we do with pretokenized headers. stat()
caching improves performance of the Cocoa-prefixed "Hello, World" by
45%.
llvm-svn: 70223
as 'objc_ownership_cfretain' except that the method acts like a CFRetain instead
of a [... retain] (important in GC modes). Checker support is wired up, but
currently only for Objective-C message expressions (not function calls).
llvm-svn: 70218
parm var decls in leopard cocoa.h end up using this abbreviation,
which shrinks the bitcode file by about 50K: 7217736->7167120.
Before:
Block ID #12 (DECLS_BLOCK):
Num Instances: 1
Total Size: 2.23595e+07b/2.79494e+06B/698736W
% of file: 38.7233
Num SubBlocks: 0
Num Abbrevs: 0
Num Records: 139387
% Abbrev Recs: 0
After:
Block ID #12 (DECLS_BLOCK):
Num Instances: 1
Total Size: 2.02405e+07b/2.53006e+06B/632516W
% of file: 35.301
Num SubBlocks: 0
Num Abbrevs: 1
Num Records: 139387
% Abbrev Recs: 19.2902
llvm-svn: 70199
file. In particular, only eagerly load source location entries for
files and for the predefines buffer. Other buffers and
macro-instantiation source location entries are loaded lazily.
With the Cocoa-prefixed "Hello, World", we only load 815/26555 source
location entities. This halves the amount of user time we spend in
this "Hello, World" program with -fsyntax-only (down to .007s).
This optimization is part 1 of 2 for the source manager. This
eliminates most of the user time in loading a PCH file. We still spend
too much time initialize File structures (especially in the calls to
stat), so we need to either make the loading of source location
entries for files lazy or import the stat cache from the PTH
implementation.
llvm-svn: 70196
eventually get an option to turn this off, but it is nice for looking at
statistics. For example, the types block now prints:
Block ID #11 (TYPES_BLOCK_ID):
Num Instances: 1
Total Size: 895100b/111888B/27971.9W
% of file: 1.55801
Num SubBlocks: 0
Num Abbrevs: 0
Num Records: 14899
% Abbrev Recs: 0
Code Histogram:
5478 TYPE_FUNCTION_PROTO
2683 TYPE_TYPEDEF
2460 TYPE_POINTER
2047 TYPE_ENUM
1553 TYPE_RECORD
283 TYPE_CONSTANT_ARRAY
274 TYPE_OBJC_INTERFACE
76 TYPE_INCOMPLETE_ARRAY
10 TYPE_VECTOR
9 TYPE_OBJC_QUALIFIED_ID
5 TYPE_FUNCTION_NO_PROTO
5 TYPE_EXT_QUAL
3 TYPE_TYPEOF_EXPR
llvm-svn: 70166
- Deal with the Receiver/ClassInfo shared storage in ObjCMessageExpr
- Implement PCH support for ImplicitParamDecl
- Fix the handling of the body of an ObjCMethodDecl
- Several cast -> cast_or_null fixes
- Make Selector::getIdentifierInfoForSlot work for 1-argument, NULL
selectors.
- Make Selector::getAsString() work with NULL selectors.
- Fix the names of VisitObjCAtCatchStmt and VisitObjCAtFinallyStmt
in the PCH reader and writer; these were never getting called.
At this point, all of the pch-test tests pass for C and Objective-C.
llvm-svn: 70163
necessary and iterate until all types and declarations have been
written. This reduces the Cocoa.h PCH file size by about 4% (since we
don't write types we don't need), and fixes problems where writing a
declaration generates a new type.
This doesn't seem to have any impact on performance either way.
llvm-svn: 70109
most of which are ignored. Instead, move the __COUNTER__ value out to
a PCH-level record (since it is handled eagerly) and move the header
file information into the SourceManager block (which is also,
currently, loaded eagerly).
This results in another 17% performance improvement in the
Cocoa-prefixed "Hello, World" with PCH.
llvm-svn: 70097
PCH file. In the Cocoa-prefixed "Hello, World" benchmark, this takes
us from reading 503 identifiers down to 37 and from 470 macros down to
4. It also results in an 8% performance improvement.
llvm-svn: 70094
identifier's ID. In this case, we know where the identifier's entry is
located in the hash table (it starts right before the identifier
string itself), so skip the hash table lookup and read the entry
directly. The performance improvement here is, gain, hard to quantify,
but it's the right thing to do.
llvm-svn: 70078
"interesting" identifiers (e.g., those where the IdentifierInfo has
some useful information) from "uninteresting" identifiers (where the
IdentifierInfo is just a name). This makes the hash table smaller (so
searching in it should be faster) and, when loading "uninteresting"
identifiers, we skip the lookup in the hash table.
PCH file size is slightly smaller than before (since we don't emit the
contents of the uninteresting IdentifierInfo structures). The
Cocoa.h-prefixed "Hello, World" doesn't show any speedup, although
we're getting to the point where system noise is a bit issue.
llvm-svn: 70075
allocating IdentifierInfos with a pointer into the string data stored
in the PCH file rather than having an entry in the identifier table's
string map. However, we don't actually get these savings at the
moment, because we go through the IdentifierTable when loading
identifiers from the on-disk hash table.
This commit is for record-keeping purposes only. I'll be reverting
this change (and the PCH layout tweak that preceded it) because it
appears that implementing this optimization will collide with another,
future optimization to reduce the size of the on-disk hash table for
identifiers. That optimization is likely to provide more benefit (with
less voodoo).
llvm-svn: 70070
that the PCH reader does not have to decode the VBR encoding at PCH
load time.
Also, reduce the size of the identifier offsets from 64 bits down to
32 bits. The identifier table itself isn't going to grow to more than
4GB :)
Overall, this results in a 13% speedup in the Cocoa-prefixed "Hello,
World" benchmark.
llvm-svn: 70063
blobs, so that we don't need to do any work to get these arrays into
memory at PCH load time.
This gives another 19% performance improvement to the Cocoa-prefixed
"Hello, World!".
llvm-svn: 70059
This results in a 10% speedup on the Cocoa-prefixed "Hello, World!",
all of which is (not surprisingly) user time. There was a tiny
reduction in the size of the PCH file for Cocoa.h, because certain
selectors aren't being written twice.
I'm using two new tricks here that I'd like to replicate elsewhere:
(1) The selectors not used in the global method pool are packed into
the blob after the global method pool's on-disk hash table and
stored as keys, so that all selectors are in the same blob.
(2) We record the offsets of each selector key when we write it into
the global method pool (or after it, in the same blob). The offset
table is written as a blob, so that we don't need to pack/unpack a
SmallVector with its contents.
llvm-svn: 70055
to the checker yet, but essentially it allows a user to specify that an
Objective-C method or C function increments the reference count of a passed
object.
llvm-svn: 70005
up to the checker yet, but essentially it allows a user to specify that an
Objective-C method or C function returns an owned an Objective-C object.
llvm-svn: 70001
(1) Make sure to pad on-disk hash tables with 4 bytes, not 2, since
the reader assumes that bucket data is aligned on 4-byte
boundaries.
(2) Don't emit the number of factory methods twice. This was
throwing off the data counts and therefore causing lookups to
fail. I've added asserts so that this class of error cannot happen
again.
llvm-svn: 69991
pools, combined). The methods in the global method pool are lazily
loaded from an on-disk hash table when Sema looks into its version of
the hash tables.
llvm-svn: 69989
As part of this, make ObjCImplDecl inherit from NamedDecl (since
ObjCImplementationDecls now need to have names so that they can be
found). This brings ObjCImplDecl very, very close to
ObjCContainerDecl; we may be able to merge them soon.
llvm-svn: 69941
their own namespace (IDNS_Protocol) and use the normal name-lookup
routines to find them. Aside from the simplification this provides
(one less DenseMap!), it means that protocols will be lazily
deserialized from PCH files.
Make the code size of the selector table block match the code size of
the type and decl blocks.
llvm-svn: 69939
SEL, Class, Protocol, CFConstantString, and
__objcFastEnumerationState. With this, we can now run the Objective-C
methods and properties PCH tests.
llvm-svn: 69932
This enables class recognition to work with PCH. I believe this means we can remove Sema::ObjCInterfaceDecls and it's usage within Sema::LookupName(). Will investigate.
llvm-svn: 69891
file needs to store. CodeGen needs to see these definitions (via
HandleTopLevelDecl), otherwise it won't be able to generate code for
them.
This patch notifies the consumer (e.g., CodeGen) about function
definitions and variable definitions when the corresponding
declarations are deserialized. Hence, we don't eagerly deserialize the
declarations for every variable or function that has a definition in
the PCH file. This gives another 5% speedup for the Carbon-prefixed
"Hello, World!", and brings our PCH statistics down to something far
more reasonable:
*** PCH Statistics:
13/20693 types read (0.062823%)
17/59230 declarations read (0.028702%)
54/44914 identifiers read (0.120230%)
0/32954 statements read (0.000000%)
5/6187 macros read (0.080815%)
llvm-svn: 69820
PCH files now contain complete information about builtins, including
any declarations that have been synthesized as part of building the
PCH file. When using a PCH file, we do not initialize builtins at all;
when needed, they'll be found in the PCH file.
This optimization translations into a 9% speedup for "Hello, World!"
with Carbon.h as a prefix header and roughly a 5% speedup for 403.gcc
with its prefix header. We're also reading less of the PCH file for
"Hello, World!":
*** PCH Statistics:
286/20693 types read (1.382110%)
1630/59230 declarations read (2.751984%)
764/44914 identifiers read (1.701029%)
1/32954 statements read (0.003035%)
5/6187 macros read (0.080815%)
down from
*** PCH Statistics:
411/20693 types read (1.986179%)
2553/59230 declarations read (4.310316%)
1093/44646 identifiers read (2.448148%)
1/32954 statements read (0.003035%)
21/6187 macros read (0.339421%)
llvm-svn: 69815
- If we don't find a file looking relative to the current working
directory, fall back to header search. This is closer to what would
happen if the lookup was starting from right directory in the first
place (except it will find files in the directory of the main
source file, which I *think* should not be found).
- PR3992.
llvm-svn: 69794
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
This optimization improves performance on the Carbon-prefixed "Hello,
World!" example by 57%. For reference, we're now about 2.25x faster
than GCC PCH. We're also pulling in far less of the PCH file:
*** PCH Statistics:
411/20693 types read (1.986179%)
2553/59230 declarations read (4.310316%)
1093/44646 identifiers read (2.448148%)
1/32954 statements read (0.003035%)
21/6187 macros read (0.339421%)
llvm-svn: 69755
identifiers from a precompiled header.
This patch changes the primary name lookup method for entities within
a precompiled header. Previously, we would load all of the names of
declarations at translation unit scope into a large DenseMap (inside
the TranslationUnitDecl's DeclContext), and then perform a special
"last resort" lookup into this DeclContext when we knew there was a
PCH file (see Sema::LookupName). Now, when we see an identifier named
for the first time, we load all of the declarations with that name
that are visible from the translation unit into the IdentifierInfo's
chain of declarations. Thus, the explicit "look into the translation
unit's DeclContext" code is gone, and Sema effectively uses the same
IdentifierInfo-based name lookup mechanism whether we are using a PCH
file or not.
This approach should help PCH scale with the size of the input program
rather than the size of the PCH file. The "Hello, World!" application
with Carbon.h as a PCH file now loads 20% of the identifiers in the
PCH file rather than 85% of the identifiers.
90% of the 20% of identifiers loaded are actually loaded when we
deserialize the preprocessor state. The next step is to make the
preprocessor load macros lazily, which should drastically reduce the
number of types, declarations, and identifiers loaded for "Hello,
World".
llvm-svn: 69737
that also includes the contents of the IdentifierInfo itself (the
various fields and flags, along with the chain of identifiers visible
at the top level that have that name).
We don't make any use of the hash table yet, except that our
identifier ID -> string mapping points into the hash table now.
llvm-svn: 69625
also gets access to the Sema object performing semantic analysis. This
will be used by the PCH writer to serialize Sema state.
No functionality change.
llvm-svn: 69595
AST context's __builtin_va_list type will be set when the PCH file is
loaded. This fixes the crash when CodeGen'ing a va_arg expression
pulled in from a PCH file.
llvm-svn: 69421
"Hello, World!", this takes us from deserializing 6469
statements/expressions down to deserializing 1
statement/expression. It only translated into a 1% improvement on the
Carbon-prefixed 403.gcc, but (a) it's the right thing to do, and (b)
we expect this to matter more once we lazily deserialize identifiers.
llvm-svn: 69407
lazy PCH deserialization. Propagate that argument wherever it needs to
be. No functionality change, except that I've tightened up a few PCH
tests in preparation.
llvm-svn: 69406
kind PCH handles that has an expression as an operand, so most of this
work is in the infrastructure to rebuild expression trees from the
serialized representation. We now store expressions in post-order
(e.g., Reverse Polish Notation), so that we can easily rebuild the
appropriate expression tree.
llvm-svn: 69101
This allows it to accurately measure tokens, so that we get:
t.cpp:8:13: error: unknown type name 'X'
static foo::X P;
~~~~~^
instead of the woefully inferior:
t.cpp:8:13: error: unknown type name 'X'
static foo::X P;
~~~~ ^
Most of this is just plumbing to push the reference around.
llvm-svn: 69099
non-inline external definitions (and tentative definitions) that are
found at the top level. The corresponding declarations are stored in a
record in the PCH file, so that they can be provided to the
ASTConsumer (via HandleTopLevelDecl) when the PCH file is read.
llvm-svn: 69005
the unlikely event that the filename IDs in the stored line table end
up being different from the filename IDs in the newly-created line
table.
llvm-svn: 68965
buffer generated for the current translation unit. If they are
different, complain and then ignore the PCH file. This effectively
checks for all compilation options that somehow would affect
preprocessor state (-D, -U, -include, the dreaded -imacros, etc.).
When we do accept the PCH file, throw away the contents of the
predefines buffer rather than parsing them, since all of the results
of that parsing are already stored in the PCH file. This eliminates
the ugliness with the redefinition of __builtin_va_list, among other
things.
llvm-svn: 68838
PCH. This works now, except for limitations not being able to do things
with identifiers. The basic example in the testcase works though.
llvm-svn: 68832
fixme's, e.g. for tokens with identifiers) but does not actually install
them. Some details with the predefines buffer needs to be sorted out first.
llvm-svn: 68828
file. When de-serializing LangOptions, we check that the
currently-provided language options are consistent with the options
used to compile the PCH file. If they are not, we emit a diagnostic
and ignore the PCH file.
llvm-svn: 68820
improvement, source locations read from the PCH file will properly
resolve to the source files that were used to build the PCH file
itself.
Once we have the preprocessor state stored in the PCH file, source
locations that refer to macro instantiations that occur in the PCH
file should have the appropriate instantiation information.
llvm-svn: 68758
de-serialization of abstract syntax trees.
PCH support serializes the contents of the abstract syntax tree (AST)
to a bitstream. When the PCH file is read, declarations are serialized
as-needed. For example, a declaration of a variable "x" will be
deserialized only when its VarDecl can be found by a client, e.g.,
based on name lookup for "x" or traversing the entire contents of the
owner of "x".
This commit provides the framework for serialization and (lazy)
deserialization, along with support for variable and typedef
declarations (along with several kinds of types). More
declarations/types, along with important auxiliary structures (source
manager, preprocessor, etc.), will follow.
llvm-svn: 68732
can use a PathLocation after any reference Stmts are reclaimed,
flattenLocation() converts those references to statements to source ranges.
llvm-svn: 68292
instead of a FullSourceLoc. This resulted in a bunch of small edits in various
clients.
- Updated BugReporter to include an alternate PathDiagnostic generation
algorithm for PathDiagnosticClients desiring more control-flow pieces.
llvm-svn: 68193
- Added an internal helper class 'PathDiagnosticBuilder' which now bundles the
'ExecutionContinues' methods.
- Added preliminary diagnostics for short-circuit '&&' and '||'
llvm-svn: 67822
diagnostics. This builds on the patch that Sebastian committed and
then revert. Major differences are:
- We don't remove or use the current ".def" files. Instead, for now,
we just make sure that we're building the ".inc" files.
- Fixed CMake makefiles to run TableGen and build the ".inc" files
when needed. Tested with both the Xcode and Makefile generators
provided by CMake, so it should be solid.
- Fixed normal makefiles to handle out-of-source builds that involve
the ".inc" files.
I'll send a separate patch to the list with Sebastian's changes that
eliminate the use of the .def files.
llvm-svn: 67058
defaults to off. When enabled, it emits range info along
with the file/line/col information for a diagnostic. This
allows tools that textually parse the output of clang to know
where the ranges are, even if they span multiple lines. For
example, with:
$ clang exprs.c -fprint-source-range-info
We now produce:
exprs.c:21:11:{21:12-21:13}: warning: use of unary operator that may be intended as compound assignment (+=)
var =+ 5; // expected-warning {{use of unary operator that may be intended as compound assignment (+=)}}
^~
exprs.c:22:11:{22:12-22:13}: warning: use of unary operator that may be intended as compound assignment (-=)
var =- 5; // expected-warning {{use of unary operator that may be intended as compound assignment (-=)}}
^~
exprs.c:36:13:{36:3-36:12}: error: assignment to cast is illegal, lvalue casts are not supported
(float*)X = P; // expected-error {{assignment to cast is illegal, lvalue casts are not supported}}
~~~~~~~~~ ^
exprs.c:41:4:{41:3-41:4}: error: called object type 'int' is not a function or function pointer
X(); // expected-error {{called object type 'int' is not a function or function pointer}}
~^
exprs.c:45:15:{45:8-45:14}{45:17-45:24}: error: invalid operands to binary expression ('int *' and '_Complex float')
P = (P-42) + Gamma*4; // expected-error {{invalid operands to binary expression ('int *' and '_Complex float')}}
~~~~~~ ^ ~~~~~~~
exprs.c:61:7:{61:16-61:22}: error: invalid application of '__alignof' to bitfield
R = __alignof(P->x); // expected-error {{invalid application of '__alignof' to bitfield}} expected-warning {{extension used}}
^ ~~~~~~
Note the range info after the column in the initial diagnostic.
This is obviously really annoying if you're not a tool parsing the
output of clang, which is why it is off by default.
llvm-svn: 66862
- PathDiagnosticControlFlowPiece now consists of a "start" and "end" location
to indicating the branch location and where the branch goes.
BugReporter:
- Updated BugReporter to construct PathDiagnosticControlFlowPiece objects with
"end" locations.
PlistDiagnostics:
- Plists now contain the bug "type" (not just bug "category")
- Plists now encode control-flow pieces differently than events; now the
"start" and "end" locations are recorded
llvm-svn: 66818
context of a template-id for which we need to instantiate default
template arguments.
In the TextDiagnosticPrinter, don't suppress the caret diagnostic if
we are producing a non-note diagnostic that follows a note diagnostic
with the same location, because notes are (conceptually) a part of the
warning or error that comes before them.
llvm-svn: 66572
- Group control flow and event PathDiagnosticPieces into PathDiagnosticMacroPieces.
- Afterwards, eliminate any PathDiagnosticMacroPieces from a PathDiagnostic that
contain no informative events.
HTMLDiagnostics:
- Use new information about PathDiagnosticMacroPieces to specially format
message bubbles for macro expansions containing interesting events.
llvm-svn: 66524
end of line instead of just the end of buffer. Scratch buffers contain
embedded \0's between tokens which are logic line separators. If a
normal text buffer contains \0's, it doesn't make a lot of sense to include
them in the caret diag output anyway.
llvm-svn: 66374
Eli Friedman