| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 146868
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
chains. The previous implementation relied heavily on the declaration
chain being stored as a (circular) linked list on disk, as it is in
memory. However, when deserializing from multiple modules, the
different chains could get mixed up, leading to broken declaration chains.
The new solution keeps track of the first and last declarations in the
chain for each module file. When we load a declaration, we search all
of the module files for redeclarations of that declaration, then
splice together all of the lists into a coherent whole (along with any
redeclarations that were actually parsed).
As a drive-by fix, (de-)serialize the redeclaration chains of
TypedefNameDecls, which had somehow gotten missed previously. Add a
test of this serialization.
This new scheme creates a redeclaration table that is fairly large in
the PCH file (on the order of 400k for Cocoa.h's 12MB PCH file). The
table is mmap'd in and searched via a binary search, but it's still
quite large. A future tweak will eliminate entries for declarations
that have no redeclarations anywhere, and should
drastically reduce the size of this table.
llvm-svn: 146841
|
|
|
|
| |
llvm-svn: 146722
|
|
|
|
|
|
| |
check whether any previous declarations of the class were visible.
llvm-svn: 146680
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
diagnostic message are compared. If either is a substring of the other, then
no error is given. This gives rise to an unexpected case:
// expect-error{{candidate function has different number of parameters}}
will match the following error messages from Clang:
candidate function has different number of parameters (expected 1 but has 2)
candidate function has different number of parameters
It will also match these other error messages:
candidate function
function has different number of parameters
number of parameters
This patch will change so that the verification string must be a substring of
the diagnostic message before accepting. Also, all the failing tests from this
change have been corrected. Some stats from this cleanup:
87 - removed extra spaces around verification strings
70 - wording updates to diagnostics
40 - extra leading or trailing characters (typos, unmatched parens or quotes)
35 - diagnostic level was included (error:, warning:, or note:)
18 - flag name put in the warning (-Wprotocol)
llvm-svn: 146619
|
|
|
|
|
|
|
| |
is not visible, look for any previous declarations of that entity that
might be visible.
llvm-svn: 146563
|
|
|
|
|
|
| |
the subdirectories to find headers in submodules.
llvm-svn: 146398
|
|
|
|
|
|
|
| |
actually a terribly good heuristic, and the world is too horrible for
it to work.
llvm-svn: 146393
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
that's currently being built. This is important for supporting
transitive dependencies ("export *" in the module map) completely.
llvm-svn: 146156
|
|
|
|
|
|
| |
private headers in a framework.
llvm-svn: 146082
|
|
|
|
| |
llvm-svn: 146074
|
|
|
|
|
|
|
|
|
| |
when we load a module map (module.map) from a directory, also load a
private module map (module_private.map) for that directory, if
present. That private module map can inject a new submodule that
captures private headers.
llvm-svn: 146012
|
|
|
|
| |
llvm-svn: 145959
|
|
|
|
|
|
| |
modules for each of its subframeworks.
llvm-svn: 145957
|
|
|
|
| |
llvm-svn: 145945
|
|
|
|
|
|
|
|
| |
most specific (sub)module based on the actual file we find, rather
than always importing the top-level module. This means
that #include'ing <Foo/Blah.h> should give us the submodule Foo.Blah.
llvm-svn: 145942
|
|
|
|
|
|
|
|
| |
frameworks). A submodule can now be labeled as a "framework", and
header search will look into the appropriate Headers/PrivateHeaders
subdirectories for named headers.
llvm-svn: 145941
|
|
|
|
|
|
|
|
| |
explicit submodules or umbrella headers from submodules. Instead,
build the entire module at once, and let the name-hiding mechanisms
hide the contents of explicit submodules at load time.
llvm-svn: 145940
|
|
|
|
|
|
|
| |
implicitly generates submodules corresponding to the headers that fall
within a module.
llvm-svn: 145887
|
|
|
|
|
|
|
| |
Module, and (de-)serialize this information. Semantics of inferred
submodules to follow.
llvm-svn: 145864
|
|
|
|
|
|
| |
(i.e., 'export *'), to better match the semantics of headers.
llvm-svn: 145813
|
|
|
|
|
|
|
|
| |
to re-export anything that it imports. This opt-in feature makes a
module behave more like a header, because it can be used to re-export
the transitive closure of a (sub)module's dependencies.
llvm-svn: 145811
|
|
|
|
|
|
|
|
| |
"main" files that import modules. When loading any of these kinds of
AST files, we make the modules that were imported visible into the
translation unit that loaded the PCH file or preamble.
llvm-svn: 145737
|
|
|
|
| |
llvm-svn: 145710
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
precompiled header. Previously, we were trying to gather predefines
buffers from all kinds of AST files (which doesn't make sense) and
were performing some validation when AST files were loaded as main
files.
With these tweaks, using PCH files that import modules no longer fails
immediately (due to mismatched predefines buffers). However, module
visibility is lost, so this feature does not yet work.
llvm-svn: 145709
|
|
|
|
| |
llvm-svn: 145700
|
|
|
|
|
|
|
| |
visible, allowing one to create modules that import (and then
re-export) other modules.
llvm-svn: 145696
|
|
|
|
|
|
|
|
| |
only the macro definitions from visible (sub)modules will actually be
visible. This provides the same behavior for macros that r145640
provided for declarations.
llvm-svn: 145683
|
|
|
|
|
|
|
|
| |
within module maps, which will (eventually) be used to re-export a
module from another module. There are still some pieces missing,
however.
llvm-svn: 145665
|
|
|
|
|
|
| |
module. When that module becomes visible, so do those declarations.
llvm-svn: 145640
|
|
|
|
|
|
| |
an #include/#import as a module import.
llvm-svn: 145500
|
|
|
|
| |
llvm-svn: 145490
|
|
|
|
|
|
|
|
|
| |
check whether the named submodules themselves are actually
valid, and drill down to the named submodule (although we don't do
anything with it yet). Perform typo correction on the submodule names
when possible.
llvm-svn: 145477
|
|
|
|
|
|
|
| |
source file (e.g., a header). Immediately steal this useful option
name for building modules from a module map file.
llvm-svn: 145444
|
|
|
|
|
|
|
| |
module map, rather than assuming that there is an umbrella
header. This allows us to automatically build umbrella-less modules.
llvm-svn: 145415
|
|
|
|
|
|
|
| |
modules (obviously) describe frameworks, and understand the header
layout of frameworks.
llvm-svn: 144921
|
|
|
|
|
|
|
|
|
| |
into a module. This module can either be loaded from a module map in
the framework directory (which isn't quite working yet) or inferred
from an umbrella header (which does work, and replaces the existing
hack).
llvm-svn: 144877
|
|
|
|
| |
llvm-svn: 144862
|
|
|
|
|
|
|
|
| |
the umbrella header's directory and its subdirectories are part of the
module (that's why it's an umbrella). Make sure that these headers are
considered to be part of the module for lookup purposes.
llvm-svn: 144859
|
|
|
|
|
|
|
|
|
|
| |
file in the source manager. This allows us to properly create and use
modules described by module map files without umbrella headers (or
with incompletely umbrella headers). More generally, we can actually
build a PCH file that makes use of file -> buffer remappings, which
could be useful in libclang in the future.
llvm-svn: 144830
|
|
|
|
|
|
|
|
| |
header, create our own in-memory buffer to parse all of the
appropriate headers, and use that to build the module. This isn't
end-to-end testable yet; that's coming next.
llvm-svn: 144797
|
|
|
|
| |
llvm-svn: 144795
|
|
|
|
| |
llvm-svn: 144779
|
|
|
|
|
|
| |
and remove stray fprintf.
llvm-svn: 144742
|
|
|
|
|
|
|
| |
interface. This is currently limited to modules with umbrella
headers.
llvm-svn: 144736
|
|
|
|
|
|
|
|
| |
into a submodule. Submodules aren't actually supported anywhere else,
but we do parse them, so this verifies that we're at least seeing
through them properly.
llvm-svn: 144436
|
|
|
|
|
|
|
|
| |
the module is described in one of the module maps in a search path or
in a subdirectory off the search path that has the same name as the
module we're looking for.
llvm-svn: 144433
|