| Age | Commit message (Collapse) | Author |
|---|
|
------------------------------------------------------------------------
r181342 | rsmith | 2013-05-07 12:32:56 -0700 (Tue, 07 May 2013) | 4 lines
C++1y: Update __cplusplus to temporary value 201305L to allow detection of 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.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_33@182340 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181246 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181114 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181067 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
MacroArgs object that provides information about
the argument tokens for a function macro.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181065 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180934 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
__has_feature(cxx_thread_local) true when the target supports thread-local storage.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180909 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Deserialized MacroInfos were not destroyed and if their SmallVector did heap allocation,
it was leaked.
rdar://13768967
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180771 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
rdar://13647445
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179907 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
C++1y binary literals.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179883 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179861 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179709 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179687 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179614 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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"
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179139 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Don't bother looking for parameter index of 'B' token if 'A' is not a parameter.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178699 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178671 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
It's not used anymore.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178106 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178105 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178037 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
-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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177761 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
submodule ID.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177760 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
of their subdirectory in the include path.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177621 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
* 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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177581 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
and warn when a newly-imported module conflicts with an already-imported module.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177577 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177466 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The previous implementation missed the case where the elif condition was
evaluated from the context of an #ifdef that was false causing PR15539.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177345 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
In a module-enabled Cocoa PCH file, we spend a lot of time stat'ing the headers
in order to associate the FileEntries with their modules and support implicit
module import.
Use a more lazy scheme by enhancing HeaderInfoTable to store extra info about
the module that a header belongs to, and associate it with its module only when
there is a request for loading the header info for a particular file.
Part of rdar://13391765
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176976 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This allows resolving top-header filenames of modules to FileEntries when
we need them, not eagerly.
Note that that this breaks ABI for libclang functions
clang_Module_getTopLevelHeader / clang_Module_getNumTopLevelHeaders
but this is fine because they are experimental and not widely used yet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176975 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176817 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
6.4.4.4/1 and 6.4.5/1.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176780 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
handle raw string literals here. C++11 doesn't yet specify how they will
behave, but discussion on core suggests that we should just strip off
everything but the r-char-sequence.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176779 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
continue parsing the directive rather than silently discarding it.
Allowing undef or redef of __TIME__ and __DATE__ is important to folks
who want stable, reproducible builds.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176540 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176535 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
It's beneficial when compiling to treat // as the start of a line
comment even in -std=c89 mode, since it's not valid C code (with a few
rare exceptions) and is usually intended as such. We emit a pedantic
warning and then continue on as if line comments were enabled.
This has been our behavior for quite some time.
However, people use the preprocessor for things besides C source files.
In today's prompting example, the input contains (unquoted) URLs, which
contain // but should still be preserved.
This change instructs the lexer to treat // as a plain token if Clang is
in C90 mode and generating preprocessed output rather than actually compiling.
<rdar://problem/13338743>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176526 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
available the
full information about the macro (e.g if it was imported and where).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175978 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
with more
arguments than it should accept.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175925 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
MacroDefinition object instead
its index in the preprocessed entities vector.
This is because the order of the entities in the vector can change in some (uncommon) cases.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175907 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
When parsing directives within skipped #if blocks, we don't want to retain
any whitespace. Previously we were just skipping comments, but it's not
possible to skip comments and retain other whitespace. This change matches
the usual behavior for parsing directives (i.e. the behavior outside of
skipped #if blocks).
<rdar://problem/13267695>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175840 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Note that unlike GNU cpp we currently do not preserve whitespace in macros
(even in -traditional-cpp mode).
<rdar://problem/12897179>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175778 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Post-commit CR feedback from Jordan Rose regarding r175594.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175679 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
MacroInfo class
for the data specific to a macro definition (e.g. what the tokens are), and
MacroDirective class which encapsulates the changes to the "macro namespace"
(e.g. the location where the macro name became active, the location where it was undefined, etc.)
(A MacroDirective always points to a MacroInfo object.)
Usually a macro definition (MacroInfo) is where a macro name becomes active (MacroDirective) but
splitting the concepts allows us to better model the effect of modules to the macro namespace
(also as a bonus it allows better modeling of push_macro/pop_macro #pragmas).
Modules can have their own macro history, separate from the local (current translation unit)
macro history; MacroDirectives will be used to model the macro history (changes to macro namespace).
For example, if "@import A;" imports macro FOO, there will be a new local MacroDirective created
to indicate that "FOO" became active at the import location. Module "A" itself will contain another
MacroDirective in its macro history (at the point of the definition of FOO) and both MacroDirectives
will point to the same MacroInfo object.
Introducing the separation of macro concepts is the first part towards better modeling of module macros.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175585 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175552 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
to make sure we don't crash on release if the index is not valid.
rdar://13089714
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175010 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
These are causing assertions on some MSVC builds.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174805 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Add warnings under -Wc++11-compat, -Wc++98-compat, and -Wc99-compat when a
particular UCN is incompatible with a different standard, and -Wunicode when
a UCN refers to a surrogate character in C++03.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174788 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Nearly all of these changes are one-to-one replacements; the few that
aren't have to do with custom identifier validation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174768 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
I threw in a couple of test cases for UD-suffixes -- already working, but
it wasn't immediately obvious to me.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174767 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Rewriting the same predicates over and over again is bad for code size and
code maintainence. Using the functions in <ctype.h> is generally unsafe
unless they are specified to be locale-independent (i.e. only isdigit and
isxdigit).
The next commit will try to clean up uses of <ctype.h> functions within Clang.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174765 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174683 91177308-0d34-0410-b5e6-96231b3b80d8
|
