to handle non-caret diagnostics as well in order to be fully useful in
libclang etc. Also sketch out some more of my plans on this refactoring.
llvm-svn: 140476
tracking the start and stop of macro expansion suppression. Also remove
the Columns variable which was just a convenience variable based on
DiagOpts. Instead we materialize it in the one piece of code that cared.
llvm-svn: 140475
TextDiagnosticPrinter into the CaretDiagnostic class. Several
interesting results from this:
- This removes a significant per-diagnostic bit of state from the
CaretDiagnostic class, which should eventually allow us to re-use the
object.
- It removes a redundant recursive walk of the macro expansion stack
just to compute the depth. We don't need the depth until we're
unwinding anyways, so we can just mark when we reach it.
- It also paves the way for several simplifications we can do to how we
implement the suppression.
llvm-svn: 140474
This moves the existing code for CPATH into the driver and adds the environment lookup and path splitting there.
The paths are then passed down to cc1 with -I options (CPATH), added after the normal user-specified include dirs.
Language specific paths are passed via -LANG-isystem and the actual filtering is performed in the frontend.
I tried to match GCC's behavior as close as possible
Fixes PR8971.
llvm-svn: 140341
OpenCL is different from AltiVec in the way it supports vector literals. OpenCL
is strict with regards to semantic checks. For example, implicit conversions
and explicit casts between vectors of different types are disallowed.
Fixes PR10975. Submitted by: Anton Lokhmotov <Anton.lokhmotov@gmail.com>
llvm-svn: 140270
PreprocessingRecord's getPreprocessedEntitiesInRange.
Also remove all the stuff that were added in ASTUnit that are unnecessary now
that we do a binary search for preprocessed entities and deserialize only
what is necessary.
llvm-svn: 140063
check whether the requested location points inside the precompiled preamble,
in which case the returned source location will be a "loaded" one.
llvm-svn: 140060
Microsoft specific tweaking will now fall into 2 categories:
- fms-extension: Microsoft specific extensions that should never change the meaning of an otherwise well formed code. Currently map to LangOptions::Microsoft. (To be clearer, I am planning to change the name to LangOptions::MicrosoftExt).
- fms-compatibility: Really a MSVC emulation mode. Map to LangOptions::MicrosoftMode. Can change the meaning of an otherwise standard conformant program.
llvm-svn: 139978
-Use an array of offsets for all preprocessed entities
-Get rid of the separate array of offsets for just macro definitions;
for references to macro definitions use an index inside the preprocessed
entities array.
-Deserialize each preprocessed entity lazily, at first request; not in bulk.
Paves the way for binary searching of preprocessed entities that will offer
efficiency and will simplify things on the libclang side a lot.
llvm-svn: 139809
target triple to separate modules built under different
conditions. The hash is used to create a subdirectory in the module
cache path where other invocations of the compiler (with the same
version, language options, etc.) can find the precompiled modules.
llvm-svn: 139662
language options. Use that .def file to declare the LangOptions class
and initialize all of its members, eliminating a source of annoying
initialization bugs.
AST serialization changes are next up.
llvm-svn: 139605
already provided. This required a little bit of clean-up in the way
that VerifyDiagnosticsClient managed ownership of its underlying
"primary" client, because now it will no longer always take ownership.
llvm-svn: 139570
but there is a corresponding umbrella header in a framework, build the
module on-the-fly so it can be immediately loaded at the import
statement. This is very much proof-of-concept code, with details to be
fleshed out over time.
llvm-svn: 139558
where the compiler will look for module files. Eliminates the
egregious hack where we looked into the header search paths for
modules.
llvm-svn: 139538
modifying directly for the preamble.
This avoids an awful, hard to find, bug where "PreprocessorOpts.DisablePCHValidation = true"
would be persistent for subsequent reparses of the translation unit which would result
in defines, present in command-line but not in the PCH, being ignored.
Fixes rdar://9615399.
llvm-svn: 139512
feature akin to the ARC runtime checks. Removes a terrible hack where
IR gen needed to find the declarations of those symbols in the translation
unit.
llvm-svn: 139404
function. This is really the beginning of the second phase of
refactorings here. The end goal is to have (roughly) three interfaces:
1) Base class to format a single diagnostic suitable for display on the
console.
2) Extension of the base class which also displays a caret diagnostic
suitable for display on the console.
3) An adaptor that implements the DiagnosticClient by delegating to #1
and/or #2 as appropriate.
Once we have these, things like libclang's formatDiagnostic can use #1
and #2 to provide really well formatted (and consistently formatted!)
textual formatting of diagnostics.
Getting there is going to be quite a bit of shuffling. I'm basically
sketching out where the interface boundaries can be drawn for #1 and #2
within the existing classes. That lets me shuffle with a minimum of fuss
and delta. Once that's done, and any of the related interfaces that need
to change are updated, I'll hoist these into separate headers and
re-implement libclang in terms of their interfaces. Long WIP, but
comments at each step welcome. =D
llvm-svn: 139228
a stack array of a magical size with an assert() that we never
overflowed it. That seems incredibly risky. We also have a very nice API
for bundling up a vector we expect to usually have a small size without
loss of functionality or security if the size is excessive.
The fallout is to remove the last pointer+size parameter pair that are
traced through the recursive caret diagnostic emission.
llvm-svn: 139217
a defined interface. This isn't as nice as the previous one, but should
get better as I push through better data types in all these functions.
Also, I'm hoping to pull some aspects of this out into a common routine
(such as tab expansion).
Again, WIP, comments welcome as I'm going through.
llvm-svn: 139190
The function was only counting lines that included tokens and not empty lines,
but MaxLines (mainly initiated to the line where the code-completion point resides)
is a count of overall lines (even empty ones).
llvm-svn: 139085
Chandler Carruth