SourceManager's getBuffer() (and similar) operations. This abstract
can be used to force callers to cope with errors in getBuffer(), such
as missing files and changed files. Fix a bunch of callers to use the
new interface.
Add some very basic checks for file consistency (file size,
modification time) into ContentCache::getBuffer(), although these
checks don't help much until we've updated the main callers (e.g.,
SourceManager::getSpelling()).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@98585 91177308-0d34-0410-b5e6-96231b3b80d8
(even if it is defined). This fixes the issue of this function
returning '0' when SVN_VERSION is defined to be "".
Fixes: <rdar://problem/7663667>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@97620 91177308-0d34-0410-b5e6-96231b3b80d8
end-of-line source location when given a column number beyond the
length of the line, or an end-of-file source location when given a
line number beyond the length of the file. Previously, we would return
an invalid location.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@97299 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@96592 91177308-0d34-0410-b5e6-96231b3b80d8
every time they are called:
getClangRevision()
getClangFullRepositoryVersion()
getClangFullVersion()
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@96033 91177308-0d34-0410-b5e6-96231b3b80d8
we'd add an offset from the spelling location space to the
instantiation location, which doesn't make sense and would
lead up to the text diagnostics crashing when presented with
non-sensical locations.
This fixes rdar://7597492, a crash on 255.vortex.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@96004 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@95870 91177308-0d34-0410-b5e6-96231b3b80d8
by setting the section of the generated global. This is an
optimization done by the code generator, and the code being
removed didn't handle the case when the string contained an
embedded nul (which the code generator does correctly
handle). This is rdar://7589850
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@95003 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94740 91177308-0d34-0410-b5e6-96231b3b80d8
have it return a StringRef instead of an integer (to be more VCS
agnostic).
(2) Add getClangFullRepositoryVersion(), which contains an
amalgamation of the repository name and the revision.
(3) Change PCH to only emit the string returned by
getClangFullRepositoryVersion() instead of also emitting the value
of getClangSubversionRevision() (which has been removed). This is
functionally equivalent.
More cleanup to version string generation pending...
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94231 91177308-0d34-0410-b5e6-96231b3b80d8
characters to be escaped and implement a scan-forward function which
properly respects brace nesting.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@93447 91177308-0d34-0410-b5e6-96231b3b80d8
English right now; would not be impossible to grab a special format string
from the diagnostic pool and localize that way.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@93390 91177308-0d34-0410-b5e6-96231b3b80d8
- Correctly is in quotes, because we are following what I interpreted as GCC's
intent (which diverges from practice, naturally).
- Also, fix the arch define for arm1136jf-s.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91855 91177308-0d34-0410-b5e6-96231b3b80d8
- In particular, it can claim features for itself instead of always passing them on to LLVM.
- This allows using the target features as a generic mechanism for passing target specific options to the TargetInfo instance, which may need them for initializing preprocessor defines, etc.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91753 91177308-0d34-0410-b5e6-96231b3b80d8
- This should be done leveraging the backend, but I'm a little refactored
out. I'll fix it one day, I promise.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91700 91177308-0d34-0410-b5e6-96231b3b80d8
inconsistent situations if we do, and they are not important for PCH performance
(which currently only needs the stats to construct the initial FileManager
entries).
- No test case, sorry, the machinations are too involved.
This occurs when, for example, the build makes a PCH file and has a header map
or a -I for a directory that does not yet exist. It is possible we will cache
the negative stat on that directory, and then in the build we will never find
header files inside that dir.
For PCH we don't need these stats anyway for performance, so this also makes PCH
files smaller w/ no loss. I hope to eventually eliminate the stat cache
entirely.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91082 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@90699 91177308-0d34-0410-b5e6-96231b3b80d8
Simply use the 'LangOpts' member already present in TextDiagnosticPrinter.
Sorry for the confusion!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@90664 91177308-0d34-0410-b5e6-96231b3b80d8
file. This is accomplished by introducing the notion of a "virtual"
file into the file manager, which provides a FileEntry* for a named
file whose size and modification time are known but which may not
exist on disk.
Added a cute little test that remaps both a .c file and a .h file it
includes to alternative files.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@90329 91177308-0d34-0410-b5e6-96231b3b80d8
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>).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@90300 91177308-0d34-0410-b5e6-96231b3b80d8
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?
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@90280 91177308-0d34-0410-b5e6-96231b3b80d8
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"
^
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@90276 91177308-0d34-0410-b5e6-96231b3b80d8
- This ended up being hard to factor, sorry for the large diff.
- Some post-commit cleanup to come.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@88833 91177308-0d34-0410-b5e6-96231b3b80d8
into TargetInfo, just derive this based on the underlying type.
This prevents them from getting out of synch, patch by Ken Dyck!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86976 91177308-0d34-0410-b5e6-96231b3b80d8
Douglas Gregor
Kovarththanan Rajaratnam
Nuno Lopes
Ted Kremenek
Chris Lattner
Benjamin Kramer
Eric Christopher
Sanjiv Gupta
John McCall
Daniel Dunbar
John Thompson
Anders Carlsson
Anton Korobeynikov
Chandler Carruth
Fariborz Jahanian
Steve Naroff
Edward O'Callaghan