files.
- The issue is that PCH uses a stat cache, which may reference files which have
been deleted or moved. In such cases ContentCache::getBuffer was returning 0
but most clients are incapable of dealing with this (i.e., they don't).
For the time being, resolve this issue by just making up some invalid file
contents and. Eventually we should detect that we are in an inconsistent
situation and error out with a nice message that the PCH is out of date.
llvm-svn: 90699
files with the contents of an arbitrary memory buffer. Use this new
functionality to drastically clean up the way in which we handle file
truncation for code-completion: all of the truncation/completion logic
is now encapsulated in the preprocessor where it belongs
(<rdar://problem/7434737>).
llvm-svn: 90300
The later assumption is patently false, but this was already broken -- this situation is conceptually impossible, my feeling is we should fix SourceManager and friends to make it impossible in practice as well. However, we need to fix PR5662 and perhaps some other things involving memory buffers first. In the short term I'm pretty sure this is reliable.
Chris, Argiris, is this going to break anything that wasn't already broken?
llvm-svn: 90280
in diagnostics when we fail to open a file. This allows us to
report things like:
$ clang test.c -I.
test.c:2:10: fatal error: error opening file './foo.h': Permission denied
#include "foo.h"
^
llvm-svn: 90276
-code-completion-at=filename:line:column
which performs code completion at the specified location by truncating
the file at that position and enabling code completion. This approach
makes it possible to run multiple tests from a single test file, and
gives a more natural command-line interface.
llvm-svn: 82571
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
Now instead of just tracking the expansion history, also track the full
range of the macro that got replaced. For object-like macros, this doesn't
change anything. For _Pragma and function-like macros, this means we track
the locations of the ')'.
This is required for PR3579 because apparently GCC uses the line of the ')'
of a function-like macro as the location to expand __LINE__ to.
llvm-svn: 64601
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
location below it report as coming from the #line location. For example,
with:
#line 92 "foo.h"
#warning blarg!
#warning blarg!
we now emit:
foo.h:92:2: warning: #warning blarg!
#warning blarg!
^
foo.h:92:2: warning: #warning blarg!
#warning blarg!
^
llvm-svn: 63709
makes it clear to clients that they have to pick an instantiation
or spelling location before calling it and allows optimization based
on that.
llvm-svn: 63698
ContentCache objects to using a densemap and list, and allocating
the ContentCache objects from a bump pointer. This does not speed
up or slow down things substantially, but gives us control over
their alignment.
llvm-svn: 63628
as reported to the user and as manipulated by #line. This is what __FILE__,
__INCLUDE_LEVEL__, diagnostics and other things should follow (but not
dependency generation!).
This patch also includes several cleanups along the way:
- SourceLocation now has a dump method, and several other places
that did similar things now use it.
- I cleaned up some code in AnalysisConsumer, but it should probably be
simplified further now that NamedDecl is better.
- TextDiagnosticPrinter is now simplified and cleaned up a bit.
This patch is a prerequisite for #line, but does not actually provide
any #line functionality.
llvm-svn: 63098
address space we used up. Some interesting data:
For c99-intconst-1.c:
6912762 SLocEntry's allocated, 25592386B of Sloc address space used.
For cocoa.h:
26469 SLocEntry's allocated, 10278752B of Sloc address space used.
For carbon.h:
27364 SLocEntry's allocated, 12398141B of Sloc address space used.
Clearly 2G of sloc address space should be enough for anyone?!
llvm-svn: 63093
Daniel Dunbar