| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
| |
We would check if the terminator marker is on a newline. However, the
logic would end up out-of-bounds if the terminator marker immediately
follows the start marker.
This fixes PR21820.
llvm-svn: 224210
|
|
|
|
|
|
|
| |
#undef a keyword is generally harmless but used often in configuration scripts.
Also added tests that I forgot to include to commit in r223114.
llvm-svn: 224100
|
|
|
|
|
|
|
|
|
|
| |
objc_bridge(id).
This means that a pointer to the struct type to which the attribute appertains
is a CF type (and therefore an Objective-C object of some type), but not of any
specific class. rdar://19157264
llvm-svn: 224072
|
|
|
|
|
|
|
| |
components. These sometimes get synthetically added, and we don't want -Ifoo
and -I./foo to be treated fundamentally differently here.
llvm-svn: 224055
|
|
|
|
|
|
| |
Recommit of r223114, reverted in r223120.
llvm-svn: 224012
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Original commit message:
[modules] Add experimental -fmodule-map-file-home-is-cwd flag to -cc1.
For files named by -fmodule-map-file=, and files found by 'extern module'
directives, this flag specifies that we should resolve filenames relative to
the current working directory rather than relative to the directory in which
the module map file resides. This is aimed at fixing path handling, in
particular for relative -I paths, when building modules that represent
components of the current project (rather than libraries installed on the
current system, which the current project has as dependencies, where we'd
typically expect the module map files to be looked up implicitly).
llvm-svn: 223913
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
in debugger mode) to accept @import declarations
and pass them to the debugger.
In the preprocessor, accept import declarations
if the debugger is enabled, but don't actually
load the module, just pass the import path on to
the preprocessor callbacks.
In the Objective-C parser, if it sees an import
declaration in statement context (usual for LLDB),
ignore it and return a NullStmt.
llvm-svn: 223855
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r223753. It broke the Green Dragon build for a few
hours:
http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental_build/2259/
http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental_build/2259/consoleFull#43901905849ba4694-19c4-4d7e-bec5-911270d8a58c
I suspect `clang-tools-extra` just needs a follow-up for an API change,
but I'm not the right one to look into it.
llvm-svn: 223759
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For files named by -fmodule-map-file=, and files found by 'extern module'
directives, this flag specifies that we should resolve filenames relative to
the current working directory rather than relative to the directory in which
the module map file resides. This is aimed at fixing path handling, in
particular for relative -I paths, when building modules that represent
components of the current project (rather than libraries installed on the
current system, which the current project has as dependencies, where we'd
typically expect the module map files to be looked up implicitly).
llvm-svn: 223753
|
|
|
|
|
|
| |
diagnostics if they don't exist. Based on a patch by John Thompson!
llvm-svn: 223561
|
|
|
|
|
|
| |
map path more canonical before hashing it. No functionality change.
llvm-svn: 223547
|
|
|
|
|
|
| |
Removes the ability to look for generic attributes and keywords via this macro, which has the potential to be a breaking change. However, since there is __has_cpp_attribute and __has_declspec_attribute, and given the limited usefulness of querying a generic attribute name regardless of syntax, this seems like the correct path forward.
llvm-svn: 223468
|
|
|
|
|
|
| |
as a way to determine whether Clang supports a __declspec spelling for a given attribute, similar to __has_attribute and __has_cpp_attribute.
llvm-svn: 223467
|
|
|
|
|
|
|
| |
r142020 added support for has_feature(cxx_alignas). This does the same for
alignof.
llvm-svn: 223186
|
|
|
|
| |
llvm-svn: 223120
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change implements warnings if macro name is identical to a keyword or
reserved identifier. The warnings are different depending on the "danger"
of the operation. Defining macro that replaces a keyword is on by default.
Other cases produce warning that is off by default but can be turned on
using option -Wreserved-id-macro.
This change fixes PR11488.
Reviewers: rnk
Reviewed By: rnk
Subscribers: rnk, cfe-commits
Differential Revision: http://reviews.llvm.org/D6194
llvm-svn: 223114
|
|
|
|
| |
llvm-svn: 223105
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
rather than trying to extract this information from the FileEntry after the
fact.
This has a number of beneficial effects. For instance, diagnostic messages for
failed module builds give a path relative to the "module root" rather than an
absolute file path, and the contents of the module includes file is no longer
dependent on what files the including TU happened to inspect prior to
triggering the module build.
llvm-svn: 223095
|
|
|
|
|
|
|
| |
This suppresses the implicit search for files called 'module.modulemap' and
similar.
llvm-svn: 222745
|
|
|
|
| |
llvm-svn: 222317
|
|
|
|
| |
llvm-svn: 222306
|
|
|
|
| |
llvm-svn: 221998
|
|
|
|
|
|
| |
support for __has_cpp_attribute.
llvm-svn: 221991
|
|
|
|
| |
llvm-svn: 221576
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use the bitmask to store the set of enabled sanitizers instead of a
bitfield. On the negative side, it makes syntax for querying the
set of enabled sanitizers a bit more clunky. On the positive side, we
will be able to use SanitizerKind to eventually implement the
new semantics for -fsanitize-recover= flag, that would allow us
to make some sanitizers recoverable, and some non-recoverable.
No functionality change.
llvm-svn: 221558
|
|
|
|
|
|
|
|
|
|
|
|
| |
This DefaultIgnore warning under -Wincomplete-module was firing on
any module map files that happened to be parsed (it's only supposed to
fire on headers), and it has been superceded by
-Wnon-modular-include-in-module anyway.
For compatibility, I rewired -Wincomplete-module to imply
-Wnon-modular-include-in-module.
llvm-svn: 221357
|
|
|
|
| |
llvm-svn: 220855
|
|
|
|
|
|
|
| |
This eliminates converting back and forth between the 3 formats and
gives us a more homogeneous interface.
llvm-svn: 220657
|
|
|
|
| |
llvm-svn: 220646
|
|
|
|
| |
llvm-svn: 220644
|
|
|
|
| |
llvm-svn: 220639
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We would crash because we used operator[] to access past the end of a
SmallString. This occured because our token had length zero.
Instead, form the pointer using .data() and arithmetic. This is safe
because this forms a one-past-the-end pointer and it is only used to
compare with another one-past-the-end pointer.
This fixes PR21379.
llvm-svn: 220614
|
|
|
|
| |
llvm-svn: 220589
|
|
|
|
| |
llvm-svn: 220572
|
|
|
|
|
|
|
|
|
| |
This was not a real header role, and was never exposed to clients of ModuleMap.
Remove the enumeration value for it and track it as marking the header as
'known' rather than creating an extra KnownHeader entry that *every single*
client ignores.
llvm-svn: 220460
|
|
|
|
| |
llvm-svn: 220456
|
|
|
|
|
|
|
|
| |
This allows a module to specify that it logically contains a file, but that
said file is non-modular and intended for textual inclusion. This allows
layering checks to work properly in the presence of such files.
llvm-svn: 220448
|
|
|
|
|
|
|
|
|
|
|
|
| |
#include_next interacts poorly with modules: it depends on where in the list of
include paths the current file was found. Files covered by module maps are not
found in include search paths when building the module (and are not found in
include search paths when @importing the module either), so this isn't really
meaningful. Instead, we fake up the result that #include_next *should* have
given: find the first path that would have resulted in the given file being
picked, and search from there onwards.
llvm-svn: 220177
|
|
|
|
|
|
|
|
|
| |
position at the beginning of the file after the preamble.
Otherwise we will not hit the code-completion point.
llvm-svn: 220136
|
|
|
|
| |
llvm-svn: 220135
|
|
|
|
|
|
| |
loading multiple module map files from the same directory.
llvm-svn: 220020
|
|
|
|
| |
llvm-svn: 220014
|
|
|
|
| |
llvm-svn: 219637
|
|
|
|
|
|
|
|
|
|
|
| |
In code-completion, don't assume there is a MacroInfo for everything,
since we aren't serializing the def corresponding to a later #undef in
the same module. Also setup the HadMacro bit correctly for undefs to
avoid an assertion failure.
rdar://18416901
llvm-svn: 218694
|
|
|
|
|
|
|
|
|
| |
lexer, add the token buffer underneath the caching lexer where possible and
push the tokens directly into the caching lexer otherwise. We previously
put the lexer into a corrupted state where we could not guarantee to provide
the tokens in the right order and would sometimes assert.
llvm-svn: 218333
|
|
|
|
|
|
| |
Follow up to r217656
llvm-svn: 217829
|
|
|
|
| |
llvm-svn: 217656
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. We were hitting the NextIsPrevious assertion because we were trying
to merge decl chains that were independent of each other because we had
no Sema object to allow them to find existing decls. This is fixed by
delaying loading the "preloaded" decls until Sema is available.
2. We were trying to get identifier info from an annotation token, which
asserts. The fix is to special-case the module annotations in the
preprocessed output printer.
Fixed in a single commit because when you hit 1 you almost invariably
hit 2 as well.
llvm-svn: 217550
|
|
|
|
|
|
| |
Unique_ptr creation stil needs to be moved earlier at some of the call sites.
llvm-svn: 217474
|
|
|
|
| |
llvm-svn: 216786
|