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
Douglas Gregor