| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
consistent.
Fixes a crash printing diagnostics on the gcc testsuite, and also makes
diagnostic range printing print nicer results for token pastes.
llvm-svn: 169068
|
|
|
|
| |
llvm-svn: 169030
|
|
|
|
|
|
| |
to pravic!
llvm-svn: 169028
|
|
|
|
|
|
|
|
|
|
|
|
| |
import of that module elsewhere, don't try to build the module again:
it won't work, and the experience is quite dreadful. We track this
information somewhat globally, shared among all of the related
CompilerInvocations used to build modules on-the-fly, so that a
particular Clang instance will only try to build a given module once.
Fixes <rdar://problem/12552849>.
llvm-svn: 168961
|
|
|
|
| |
llvm-svn: 168778
|
|
|
|
|
|
|
|
| |
string literal needs cleaning (because it contains line-splicing in the
encoding prefix or in the ud-suffix), do not clean the section between the
double-quotes -- that's the "raw" bit!
llvm-svn: 168776
|
|
|
|
| |
llvm-svn: 168274
|
|
|
|
|
|
|
| |
This makes LexCharConstant() look more like LexStringLiteral(), which doesn't
have this bug. Add tests for eof after \ for several other cases.
llvm-svn: 168269
|
|
|
|
|
|
|
| |
__has_attribute, __has_extension, making them behave more akin to
conventional macros.
llvm-svn: 168268
|
|
|
|
| |
llvm-svn: 168267
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
common LexStringLiteral function. In doing so, some consistency problems have
been ironed out (e.g. where the first token in the string literal was lexed
with macro expansion, but subsequent ones were not) and also an erroneous
diagnostic has been corrected.
LexStringLiteral is complemented by a FinishLexStringLiteral function which
can be used in the situation where the first token of the string literal has
already been lexed.
llvm-svn: 168266
|
|
|
|
| |
llvm-svn: 168265
|
|
|
|
| |
llvm-svn: 168077
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the related comma pasting extension.
In certain cases, we used to get two diagnostics for what is essentially one
extension. This change suppresses the first diagnostic in certain cases
where we know we're going to print the second diagnostic. The
diagnostic is redundant, and it can't be suppressed in the definition
of the macro because it points at the use of the macro, so we want to
avoid printing it if possible.
The implementation works by detecting constructs which look like comma
pasting at the time of the definition of the macro; this information
is then used when the macro is used. (We can't actually detect
whether we're using the comma pasting extension until the macro is
actually used, but we can detecting constructs which will be comma
pasting if the varargs argument is elided.)
<rdar://problem/12292192>
llvm-svn: 167907
|
|
|
|
|
|
| |
line endings. <rdar://problem/12639047>.
llvm-svn: 167900
|
|
|
|
|
|
| |
tokens at all,". This change broke External/Nurbs in LLVM test-suite.
llvm-svn: 167858
|
|
|
|
|
|
| |
FIXME in LexNumericConstant.
llvm-svn: 167818
|
|
|
|
|
|
|
|
|
| |
don't recursively continue lexing.
This avoids a stack overflow with a sequence of many empty #includes.
rdar://11988695
llvm-svn: 167801
|
|
|
|
| |
llvm-svn: 167800
|
|
|
|
| |
llvm-svn: 167690
|
|
|
|
|
|
|
|
|
|
| |
is empty in a variadic macro expansion. This fixes a divergence in support for
the ", ## __VA_ARGS__" GCC extension which differed in behaviour when in strict
C99 mode (note: there is no change in behaviour has been made in the gnu99 mode
that clang uses by default). In addition, there is improved support for the
Microsoft alternative extension ", __VA_ARGS__".
llvm-svn: 167613
|
|
|
|
|
|
|
|
|
| |
string parts.
Instead just use a dummy buffer, we're not going to use the decoded string anyways.
Fixes PR14292.
llvm-svn: 167594
|
|
|
|
| |
llvm-svn: 167593
|
|
|
|
| |
llvm-svn: 167483
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
allowing a module map to be placed one level above the '.framework'
directories to specify that all .frameworks within that directory can
be inferred as framework modules. One can also specifically exclude
frameworks known not to work.
This makes explicit (and more restricted) behavior modules have had
"forever", where *any* .framework was assumed to be able to be built
as a module. That's not necessarily true, so we white-list directories
(with exclusions) when those directories have been audited.
llvm-svn: 167482
|
|
|
|
|
|
| |
*Sanitizer to Sanitize* in preparation for later patches.
llvm-svn: 167405
|
|
|
|
|
|
|
|
| |
preserve the macro location of the range end if the filename came from a macro.
Patch by Kim Gräsman!
llvm-svn: 167239
|
|
|
|
| |
llvm-svn: 167059
|
|
|
|
|
|
|
| |
limit highlight to exactly the bad encoding, and highlight every
bad encoding in a string.
llvm-svn: 166900
|
|
|
|
|
|
| |
when computing the size of the precompiled preamble.
llvm-svn: 166659
|
|
|
|
| |
llvm-svn: 166599
|
|
|
|
|
|
| |
reference-counted, and hold a reference to it in HeaderSearch.
llvm-svn: 166583
|
|
|
|
| |
llvm-svn: 166571
|
|
|
|
|
|
|
| |
the various stakeholders bump up the reference count. In particular,
the diagnostics engine now keeps the DiagnosticOptions object alive.
llvm-svn: 166508
|
|
|
|
|
|
| |
expressions involving __has_include
llvm-svn: 166438
|
|
|
|
|
|
| |
created.
llvm-svn: 165943
|
|
|
|
|
|
|
|
| |
description. Previously, one could emulate this behavior by placing
the header in an always-unavailable submodule, but Argyrios guilted me
into expressing this idea properly.
llvm-svn: 165921
|
|
|
|
|
|
|
| |
or directories, to make sure that they are identifiers that are not
keywords in any dialect. Fixes <rdar://problem/12489495>.
llvm-svn: 165821
|
|
|
|
|
|
| |
#undef only occurs if that submodule is imported.
llvm-svn: 165773
|
|
|
|
|
|
|
| |
only with modules, when two disjoint modules #define the same
identifier to different token sequences.
llvm-svn: 165746
|
|
|
|
|
|
| |
associated with deserializing macro history for an identifier.
llvm-svn: 165729
|
|
|
|
| |
llvm-svn: 165683
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
macro history.
When deserializing macro history, we arrange history such that the
macros that have definitions (that haven't been #undef'd) and are
visible come at the beginning of the list, which is what the
preprocessor and other clients of Preprocessor::getMacroInfo()
expect. If additional macro definitions become visible later, they'll
be moved toward the front of the list. Note that it's possible to have
ambiguities, but we don't diagnose them yet.
There is a partially-implemented design decision here that, if a
particular identifier has been defined or #undef'd within the
translation unit, that definition (or #undef) hides any macro
definitions that come from imported modules. There's still a little
work to do to ensure that the right #undef'ing happens.
Additionally, we'll need to scope the update records for #undefs, so
they only kick in when the submodule containing that update record
becomes visible.
llvm-svn: 165682
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MacroInfo*. Instead of simply dumping an offset into the current file,
give each macro definition a proper ID with all of the standard
modules-remapping facilities. Additionally, when a macro is modified
in a subsequent AST file (e.g., #undef'ing a macro loaded from another
module or from a precompiled header), provide a macro update record
rather than rewriting the entire macro definition. This gives us
greater consistency with the way we handle declarations, and ties
together macro definitions much more cleanly.
Note that we're still not actually deserializing macro history (we
never were), but it's far easy to do properly now.
llvm-svn: 165560
|
|
|
|
|
|
| |
that are associated with a (sub)module.
llvm-svn: 165279
|
|
|
|
|
|
|
| |
loaded entities vector, otherwise its meaning will change when a module
is imported and the vector size changes.
llvm-svn: 165278
|
|
|
|
|
|
| |
resulted in an automatic module import.
llvm-svn: 165022
|
|
|
|
|
|
|
| |
use it to suggest appropriate macro for __attribute__((deprecated)) in
-Wdocumentation-deprecated-sync.
llvm-svn: 164892
|
|
|
|
|
|
|
| |
an inclusion directive was automatically turned into a module import, and
PPCallbacks::moduleImport() for an explicit module import.
llvm-svn: 164874
|
|
|
|
|
|
| |
is the same as the suggested one when looking up the include filename.
llvm-svn: 164872
|