| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 186547
|
| |
|
|
|
|
| |
Austin Seipp!
llvm-svn: 185896
|
| |
|
|
|
|
|
| |
with identifier info. This covers most identifier-like entities (other than
the ISO646 keywords).
llvm-svn: 185895
|
| |
|
|
| |
llvm-svn: 185715
|
| |
|
|
| |
llvm-svn: 185280
|
| |
|
|
| |
llvm-svn: 185164
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This allows clang to parse the type_traits header in Visual Studio 2012,
which is included widely in practice.
This is a rework of r163022 by João Matos. The original patch broke
preprocessing of gtest headers, which this patch addresses.
Patch by Will Wilson!
llvm-svn: 184968
|
| |
|
|
|
|
|
|
|
| |
a system module.
This prevents -pedantic from causing warnings in the system headers
used to create modules. Fixes <rdar://problem/14201171>.
llvm-svn: 184560
|
| |
|
|
|
|
|
| |
headers may be included from within the module, but not from outside
the module.
llvm-svn: 184471
|
| |
|
|
|
|
| |
succession. Fixes PR16363.
llvm-svn: 184240
|
| |
|
|
|
|
|
|
| |
and a '!defined(X)' if we find a broken header guard. This is suboptimal; we
should point the diagnostic at the 'X' token not the 'if' token, but it fixes
the crash.
llvm-svn: 184054
|
| |
|
|
|
|
|
|
| |
properly. This warning checks that the #ifndef and #define directives at
the beginning of a header refer to the same macro name. Includes a fix-it
hint to correct the header guard.
llvm-svn: 183867
|
| |
|
|
|
|
| |
I am about to move PathV2.h to Path.h.
llvm-svn: 183795
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When x is empty, x ## is suppressed, and when y gets expanded, the fact that it follows ## is not
available in the macro expansion result. The macro definition can be checked instead, the ## will
be available there regardless of what x expands to.
Fixes http://llvm.org/PR12767
Patch by Harald van Dijk!
llvm-svn: 182699
|
| |
|
|
| |
llvm-svn: 182675
|
| |
|
|
|
|
|
|
|
|
| |
instead of trying to continue in an invalid state.
Also don't let libclang create a PCH with such an error.
Fixes rdar://13953768
llvm-svn: 182629
|
| |
|
|
|
|
| |
module but isn't itself part of a module.
llvm-svn: 182263
|
| |
|
|
|
|
|
|
| |
function macro arguments.
This is a modified version of a patch by Manuel Klimek.
llvm-svn: 182055
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The most common (non-buggy) case are where such objects are used as
return expressions in bool-returning functions or as boolean function
arguments. In those cases I've used (& added if necessary) a named
function to provide the equivalent (or sometimes negative, depending on
convenient wording) test.
DiagnosticBuilder kept its implicit conversion operator owing to the
prevalent use of it in return statements.
One bug was found in ExprConstant.cpp involving a comparison of two
PointerUnions (PointerUnion did not previously have an operator==, so
instead both operands were converted to bool & then compared). A test
is included in test/SemaCXX/constant-expression-cxx1y.cpp for the fix
(adding operator== to PointerUnion in LLVM).
llvm-svn: 181869
|
| |
|
|
|
|
| |
completes the implementation of N3638.
llvm-svn: 181669
|
| |
|
|
|
|
| |
in system header directories.
llvm-svn: 181643
|
| |
|
|
| |
llvm-svn: 181583
|
| |
|
|
|
|
|
|
| |
This made sense in pre-module era, before merging of HeaderFileInfos was introduced.
Final part of rdar://13840148.
llvm-svn: 181490
|
| |
|
|
|
|
|
|
|
|
|
| |
HeaderFileInfo for headers not belonging to the module.
After r180934 we may initiate module map parsing for modules not related to the module what we are building,
make sure we ignore the header file info of headers from such modules.
First part of rdar://13840148
llvm-svn: 181489
|
| |
|
|
|
|
|
|
|
| |
provisional C++1y support.
Add __has_feature and __has_extension checks for C++1y features (based on the provisional names from
the C++ features study group), and update documentation to match.
llvm-svn: 181342
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
No functionality change. The existing tests for this pragma only verify
that we can preprocess it.
Reviewers: rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D751
llvm-svn: 181246
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 181114
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we would clone the current diagnostic consumer to produce
a new diagnostic consumer to use when building a module. The problem
here is that we end up losing diagnostics for important diagnostic
consumers, such as serialized diagnostics (where we'd end up with two
diagnostic consumers writing the same output file). With forwarding,
the diagnostics from all of the different modules being built get
forwarded to the one serialized-diagnostic consumer and are emitted in
a sane way.
Fixes <rdar://problem/13663996>.
llvm-svn: 181067
|
| |
|
|
|
|
|
|
| |
MacroArgs object that provides information about
the argument tokens for a function macro.
llvm-svn: 181065
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
headers, speculatively load module maps.
The "magical" builtin headers are the headers we provide as part of
the C standard library, which typically comes from /usr/include. We
essentially merge our headers into that location (due to cyclic
dependencies). This change makes sure that, when header search finds
one of our builtin headers, we figure out which module it actually
lives in. This case is fairly rare; one ends up having to include one
of the few built-in C headers we provide before including anything
from /usr/include to trigger it. Fixes <rdar://problem/13787184>.
llvm-svn: 180934
|
| |
|
|
|
|
| |
__has_feature(cxx_thread_local) true when the target supports thread-local storage.
llvm-svn: 180909
|
| |
|
|
|
|
|
|
|
| |
Deserialized MacroInfos were not destroyed and if their SmallVector did heap allocation,
it was leaked.
rdar://13768967
llvm-svn: 180771
|
| |
|
|
|
|
| |
rdar://13647445
llvm-svn: 179907
|
| |
|
|
|
|
| |
C++1y binary literals.
llvm-svn: 179883
|
| |
|
|
| |
llvm-svn: 179861
|
| |
|
|
|
|
|
|
|
|
|
| |
The system_header pragma (from GCC) is implemented using line notes in the
source manager. However, a line note's line number specifies the number
not for the current line, but for the next line. This was making all
line numbers appear off by one after the pragma.
Reported by Andy Gibbs, uncovered during r179677.
llvm-svn: 179709
|
| |
|
|
| |
llvm-svn: 179687
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements parsing ‘#pragma clang __debug’ as a first step for
implementing captured statements. Captured statements are a mechanism for
doing outlining in the AST.
see http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-January/027540.html.
Currently returns StmtEmpty
Author: Andy Zhang <andy.zhang@intel.com>
Differential Revision: http://llvm-reviews.chandlerc.com/D369
llvm-svn: 179614
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The GNU line marker directive was sharing code with the #line directive, but some of the warnings/errors were reporting as #line directive diagnostics in both cases.
Previously:
#line 11foo1 ==> "#line directive requires a simple digit sequence"
# 11foo1 ==> "#line directive requires a simple digit sequence"
Now, we get:
#line 11foo1 ==> "#line directive requires a simple digit sequence"
# 11foo1 ==> "GNU line marker directive requires a simple digit sequence"
llvm-svn: 179139
|
| |
|
|
|
|
| |
Don't bother looking for parameter index of 'B' token if 'A' is not a parameter.
llvm-svn: 178699
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
of only lexically.
Syntactically means the function macro parameter names do not need to use the same
identifiers in order for the definitions to be considered identical.
Syntactic equivalence is a microsoft extension for macro redefinitions and we'll also
use this kind of comparison to check for ambiguous macros coming from modules.
rdar://13562254
llvm-svn: 178671
|
| |
|
|
|
|
| |
It's not used anymore.
llvm-svn: 178106
|
| |
|
|
|
|
|
|
|
|
| |
Also update "test/Modules/macros.c" to test modified semantics:
-When there is an ambiguous macro, expand using the latest introduced version, not the first one.
-#undefs in submodules cause the macro to not be exported by that submodule, it doesn't cause
undefining of macros in the translation unit that imported that submodule.
This reduces macro namespace interference across modules.
llvm-svn: 178105
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MacroDirective's subclasses.
For each macro directive (define, undefine, visibility) have a separate object that gets chained
to the macro directive history. This has several benefits:
-No need to mutate a MacroDirective when there is a undefine/visibility directive. Stuff like
PPMutationListener become unnecessary.
-No need to keep extra source locations for the undef/visibility locations for the define directive object
(which is the majority of the directives)
-Much easier to hide/unhide a section in the macro directive history.
-Easier to track the effects of the directives across different submodules.
llvm-svn: 178037
|
| |
|
|
|
|
|
|
|
| |
-Serialize the macro directives history into its own section
-Get rid of the macro updates section
-When de/serializing an identifier from a module, associate only one macro per
submodule that defined+exported it.
llvm-svn: 177761
|
| |
|
|
|
|
| |
submodule ID.
llvm-svn: 177760
|
| |
|
|
|
|
| |
of their subdirectory in the include path.
llvm-svn: 177621
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Clarify what MacroInfo::isBuiltinMacro means, as it really means something
more like "isMagicalMacro" or "requiresProcessingBeforeExpansion" -- the
macros defined in "<built-in>" are not considered built-in by this function;
* Escape __LINE__ as \__LINE__ in Doxygen comments so that the underscores
don't get replaced by *bold* output;
* Turn comments in MacroInfo.cpp into non-Doxygen comments, so that they
don't result in duplicated/badly formatted Doxygen output;
* Clean up a bunch of \brief formatting, and add a \file comment for
MacroInfo.h.
llvm-svn: 177581
|
| |
|
|
|
|
| |
and warn when a newly-imported module conflicts with an already-imported module.
llvm-svn: 177577
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Configuration macros are macros that are intended to alter how a
module works, such that we need to build different module variants
for different values of these macros. A module can declare its
configuration macros, in which case we will complain if the definition
of a configation macro on the command line (or lack thereof) differs
from the current preprocessor state at the point where the module is
imported. This should eliminate some surprises when enabling modules,
because "#define CONFIG_MACRO ..." followed by "#include
<module/header.h>" would silently ignore the CONFIG_MACRO setting. At
least it will no longer be silent about it.
Configuration macros are eventually intended to help reduce the number
of module variants that need to be built. When the list of
configuration macros for a module is exhaustive, we only need to
consider the settings for those macros when building/finding the
module, which can help isolate modules for various project-specific -D
flags that should never affect how modules are build (but currently do).
llvm-svn: 177466
|