reparses an already-parsed translation unit. At the moment it's just a
convenience function, but we hope to use it for performance
optimizations.
llvm-svn: 108756
to use them instead of SourceRange. CharSourceRange is just a SourceRange
plus a bool that indicates whether the range has the end character resolved
or whether the end location is the start of the end token. While most of
the compiler wants to think of ranges that have ends that are the start of
the end token, the printf diagnostic stuff wants to highlight ranges within
tokens.
This is transparent to the diagnostic stuff. To start taking advantage of
the new capabilities, you can do something like this:
Diag(..) << CharSourceRange::getCharRange(Begin,End)
llvm-svn: 106338
than 127 groups so this was already failing given -fsigned-char. A subsequent
to commit to TableGen will generate shorts for the arrays themselves.
llvm-svn: 103703
print the diagnostic category number in the [] at the end
of the line. For example:
$ cat t.c
#include <stdio.h>
void foo() {
printf("%s", 4);
}
$ clang t.c -fsyntax-only -fdiagnostics-print-source-range-info
t.c:3:11:{3:10-3:12}{3:15-3:16}: warning: conversion specifies type 'char *' but the argument has type 'int' [-Wformat,1]
printf("%s", 4);
~^ ~
1 warning generated.
Clients that want category information can now pick the number
out of the output, rdar://7928231.
More coming.
llvm-svn: 103053
and diagnostic groups. This allows the compiler to group
diagnostics together (e.g. "Logic Warning",
"Format String Warning", etc) like the static analyzer does.
This is not exposed through anything in the compiler yet.
llvm-svn: 103051
we will print with each error that occurs during template
instantiation. When the backtrace is longer than that, we will print
N/2 of the innermost backtrace entries and N/2 of the outermost
backtrace entries, then skip the middle entries with a note such as:
note: suppressed 2 template instantiation contexts; use
-ftemplate-backtrace-limit=N to change the number of template
instantiation entries shown
This should eliminate some excessively long backtraces that aren't
providing any value.
llvm-svn: 101882
separate count of "suppressed" errors. This way, semantic analysis
bits that depend on the error count to determine whether problems
occured (e.g., some template argument deduction failures, jump-scope
checking) will not get confused.
The actual problem here is that a missing #include (which is a fatal
error) could cause the jump-scope checker to run on invalid code,
which it is not prepared to do. Trivial fix for both
<rdar://problem/7775941> and <rdar://problem/7775709>.
llvm-svn: 101297
actually turned it on. If a diag is produced by a warning which
is an extension but defaults to on, and has no warning group, don't
print any option info.
llvm-svn: 101071
of errors and warnings. This allows us to emit something like this:
2 warnings and 1 error generated.
instead of:
3 diagnostics generated.
This also stops counting 'notes' because they are just follow-on information
about the previous diag, not a diagnostic in themselves.
llvm-svn: 100675
cache of PartialDiagnostic::Storage objects into an allocator within
the ASTContext. This eliminates a significant amount of malloc
traffic, for a 10% performance improvement in -fsyntax-only wall-clock
time with 403.gcc's combine.c.
Also, eliminate the RequireNonAbstractType hack I put in earlier,
which was but a symptom of this larger problem.
Fixes <rdar://problem/7806091>.
llvm-svn: 99849
how to handle a diagnostic during template argument deduction, which
may be "substitution failure", "suppress", or "report". This keeps us
from, e.g., emitting warnings while performing template argument
deduction.
llvm-svn: 99560
Diagnostic subsystem, which is used in the rare case where we find a
serious problem (i.e., an inconsistency in the file system) while
we're busy formatting another diagnostic. In this case, the delayed
diagnostic will be emitted after we're done with the other
diagnostic. This is only to be used for fatal conditions detected at
very inconvenient times, where we can neither stop the current
diagnostic in flight nor can we suppress the second error.
llvm-svn: 99175
we attach diagnostics to translation units and code-completion
results, so they can be queried at any time.
To facilitate this, the new StoredDiagnostic class stores a diagnostic
in a serializable/deserializable form, and ASTUnit knows how to
capture diagnostics in this stored form. CIndex's CXDiagnostic is a
thin wrapper around StoredDiagnostic, providing a C interface to
stored or de-serialized diagnostics.
I've XFAIL'd one test case temporarily, because currently we end up
storing diagnostics in an ASTUnit that's never returned to the user
(because it contains errors). I'll introduce a temporary fix for this
soon; the real fix will be to allow us to return and query invalid ASTs.
llvm-svn: 96592
their spelling location. This prevents warnings from being swallowed just
because the caret is on the first parenthesis in, say, NULL.
This is an experiment; the risk is that there might be a substantial number
of system headers which #define symbols to expressions which inherently cause
warnings. My theory is that that's rare enough that it can be worked
around case-by-case, and that producing useful warnings around NULL is worth
it. But I'm willing to accept that I might be empirically wrong.
llvm-svn: 95870
so that CIndex can report diagnostics through the normal mechanisms
even when executing Clang in a separate process. This applies both
when performing code completion and when using ASTs as an intermediary
for clang_createTranslationUnitFromSourceFile().
The serialized format is not perfect at the moment, because it does
not encapsulate macro-instantiation information. Instead, it maps all
source locations back to the instantiation location. However, it does
maintain source-range and fix-it information. To get perfect fidelity
from the serialized format would require serializing a large chunk of
the source manager; at present, it isn't clear if this code will live
long enough for that to matter.
llvm-svn: 94740
http://llvm.org/viewvc/llvm-project?view=rev&revision=71086
Note - This commit only includes the fix for:
<rdar://problem/6309338> slightly different error message format for Visual Studio.
The fix for <rdar://problem/6845623> from protocol to template. is separate/forthcoming.
llvm-svn: 90642
pass them down into the ArgToStringFn implementation. This allows
redundancy across operands to a diagnostic to be eliminated.
This isn't used yet, so no functionality change.
llvm-svn: 84602
what we found when we looked into <blah>", where <blah> is a
DeclContext*. We can now format DeclContext*'s in nice ways, e.g.,
"namespace N", "the global namespace", "'class Foo'".
This is part of PR3990, but we're not quite there yet.
llvm-svn: 84028
essence, code completion is triggered by a magic "code completion"
token produced by the lexer [*], which the parser recognizes at
certain points in the grammar. The parser then calls into the Action
object with the appropriate CodeCompletionXXX action.
Sema implements the CodeCompletionXXX callbacks by performing minimal
translation, then forwarding them to a CodeCompletionConsumer
subclass, which uses the results of semantic analysis to provide
code-completion results. At present, only a single, "printing" code
completion consumer is available, for regression testing and
debugging. However, the design is meant to permit other
code-completion consumers.
This initial commit contains two code-completion actions: one for
member access, e.g., "x." or "p->", and one for
nested-name-specifiers, e.g., "std::". More code-completion actions
will follow, along with improved gathering of code-completion results
for the various contexts.
[*] In the current -code-completion-dump testing/debugging mode, the
file is truncated at the completion point and EOF is translated into
"code completion".
llvm-svn: 82166
qualified name does not actually refer into a class/class
template/class template partial specialization.
Improve printing of nested-name-specifiers to eliminate redudant
qualifiers. Also, make it possible to output a nested-name-specifier
through a DiagnosticBuilder, although there are relatively few places
that will use this leeway.
llvm-svn: 80056
Implement support for C++ Substitution Failure Is Not An Error
(SFINAE), which says that errors that occur during template argument
deduction do *not* produce diagnostics and do not necessarily make a
program ill-formed. Instead, template argument deduction silently
fails. This is currently implemented for template argument deduction
during matching of class template partial specializations, although
the mechanism will also apply to template argument deduction for
function templates. The scheme is simple:
- If we are in a template argument deduction context, any diagnostic
that is considered a SFINAE error (or warning) will be
suppressed. The error will be propagated up the call stack via the
normal means.
- By default, all warnings and errors are SFINAE errors. Add the
NoSFINAE class to a diagnostic in the .td file to make it a hard
error (e.g., for access-control violations).
Note that, to make this fully work, every place in Sema that emits an
error *and then immediately recovers* will need to check
Sema::isSFINAEContext() to determine whether it must immediately
return an error rather than recovering.
llvm-svn: 73332
them with -Werror. Custom diags cannot be mapped, and this makes
-Werror cause a determinstic crash for the checker and other
clients of the custom diagnostics machinery. rdar://6816191
llvm-svn: 70639
Douglas Gregor