Age | Commit message (Collapse) | Author |
|
module in place. <rdar://problem/10138913>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167539 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167482 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
token. This is important because the first token could actually be
after an #include that triggers a module import, which might use
either Sema or the AST consumer before it would have been initialized.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167423 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
While we're here, extend the module map to cover most of the
newly-added instrinsic headers. Only wmmintrin.h is missing, because
it needs to be split into AES/PCLMUL subheaders (as a separate commit).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167398 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
(so that it can have additional options set when trying to debug issues causing regressions).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166681 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
VerifyDiagnosticConsumer, make the necessary adjustment to 580 test-cases which will henceforth require this new directive.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166280 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165921 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165822 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
or directories, to make sure that they are identifiers that are not
keywords in any dialect. Fixes <rdar://problem/12489495>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165821 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
#undef only occurs if that submodule is imported.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165773 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
only with modules, when two disjoint modules #define the same
identifier to different token sequences.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165746 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165682 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165560 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
whether that function/method already has a body (loaded from some
other AST file), as introduced in r165137. Delay this check until
after the redeclaration chains have been wired up.
While I'm here, make the loading of method bodies lazy.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165513 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the merging should have set it correctly.
This is especially relevant for templatedDecls that might be injected (and thus have their DeclContext set to) somewhere completely different.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165005 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the ASTConsumer.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165001 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Check whether a pending instantiation needs to be instantiated (or whether an instantiation already exists).
Verify the size of the PendingInstantiations record (was only checking size of existing PendingInstantiations).
Migrate Obj-C++ part of redecl-merge into separate test, now that this is growing.
templates.mm: test that CodeGen has seen exactly one definition of template instantiations.
redecl-merge.m: use "@" specifier for expected-diagnostics.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164993 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Lookup can nevertheless find them due to the serialized lookup table.
For instance when reading a template decl's templatedDecl, it will search for existing decls that it could be a redeclaration of, and find the half-read template decl.
Thus there is no point in asserting the names of decls.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164932 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Don't require specializations (of existing and read template) to be unique.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164931 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
specialization was written, which is non-canonical at the time of reading: force the reading of the ClassTemplateDecl if it was written.
The easiest way out is to store whether the decl was canonical at the time of writing.
Add test.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164927 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
specific module (__building_module(modulename)) and to get the name of
the current module as an identifier (__MODULE__).
Used to help headers behave differently when they're being included as
part of building a module. Oh, the irony.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164605 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
statement starts with an identifier for which name lookup will fail either way,
look at later tokens to disambiguate in order to improve error recovery.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162464 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The old behavior was to re-scan any files (like modules) where we may have
directives but won't actually be parsing during the -verify invocation.
Now, we keep the old behavior in Debug builds as a sanity check (though
modules are a known entity), and expect all legitimate directives to come
from comments seen by the preprocessor.
This also affects the ARC migration tool, which captures diagnostics in
order to filter some out. This change adds an explicit cleanup to
CaptureDiagnosticsConsumer in order to let its sub-consumer handle the
real end of diagnostics.
This was originally split into four patches, but the tests do not run
cleanly without all four, so I've combined them into one commit.
Patches by Andy Gibbs, with slight modifications from me.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161650 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160622 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is accomplished by making VerifyDiagnosticsConsumer a CommentHandler,
which then only reads the -verify directives that are actually in live
blocks of code. It also makes it simpler to handle -verify directives that
appear in header files, though we still have to manually reparse some files
depending on how they are generated.
This requires some test changes. In particular, all PCH tests now have their
-verify directives outside the "header" portion of the file, using the @line
syntax added in r159978. Other tests have been modified mostly to make it
clear what is being tested, and to prevent polluting the expected output with
the directives themselves.
Patch by Andy Gibbs! (with slight modifications)
The new Frontend/verify-* tests exercise the functionality of this commit,
as well as r159978, r159979, and r160053 (Andy's other -verify enhancements).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160068 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156923 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
turns out that it's actually needed for C++ modules support. Since simplifying
it didn't cause any test failures, I'll add a test for it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154582 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
root class is intentionally declared.
The warning this inhibits, -Wobjc-root-class, is opt-in for now. However, all clang unit tests that would trigger
the warning have been updated to use -Wno-objc-root-class. <rdar://problem/7446698>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154187 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The deferred lookup table building step couldn't accurately tell which Decls
should be included in the lookup table, and consequently built different tables
in some cases.
Fix this by removing lazy building of DeclContext name lookup tables. In
practice, the laziness was frequently not worthwhile in C++, because we
performed lookup into most DeclContexts. In C, it had a bit more value,
since there is no qualified lookup.
In the place of lazy lookup table building, we simply don't build lookup tables
for function DeclContexts at all. Such name lookup tables are not useful, since
they don't capture the scoping information required to correctly perform name
lookup in a function scope.
The resulting performance delta is within the noise on my testing, but appears
to be a very slight win for C++ and a very slight loss for C. The C performance
can probably be recovered (if it is a measurable problem) by avoiding building
the lookup table for the translation unit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152608 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
commit to a particular syntax for modules,
and don't have time to push it forward in the near future.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151841 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149626 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149624 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
don't need it here
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149613 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
into using non-absolute system includes (<foo>)...
... and introduce another hack that is simultaneously more heineous
and more effective. We whitelist Clang-supplied headers that augment
or override system headers (such as float.h, stdarg.h, and
tgmath.h). For these headers, Clang does not provide a module
mapping. Instead, a system-supplied module map can refer to these
headers in a system module, and Clang will look both in its own
include directory and wherever the system-supplied module map
suggests, then adds either or both headers. The end result is that
Clang-supplied headers get merged into the system-supplied module for
the C standard library.
As a drive-by, fix up a few dependencies in the _Builtin_instrinsics
module.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149611 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
On Cygwin, at first, <stddef.h> is included without __need_wint_t.
Next, <stddef.h> is included with __need_wint_t, though Modules feature would not process <stddef.h> twice.
Then, wint_t is not found in system headers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149500 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
provides size_t.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149499 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
builds, and bring mm_alloc.h into the fold. Start playing some tricks
with these builtin modules to mirror the include_next tricks that the
headers already perform.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149434 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
cyclic module dependency due to its inclusion of math.h and
complex.h. I'll take another shot at it later.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149283 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
each of the targets. Use this for module requirements, so that we can
pin the availability of certain modules to certain target features,
e.g., provide a module for xmmintrin.h only when SSE support is
available.
Use these feature names to provide a nearly-complete module map for
Clang's built-in headers. Only mm_alloc.h and unwind.h are missing,
and those two are fairly specialized at the moment. Finishes
<rdar://problem/10710060>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149227 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149214 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149213 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149212 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149210 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149209 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
useful output from the buildbots
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149208 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
headers. The remaining headers require more sophisticated
requirements; they'll be handled separately. Part of
<rdar://problem/10710060>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149206 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149196 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
single attribute ("system") that allows us to mark a module as being a
"system" module. Each of the headers that makes up a system module is
considered to be a system header, so that we (for example) suppress
warnings there.
If a module is being inferred for a framework, and that framework
directory is within a system frameworks directory, infer it as a
system framework.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149143 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the direct serialization of the linked-list structure. Instead, use a
scheme similar to how we handle redeclarations, with redeclaration
lists on the side. This addresses several issues:
- In cases involving mixing and matching of many categories across
many modules, the linked-list structure would not be consistent
across different modules, and categories would get lost.
- If a module is loaded after the class definition and its other
categories have already been loaded, we wouldn't see any categories
in the newly-loaded module.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149112 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
additional data from the external Sema source. This properly copes
with modules that are imported after we have already searched in the
global method pool for a given selector. For PCH, it's a slight
pessimization to be fixed soon.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148891 91177308-0d34-0410-b5e6-96231b3b80d8
|