| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
| |
visible in the module we're considering entering. Previously we assumed that if
we knew the include guard for a modular header, we'd already parsed it, but
that need not be the case if a header is present in the current module and one
of its dependencies; the result of getting this wrong was that the current
module's submodule for the header would end up empty.
llvm-svn: 241953
|
|
|
|
|
|
| |
for a header to work in the presence of module hierarchy.
llvm-svn: 241936
|
|
|
|
|
|
| |
underlying types. A visible declaration is enough to make the type complete, but not enough to make the definition visible.
llvm-svn: 241743
|
|
|
|
|
|
| |
empty namespace.
llvm-svn: 241732
|
|
|
|
|
|
|
| |
instantiation, use the set of modules visible from the template definition, not
from whichever declaration the specialization was instantiated from.
llvm-svn: 241662
|
|
|
|
|
|
| |
of the llvm targets from clang/CodeGen into ClangCheck.cpp and CIndex.cpp.
llvm-svn: 241653
|
|
|
|
|
|
| |
failures.
llvm-svn: 241642
|
|
|
|
|
|
| |
r241620.
llvm-svn: 241623
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds ObjectFilePCHContainerOperations uses the LLVM backend
to put the contents of a PCH into a __clangast section inside a COFF, ELF,
or Mach-O object file container.
This is done to facilitate module debugging by makeing it possible to
store the debug info for the types defined by a module alongside the AST.
rdar://problem/20091852
llvm-svn: 241620
|
|
|
|
| |
llvm-svn: 241421
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We use findModuleForHeader() in several places, but in header search we
were not calling it when a framework module didn't show up with the
expected name, which would then lead to unexpected non-modular includes.
Now we will find the module unconditionally for frameworks. For regular
frameworks, we use the spelling of the module name from the module map
file, and for inferred ones we use the canonical directory name.
In the future we might want to lock down framework modules sufficiently
that these name mismatches cannot happen.
rdar://problem/20465870
llvm-svn: 241258
|
|
|
|
|
|
|
| |
rarely matters, but can affect whether two dependent types are canonically
equivalent.
llvm-svn: 241207
|
|
|
|
|
|
|
| |
class template specialization visible just because the class template
specialization's definition is visible.
llvm-svn: 241182
|
|
|
|
|
|
| |
parse-merging.
llvm-svn: 241180
|
|
|
|
|
|
| |
any source of the inline nature is sufficient.
llvm-svn: 241146
|
|
|
|
|
|
|
|
|
|
|
| |
update the identifier in case we've imported a definition of the macro (and
thus the contents of the header) from a module.
Also fold ExternalIdentifierLookup into ExternalPreprocessorSource; it no longer
makes sense to keep these separate now that the only user of the former also
needs the latter.
llvm-svn: 241137
|
|
|
|
|
|
|
| |
local submodule visibility enabled; that top-level file might not actually be
the module includes buffer if use of prebuilt modules is disabled.
llvm-svn: 241120
|
|
|
|
| |
llvm-svn: 241098
|
|
|
|
|
|
| |
than forward slashes as path separators.
llvm-svn: 241090
|
|
|
|
|
|
|
|
|
| |
This allows a module-aware debugger such as LLDB to import the currently
visible modules before dropping into the expression evaluator.
rdar://problem/20965932
llvm-svn: 241084
|
|
|
|
|
|
| |
r240971.
llvm-svn: 241047
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
cases
Several tests wouldn't pass when executed on an armv7a_pc_linux triple
due to the non-default arm_aapcs calling convention produced on the
function definitions in the IR output. Account for this with the
application of a little regex.
Patch by Ying Yi.
llvm-svn: 240971
|
|
|
|
|
|
|
|
| |
For r240967.
rdar://problem/21512307
llvm-svn: 240968
|
|
|
|
|
|
| |
parsing then merged again when the module was loaded.
llvm-svn: 240700
|
|
|
|
|
|
|
| |
Any extra features from -fmodule-feature are part of the module hash and
need to get validated on load. Also print them with -module-file-info.
llvm-svn: 240433
|
|
|
|
|
|
| |
they can write to the current working directory.
llvm-svn: 240388
|
|
|
|
|
|
|
|
|
| |
find.exe on newer version of Windows.
It seems "*.pcm" would be expanded with current directory by NTOS 6.x's msvcrt. GnuWin32 utils are affected.
To avoid the issue, put an expression that msvcrt's glob won't match, like "*.pc[m]".
llvm-svn: 240387
|
|
|
|
|
|
|
| |
file in the loaded module maps and one of them is from the current module,
that's the right match.
llvm-svn: 240350
|
|
|
|
|
|
|
|
|
|
|
|
| |
redefinitions of internal-linkage symbols that are not visible.
Such conflicts are an accident waiting to happen, and this feature conflicts
with the desire to include existing headers into multiple modules and merge the
results. (In an ideal world, it should not be possible to export internal
linkage symbols from a module, but sadly the glibc and libstdc++ headers
provide 'static inline' functions in a few cases.)
llvm-svn: 240335
|
|
|
|
|
|
| |
all modules even if we've already found a definition that's not visible.
llvm-svn: 240204
|
|
|
|
|
|
| |
imported definition.
llvm-svn: 240068
|
|
|
|
|
|
| |
making either of them visible makes the merged definition visible.
llvm-svn: 239969
|
|
|
|
| |
llvm-svn: 239954
|
|
|
|
|
|
| |
that we know when its default arguments should be visible.
llvm-svn: 239936
|
|
|
|
|
|
| |
argument is not visible.
llvm-svn: 239934
|
|
|
|
|
|
|
|
|
| |
Previously we'd complain about redefinition of default arguments when we
instantiated a class with a friend template that inherits its default argument,
because we propagate the default template arguemnt onto the friend when we
reload the AST.
llvm-svn: 239857
|
|
|
|
| |
llvm-svn: 239832
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We used to have a flag to enable module maps, and two more flags to enable
implicit module maps. This is all redundant; we don't need any flag for
enabling module maps in the abstract, and we don't usually have -fno- flags for
-cc1. We now have just a single flag, -fimplicit-module-maps, that enables
implicitly searching the file system for module map files and loading them.
The driver interface is unchanged for now. We should probably rename
-fmodule-maps to -fimplicit-module-maps at some point.
llvm-svn: 239789
|
|
|
|
| |
llvm-svn: 239783
|
|
|
|
|
|
| |
would collide
llvm-svn: 239765
|
|
|
|
|
|
|
| |
Support this across module save/reload and extend the 'missing import'
diagnostics with a list of providing modules.
llvm-svn: 239750
|
|
|
|
| |
llvm-svn: 239578
|
|
|
|
| |
llvm-svn: 239575
|
|
|
|
|
|
| |
with a base-specifier inside a namespace.
llvm-svn: 239569
|
|
|
|
|
|
| |
disabled but local module visibilty was enabled.
llvm-svn: 239504
|
|
|
|
| |
llvm-svn: 239487
|
|
|
|
|
|
|
| |
modules, and allow use of a default template argument if any of the parameters
providing it is visible.
llvm-svn: 239485
|
|
|
|
| |
llvm-svn: 239452
|
|
|
|
|
|
|
| |
This is just a preparatory step towards fixing visibility for default template
arguments in modules builds.
llvm-svn: 239447
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are still problems here, but this is a better starting point.
The main part of the change is: when doing a lookup that would accept visible
or hidden declarations, prefer to produce the latest visible declaration if
there are any visible declarations, rather than always producing the latest
declaration.
Thus, when we inherit default arguments (and other properties) from a previous
declaration, we inherit them from the previous visible declaration; if the
previous declaration is hidden, we already suppress inheritance of default
arguments.
There are a couple of other changes here that fix latent bugs exposed by this
change.
llvm-svn: 239371
|