Age | Commit message (Collapse) | Author |
|
bogus with a PCH
that redefined a macro without undef'ing it first.
Proper reconstruction of the macro info history from modules will properly fix this in subsequent commits.
rdar://13016031
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173281 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172695 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
in the LangRef).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172692 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Investigating.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172689 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
undefined, and don't find methods or protocols within those protocol
definitions. This completes <rdar://problem/10634711>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172686 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
consider (sub)module visibility.
The bulk of this change replaces myriad hand-rolled loops over the
linked list of Objective-C categories/extensions attached to an
interface declaration with loops using one of the four new category
iterator kinds:
visible_categories_iterator: Iterates over all visible categories
and extensions, hiding any that have their "hidden" bit set. This is
by far the most commonly used iterator.
known_categories_iterator: Iterates over all categories and
extensions, ignoring the "hidden" bit. This tends to be used for
redeclaration-like traversals.
visible_extensions_iterator: Iterates over all visible extensions,
hiding any that have their "hidden" bit set.
known_extensions_iterator: Iterates over all extensions, whether
they are visible to normal name lookup or not.
The effect of this change is that any uses of the visible_ iterators
will respect module-import visibility. See the new tests for examples.
Note that the old accessors for categories and extensions are gone;
there are *Raw() forms for some of them, for those (few) areas of the
compiler that have to manipulate the linked list of categories
directly. This is generally discouraged.
Part two of <rdar://problem/10634711>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172665 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
when the methods are declared in a submodule that has not yet been
imported. Part of <rdar://problem/10634711>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172635 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
users can explicitly enable/disable modules autolinking.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172592 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
module-import dependencies, so we'll get the link order correct for
those silly linkers that need it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172459 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
link options for the modules it imports.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172448 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
!0 = metadata !{metadata !"-lautolink"}
!1 = metadata !{metadata !"-framework", metadata !"autolink_framework"}
referenced from llvm.module.linkoptions, e.g.,
!llvm.module.linkoptions = !{!0, !1, !2, !3}
This conceptually moves the logic for figuring out the syntax the
linker will accept from LLVM into Clang. Moreover, it makes it easier
to support MSVC's
#pragma comment(linker, "some option")
in the future, should anyone care to do so.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172441 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
will have a shared library with the same name as its framework (and no
suffix!) within its .framework directory. Detect this both when
inferring the whole top-level framework and when parsing a module map.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172439 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
metadata for linking against the libraries/frameworks for imported
modules.
The module map language is extended with a new "link" directive that
specifies what library or framework to link against when a module is
imported, e.g.,
link "clangAST"
or
link framework "MyFramework"
Importing the corresponding module (or any of its submodules) will
eventually link against the named library/framework.
For now, I've added some placeholder global metadata that encodes the
imported libraries/frameworks, so that we can test that this
information gets through to the IR. The format of the data is still
under discussion.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172437 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
which a particular declaration resides. Use this information to
customize the "definition of 'blah' must be imported from another
module" diagnostic with the module the user actually has to
import. Additionally, recover by importing that module, so we don't
complain about other names in that module.
Still TODO: coming up with decent Fix-Its for these cases, and expand
this recovery approach for other name lookup failures.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172290 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
(because they are part of some module) but have not been made visible
(because they are in a submodule that wasn't imported), filter out
those declarations unless both the old declaration and the new
declaration have external linkage. When one or both has internal
linkage, there should be no conflict unless both are imported.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171925 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171497 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171478 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
to r169831.
"ansi-escape-sequences" is easy convenient to exclude win32. Please be patient.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169945 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169922 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
latter is rather a mess to type.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169919 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
RUN: a
RUN: b || true
lit expands it to a && b || true, and the || true applies to both commands (thus ignoring failures in 'a')! This is PR10867 again.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169434 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
expressions, for now.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169375 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the LHS of a token paste. Use "expanded from here" instead when we're not sure
it's actually a macro.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169373 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169058 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
state so that all of the various clones end up rendering their
diagnostics into the same serialized-diagnostics file. This is
important when we actually want failures during module build to be
reported back to the translation unit that tried to import the
not-yet-built or out-of-date module. <rdar://problem/12565727>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169057 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
module, provide a module import stack similar to what we would get for
an include stack, e.g.,
In module 'DependsOnModule' imported from build-fail-notes.m:4:
In module 'Module' imported from DependsOnModule.framework/Headers/DependsOnModule.h:1:
Inputs/Module.framework/Headers/Module.h:15:12: note: previous definition is here
@interface Module
<rdar://problem/12696425>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169042 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
building module 'Foo' imported from..." notes (the same we we provide
"In file included from..." notes) in the diagnostic, so that we know
how this module got included in the first place. This is part of
<rdar://problem/12696425>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169021 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
import of that module elsewhere, don't try to build the module again:
it won't work, and the experience is quite dreadful. We track this
information somewhat globally, shared among all of the related
CompilerInvocations used to build modules on-the-fly, so that a
particular Clang instance will only try to build a given module once.
Fixes <rdar://problem/12552849>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168961 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168077 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
|