| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
expansion, in which case it returns a file range in the location where the
argument was spelled.
llvm-svn: 148551
|
| |
|
|
|
|
| |
that the given source range encompasses.
llvm-svn: 148481
|
| |
|
|
|
|
| |
and returns a character range with file locations.
llvm-svn: 148480
|
| |
|
|
|
|
|
|
|
| |
start/end location.
It is commonly needed after calling the function; with this way we avoid
recalculating it.
llvm-svn: 148479
|
| |
|
|
|
|
| |
into Lexer and Preprocessor; making it widely available.
llvm-svn: 148410
|
| |
|
|
|
|
| |
never are
llvm-svn: 148391
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Updates ProcessUCNExcape() for C++. C++11 allows UCNs in character
and string literals that represent control characters and basic
source characters. Also C++03 allows UCNs that refer to surrogate
codepoints.
UTF-8 sequences in character literals are now handled as single
c-chars.
Added error for multiple characters in Unicode character literals.
Added errors for when a the execution charset encoding of a c-char
cannot be represented as a single code unit in the associated
character type. Note that for the purposes of this error the asso-
ciated character type for a narrow character literal is char, not
int, even though in C narrow character literals have type int.
llvm-svn: 148389
|
| |
|
|
|
|
| |
appropriate or when GCC requires it)
llvm-svn: 148292
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Add atomic-to/from-nonatomic cast types
- Emit atomic operations for arithmetic on atomic types
- Emit non-atomic stores for initialisation of atomic types, but atomic stores and loads for every other store / load
- Add a __atomic_init() intrinsic which does a non-atomic store to an _Atomic() type. This is needed for the corresponding C11 stdatomic.h function.
- Enables the relevant __has_feature() checks. The feature isn't 100% complete yet, but it's done enough that we want people testing it.
Still to do:
- Make the arithmetic operations on atomic types (e.g. Atomic(int) foo = 1; foo++;) use the correct LLVM intrinsic if one exists, not a loop with a cmpxchg.
- Add a signal fence builtin
- Properly set the fenv state in atomic operations on floating point values
- Correctly handle things like _Atomic(_Complex double) which are too large for an atomic cmpxchg on some platforms (this requires working out what 'correctly' means in this context)
- Fix the many remaining corner cases
llvm-svn: 148242
|
| |
|
|
|
|
|
|
|
|
| |
re-computed rather than the variables be re-used just after the assert.
Just use the variables since we have them already. Fixes an unused
variable warning.
Also fix an 80-column violation.
llvm-svn: 148212
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
framework is actually a subframework within a top-level framework. If
so, only infer a module for the top-level framework and then dig out
the appropriate submodule.
This helps us cope with an amusing subframeworks anti-pattern, where
one uses -F <framework>/Frameworks to get direct include access to the
subframeworks of a framework (which otherwise would not be
permitted).
llvm-svn: 148148
|
| |
|
|
| |
llvm-svn: 148117
|
| |
|
|
| |
llvm-svn: 148084
|
| |
|
|
|
|
|
| |
requirement to headers under PrivateHeaders. We don't want to build
them as part of the module (yet).
llvm-svn: 148082
|
| |
|
|
|
|
|
|
|
|
| |
include stack to find the first file that is known to be part of the
module. This copes with situations where the module map doesn't
completely specify all of the headers that are involved in the module,
which can come up when there are very strange #include_next chains
(e.g., with weird compiler/stdlib headers like stdarg.h or float.h).
llvm-svn: 147662
|
| |
|
|
| |
llvm-svn: 147635
|
| |
|
|
|
|
|
|
| |
the AST file,
as suggested by Tom Honermann.
llvm-svn: 147612
|
| |
|
|
|
|
| |
from a module file, don't bother parsing a new definition
llvm-svn: 147574
|
| |
|
|
|
|
|
|
| |
in the module map. This provides a bit more predictability for the
user, as well as eliminating the need to sort the submodules when
serializing them.
llvm-svn: 147564
|
| |
|
|
|
|
|
|
|
| |
any language variant), and restrict __has_feature(objc_modules) to
mean that we also have the Objective-C @import syntax. I anticipate
__has_feature(cxx_modules) and/or __has_feature(c_modules) for when we
nail down the module syntax for C/C++.
llvm-svn: 147548
|
| |
|
|
|
|
| |
or when modules are disabled.
llvm-svn: 147524
|
| |
|
|
| |
llvm-svn: 147482
|
| |
|
|
| |
llvm-svn: 147469
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
modules. This leaves us without an explicit syntax for importing
modules in C/C++, because such a syntax needs to be discussed
first. In Objective-C/Objective-C++, the @import syntax is used to
import modules.
Note that, under -fmodules, C/C++ programs can import modules via the
#include mechanism when a module map is in place for that header. This
allows us to work with modules in C/C++ without committing to a syntax.
llvm-svn: 147467
|
| |
|
|
|
|
|
| |
to make a macro public (the default for headers) or private,
respectively.
llvm-svn: 147455
|
| |
|
|
|
|
| |
@import identifier [. identifier]* ;
llvm-svn: 147452
|
| |
|
|
|
|
| |
"AutoModuleImport" preprocessor option and is tied to -fmodules.
llvm-svn: 147448
|
| |
|
|
| |
llvm-svn: 147433
|
| |
|
|
| |
llvm-svn: 147418
|
| |
|
|
|
|
|
|
|
| |
features needed for a particular module to be available. This allows
mixed-language modules, where certain headers only work under some
language variants (e.g., in C++, std.tuple might only be available in
C++11 mode).
llvm-svn: 147387
|
| |
|
|
|
|
|
|
| |
so this patch is surprisingly small.
Also drop -Wc1x-extensions in favor of -Wc11-extensions. I don't think we need to keep this around for compatibility.
llvm-svn: 147221
|
| |
|
|
| |
llvm-svn: 147208
|
| |
|
|
|
|
|
|
| |
found within that umbrella directory that were not actually included
by the umbrella header. They should either be referenced in the module
map or included by the umbrella header.
llvm-svn: 147207
|
| |
|
|
| |
llvm-svn: 147195
|
| |
|
|
|
|
|
|
|
|
| |
\<newline><newline>
don't consume the second newline.
Thanks to David Blaikie for pointing out the crash!
llvm-svn: 147138
|
| |
|
|
|
|
|
|
|
|
| |
the buffer
when the end of the buffer is immediately after an escaped newline.
Fixes http://llvm.org/PR10153.
llvm-svn: 147091
|
| |
|
|
| |
llvm-svn: 146967
|
| |
|
|
|
|
| |
http://llvm.org/docs/CodingStandards.html#ll_virtual_anch
llvm-svn: 146959
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
hitting a submodule that was never actually created, e.g., because
that header wasn't parsed. In such cases, complain (because the
module's umbrella headers don't cover everything) and fall back to
including the header.
Later, we'll add a warning at module-build time to catch all such
cases. However, this fallback is important to eliminate assertions in
the ASTWriter when this happens.
llvm-svn: 146933
|
| |
|
|
|
|
|
|
| |
macro expansion.
rdar://10588825
llvm-svn: 146818
|
| |
|
|
|
|
|
|
| |
#__include_macros) in the arguments of a function-style macro. Directives in the
arguments of such macros have undefined behaviour, and GCC does not correctly
support these cases. In some situations, this can lead to better diagnostics.
llvm-svn: 146765
|
| |
|
|
| |
llvm-svn: 146451
|
| |
|
|
|
|
|
| |
actually a terribly good heuristic, and the world is too horrible for
it to work.
llvm-svn: 146393
|
| |
|
|
|
|
|
| |
".framework/" in the path name, because it could be ".framework\" on
Windows. This whole function needs to be rewritten with PathV2.
llvm-svn: 146261
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
all of the headers below that particular directory. Use umbrella
directories as a clean way to deal with (1) directories/frameworks
that don't have an umbrella header, but don't want to enumerate all of
their headers, and (2) PrivateHeaders, which we never want to
enumerate and want to keep separate from the main umbrella header.
This also eliminates a little more of the "magic" for private headers,
and frameworks in general.
llvm-svn: 146235
|
| |
|
|
|
|
|
|
| |
part of HeaderSearch. This function just normalizes filenames for use
inside of a synthetic include directive, but it is used in both the
Frontend and Serialization libraries so it needs a common home.
llvm-svn: 146227
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
umbrella headers in the sense that all of the headers within that
directory (and eventually its subdirectories) are considered to be
part of the module with that umbrella directory. However, unlike
umbrella headers, which are expected to include all of the headers
within their subdirectories, Clang will automatically include all of
the headers it finds in the named subdirectory.
The intent here is to allow a module map to trivially turn a
subdirectory into a module, where the module's structure can mimic the
directory structure.
llvm-svn: 146165
|
| |
|
|
|
|
|
|
|
|
|
| |
a modifier for a header declarartion, e.g.,
umbrella header "headername"
Collapse the umbrella-handling code in the parser into the
header-handling code, so we don't duplicate the header-search logic.
llvm-svn: 146159
|
| |
|
|
|
|
|
|
|
|
| |
header to also support umbrella directories. The umbrella directory
for an umbrella header is the directory in which the umbrella header
resides.
No functionality change yet, but it's coming.
llvm-svn: 146158
|
| |
|
|
|
|
|
| |
that's currently being built. This is important for supporting
transitive dependencies ("export *" in the module map) completely.
llvm-svn: 146156
|