| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
involve submodules (e.g., importing std.vector), rather than always
importing the top-level module.
llvm-svn: 145478
|
|
|
|
|
|
|
| |
top-level module name to a module path (e.g., std.vector). We're still
missing a number of pieces for this actually to do something.
llvm-svn: 145462
|
|
|
|
|
|
| |
that use \ as a separator.
llvm-svn: 145439
|
|
|
|
|
|
|
| |
we infer the module map, we'll just print the module map to a
temporary file and generate the module using that.
llvm-svn: 145436
|
|
|
|
|
|
|
| |
module map, rather than assuming that there is an umbrella
header. This allows us to automatically build umbrella-less modules.
llvm-svn: 145415
|
|
|
|
|
|
| |
interface. No functionality change.
llvm-svn: 145411
|
|
|
|
|
|
|
|
| |
return the module itself (in the module map) rather than returning the
umbrella header used to build the module. While doing this, make sure
that we're inferring modules for frameworks to build that module.
llvm-svn: 145310
|
|
|
|
| |
llvm-svn: 145108
|
|
|
|
|
|
| |
The assert wasn't adding much value but slowed down Release+Asserts builds.
llvm-svn: 145082
|
|
|
|
|
|
| |
We can reuse the information and avoid looping over all the bytes again.
llvm-svn: 145070
|
|
|
|
|
|
| |
LangOpts.AddressSanitizer instead of CodeGenOpts.AddressSanitizer
llvm-svn: 145054
|
|
|
|
|
|
| |
from Jason Haslam!
llvm-svn: 145012
|
|
|
|
|
|
|
| |
preprocess/parse a header, report back with an actual module (which
may be a submodule) rather than just the name of the module.
llvm-svn: 144925
|
|
|
|
|
|
|
| |
modules (obviously) describe frameworks, and understand the header
layout of frameworks.
llvm-svn: 144921
|
|
|
|
| |
llvm-svn: 144880
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
interface. This is currently limited to modules with umbrella
headers.
llvm-svn: 144736
|
|
|
|
| |
llvm-svn: 144521
|
|
|
|
| |
llvm-svn: 144500
|
|
|
|
|
|
|
|
| |
module import: don't re-check for a loaded module unless we've
actually loaded a new module map file. Already-loaded module map files
aren't interesting.
llvm-svn: 144435
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
map, so long as they have an umbrella header. This makes it possible
to introduce a module map + umbrella header for a given set of
headers, to turn it into a module.
There are two major deficiencies here: first, we don't go hunting for
module map files when we just see a module import (so we won't know
about the modules described therein). Second, we don't yet have a way
to build modules that don't have umbrella headers, or have incomplete
umbrella headers.
llvm-svn: 144424
|
|
|
|
|
|
|
| |
the corresponding (top-level) modules. This isn't actually useful yet,
because we don't yet have a way to build modules out of module maps.
llvm-svn: 144410
|
|
|
|
|
|
| |
declarations to actual files.
llvm-svn: 144408
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Module map files provide a way to map between headers and modules, so
that we can layer a module system on top of existing headers without
changing those headers at all.
This commit introduces the module map file parser and the module map
that it generates, and wires up the module map file parser so that
we'll automatically find module map files as part of header
search. Note that we don't yet use the information stored in the
module map.
llvm-svn: 144402
|
|
|
|
|
|
| |
diagnostics in the future. Make it so.
llvm-svn: 144347
|
|
|
|
| |
llvm-svn: 143769
|
|
|
|
|
|
| |
for string literal parsing. No functional change on little-endian architectures; should fix test failures on PPC.
llvm-svn: 143585
|
|
|
|
|
|
|
|
|
|
| |
(For now, we are assuming the source character set is always UTF-8; this can be easily extended if necessary.)
Tests will be coming up in a subsequent commit.
Patch by Seth Cantrell.
llvm-svn: 143416
|
|
|
|
|
|
| |
__has_feature(cxx_unicode_literals), from Michel Morin!
llvm-svn: 143412
|
|
|
|
|
|
| |
functions", from Michel Morin!
llvm-svn: 143411
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
AST file more lazy, so that we don't eagerly load that information for
all known identifiers each time a new AST file is loaded. The eager
reloading made some sense in the context of precompiled headers, since
very few identifiers were defined before PCH load time. With modules,
however, a huge amount of code can get parsed before we see an
@import, so laziness becomes important here.
The approach taken to make this information lazy is fairly simple:
when we load a new AST file, we mark all of the existing identifiers
as being out-of-date. Whenever we want to access information that may
come from an AST (e.g., whether the identifier has a macro definition,
or what top-level declarations have that name), we check the
out-of-date bit and, if it's set, ask the AST reader to update the
IdentifierInfo from the AST files. The update is a merge, and we now
take care to merge declarations before/after imports with declarations
from multiple imports.
The results of this optimization are fairly dramatic. On a small
application that brings in 14 non-trivial modules, this takes modules
from being > 3x slower than a "perfect" PCH file down to 30% slower
for a full rebuild. A partial rebuild (where the PCH file or modules
can be re-used) is down to 7% slower. Making the PCH file just a
little imperfect (e.g., adding two smallish modules used by a bunch of
.m files that aren't in the PCH file) tips the scales in favor of the
modules approach, with 24% faster partial rebuilds.
This is just a first step; the lazy scheme could possibly be improved
by adding versioning, so we don't search into modules we already
searched. Moreover, we'll need similar lazy schemes for all of the
other lookup data structures, such as DeclContexts.
llvm-svn: 143100
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
deserializing
preprocessed entities that are #included in the range that we are interested.
This is useful when we are interested in preprocessed entities of a specific file, e.g
when we are annotating tokens. There is also an optimization where we cache the last
result of PreprocessingRecord::getPreprocessedEntitiesInRange and we re-use it if
there is a call with the same range as before.
rdar://10313365
llvm-svn: 142887
|
|
|
|
| |
llvm-svn: 142423
|
|
|
|
|
|
| |
Me, I believe him.
llvm-svn: 142327
|
|
|
|
| |
llvm-svn: 142324
|
|
|
|
| |
llvm-svn: 142284
|
|
|
|
|
|
|
| |
public. Add a __private_macro__ directive to hide a macro, similar to
the __module_private__ declaration specifier.
llvm-svn: 142188
|
|
|
|
|
|
|
|
| |
This also adds a -Wc++98-compat-pedantic for warning on constructs which would
be diagnosed by -std=c++98 -pedantic (that is, it warns even on C++11 features
which we enable by default, with no warning, in C++98 mode).
llvm-svn: 142034
|
|
|
|
| |
llvm-svn: 142020
|
|
|
|
|
|
| |
operator is seen, from Jason Haslam!
llvm-svn: 141926
|
|
|
|
|
|
| |
warning flag is valid. Fixes <rdar://problem/10263428>.
llvm-svn: 141802
|
|
|
|
| |
llvm-svn: 141798
|
|
|
|
|
|
| |
fixes http://llvm.org/PR11120
llvm-svn: 141788
|
|
|
|
|
|
|
| |
swaps over the <<<< and >>>> markers, and uses shorter markers than traditional
tools.
llvm-svn: 141751
|
|
|
|
|
|
| |
C++98 mode. Only the first occurrence of each keyword will produce a warning.
llvm-svn: 141700
|
|
|
|
| |
llvm-svn: 141681
|
|
|
|
| |
llvm-svn: 141596
|
|
|
|
| |
llvm-svn: 141012
|