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>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173976 91177308-0d34-0410-b5e6-96231b3b80d8
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169237 91177308-0d34-0410-b5e6-96231b3b80d8
module, provide a module import stack similar to what we would get for
an include stack, e.g.,
In module 'DependsOnModule' imported from build-fail-notes.m:4:
In module 'Module' imported from DependsOnModule.framework/Headers/DependsOnModule.h:1:
Inputs/Module.framework/Headers/Module.h:15:12: note: previous definition is here
@interface Module
<rdar://problem/12696425>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169042 91177308-0d34-0410-b5e6-96231b3b80d8
building module 'Foo' imported from..." notes (the same we we provide
"In file included from..." notes) in the diagnostic, so that we know
how this module got included in the first place. This is part of
<rdar://problem/12696425>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169021 91177308-0d34-0410-b5e6-96231b3b80d8
caret locations and source ranges in macros. Makes ranges more accurate
in some cases, and fixes an assertion failure.
Fixes <rdar://problem/12472249>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167353 91177308-0d34-0410-b5e6-96231b3b80d8
the various stakeholders bump up the reference count. In particular,
the diagnostics engine now keeps the DiagnosticOptions object alive.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166508 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163820 91177308-0d34-0410-b5e6-96231b3b80d8
This time, make sure we don't try to print fixits with newline characters,
since they don't have a valid column width, and they don't look good anyway.
PR13417 (and originally <rdar://problem/11877454>)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160561 91177308-0d34-0410-b5e6-96231b3b80d8
This code is very sensitive to the difference between "columns" as printed
and "bytes" (SourceManager columns). All variables are now named explicitly
and our assumptions are (hopefully) documented as both comment and assertion.
Whether parseable fixits should use byte offsets or Unicode character counts
is pending discussion on the mailing list; currently the implementation uses
bytes (and has no problems on lines containing multibyte characters).
This has been added to the user manual.
<rdar://problem/11877454>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160319 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159216 91177308-0d34-0410-b5e6-96231b3b80d8
This occurs when you have two insertions and the first one is so long that the
second fixit's column is before the first fixit ends. The edits themselves
don't actually overlap, but our command-line preview does.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158229 91177308-0d34-0410-b5e6-96231b3b80d8
if the value isn't an unsigned char or EOF behavior is undefined
(and on Windows there's an assertion)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@157445 91177308-0d34-0410-b5e6-96231b3b80d8
http://llvm.org/bugs/show_bug.cgi?id=12924
This issue was that the source location was pointing to a
non-printable character and so CaretEnd was pointing one
_column_ past the caret but not one _character_ past the
caret. So the conversion between column and byte locations
wasn't working (because the conversion is only valid from
the first column or byte of a character).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@157372 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156536 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154980 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154946 91177308-0d34-0410-b5e6-96231b3b80d8
pulled into DiagnosticNoteRenderer, and common DiagnosticRenderer that
assumes that all custom diagnostic messages are notes. Also extend
DiagnosticRenderer to work with StoredDiagnostics in preparation for
subsequent changes.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150455 91177308-0d34-0410-b5e6-96231b3b80d8
(I was going to fix the TODO about DenseMap too, but
that would break self-host right now. See PR11922.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149799 91177308-0d34-0410-b5e6-96231b3b80d8
the policy of how diagnostics are lowered/rendered, while TextDiagnostic handles
the actual pretty-printing.
This is a first part of reworking SerializedDiagnosticPrinter to use the same
inclusion-stack/macro-expansion logic as TextDiagnostic.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146819 91177308-0d34-0410-b5e6-96231b3b80d8
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: ...".
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@142127 91177308-0d34-0410-b5e6-96231b3b80d8
NAKAMURA Takumi
Jordan Rose
Dmitri Gribenko
Douglas Gregor
Chandler Carruth
Benjamin Kramer
Seth Cantrell
Eli Friedman
Sylvestre Ledru
Richard Smith
Joerg Sonnenberger
Nico Weber
Richard Trieu
David Blaikie
James Dennett
Argyrios Kyrtzidis
Matt Beaumont-Gay
Ted Kremenek
Dylan Noblesmith