| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
for completeness and use it in CompilerInstance::InitializeSourceManager if
the input is a memory buffer.
llvm-svn: 167628
|
|
|
|
|
|
| |
viceversa). No functionality change.
llvm-svn: 167591
|
|
|
|
|
|
| |
module in place. <rdar://problem/10138913>
llvm-svn: 167539
|
|
|
|
|
|
|
|
|
| |
Spent longer than reasonable looking for a nice way to test this & decided to
give up for now. Open to suggestions/requests. Richard Smith suggested adding
something to ASTMatchers but it wasn't readily apparent how to test this with
that.
llvm-svn: 167507
|
|
|
|
|
|
| |
the validation of an AST file against a specific set of options.
llvm-svn: 167504
|
|
|
|
| |
llvm-svn: 167426
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
reference instead of relying on computing it.
In general, if storage is no issue, it is preferable to deserialize info from
the PCH instead of trying to recompute it after the PCH was loaded.
The incentive to change this now was due to r155303 changing how friend template
classes in dependent contexts are handled; such classes can now be chained to
a previous template class but the computed InjectedClassNameType may be different
due to the extra template parameters from the dependent context.
The new handling requires more investigation but, in the meantime, writing out
InjectedClassNameType fixes PCH issue in rdar://12627738.
llvm-svn: 167425
|
|
|
|
|
|
| |
is getting converted to a global PreprocessedEntityID.
llvm-svn: 167280
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The stat cache became essentially useless ever since we started
validating all file entries in the PCH.
But the motivating reason for removing it now is that it also affected
correctness in this situation:
-You have a header without include guards (using "#pragma once" or #import)
-When creating the PCH:
-The same header is referenced in an #include with different filename cases.
-In the PCH, of course, we record only one file entry for the header file
-But we cache in the PCH file the stat info for both filename cases
-Then the source files are updated and the header file is updated in a way that
its size and modification time are the same but its inode changes
-When using the PCH:
-We validate the headers, we check that header file and we create a file entry with its current inode
-There's another #include with a filename with different case than the previously created file entry
-In order to get its stat info we go through the cached stat info of the PCH and we receive the old inode
-because of the different inodes, we think they are different files so we go ahead and include its contents.
Removing the stat cache will potentially break clients that are attempting to use the stat cache
as a way of avoiding having the actual input files available. If that use case is important, patches are welcome
to bring it back in a way that will actually work correctly (i.e., emit a PCH that is self-contained, coping with
literal strings, line/column computations, etc.).
This fixes rdar://5502805
llvm-svn: 167172
|
|
|
|
|
|
|
| |
MaybeAddSystemRootToFilename doesn't need to return anything, it modifies
its argument.
llvm-svn: 166988
|
|
|
|
|
|
|
|
|
| |
diagnostic states; make sure the ASTReader sets the diagnostic state
properly instead of always recreating it.
Fixes rdar://12581618 & http://llvm.org/PR14181
llvm-svn: 166987
|
|
|
|
|
|
|
| |
replaced by the more efficient, cleaner preprocessor-option version
that occurs earlier in PCH validation.
llvm-svn: 166654
|
|
|
|
|
|
| |
checking, and disable the old predefines-buffer-diff'ing code path.
llvm-svn: 166653
|
|
|
|
|
|
|
| |
predefines. We're not quite ready to cut over to these suggested
predefines yet, however.
llvm-svn: 166648
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the macros that are #define'd or #undef'd on the command line. This
checking happens much earlier than the current macro-definition
checking and is far cleaner, because it does a direct comparison
rather than a diff of the predefines buffers. Moreover, it allows us
to use the result of this check to skip over PCH files within a
directory that have non-matching -D's or -U's on the command
line. Finally, it improves the diagnostics a bit for mismatches,
fixing <rdar://problem/8612222>.
The old predefines-buffer diff'ing will go away in a subsequent commit.
llvm-svn: 166641
|
|
|
|
|
|
| |
-include'd files, etc.
llvm-svn: 166614
|
|
|
|
| |
llvm-svn: 166586
|
|
|
|
| |
llvm-svn: 166577
|
|
|
|
| |
llvm-svn: 166572
|
|
|
|
|
|
|
|
|
| |
check each of the files within that directory to determine if any of
them is an AST file that matches the language and target options. If
so, the first matching AST file is loaded. This fixes a longstanding
discrepency with GCC's precompiled header implementation.
llvm-svn: 166469
|
|
|
|
|
|
|
|
|
|
| |
failures they know how to tolerate, e.g., out-of-date input files or
configuration/version mismatches. Suppress the corresponding
diagnostics if the client can handle it.
No clients actually use this functionality, yet.
llvm-svn: 166449
|
|
|
|
|
|
| |
ReadSLocEntry(). No functionality change.
llvm-svn: 166447
|
|
|
|
|
|
|
|
| |
file corruption, compiler version mismatch, target/language
configuration mismatch, out-of-date AST file. No functionality change
yet.
llvm-svn: 166446
|
|
|
|
| |
llvm-svn: 166442
|
|
|
|
|
|
|
|
|
|
| |
manager block and input-file information in the control block. The
source manager entries now point back into the control block. Input
files are now lazily deserialized (if validation is disabled). Reduces
Cocoa's PCH by the ~70k I added when I introduced the redundancy in
r166251.
llvm-svn: 166429
|
|
|
|
| |
llvm-svn: 166257
|
|
|
|
| |
llvm-svn: 166252
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
block, so the input files are validated early on, before we've
committed to loading the AST file. This (accidentally) fixed a but
wherein the main file used to generate the AST file would *not* be
validated by the existing validation logic.
At the moment, this leads to some duplication of filenames between the
source manager block and input-file blocks, as well as validation
logic. This will be handled via an upcoming patch.
llvm-svn: 166251
|
|
|
|
| |
llvm-svn: 166233
|
|
|
|
| |
llvm-svn: 166229
|
|
|
|
|
|
| |
module files.
llvm-svn: 166228
|
|
|
|
| |
llvm-svn: 166208
|
|
|
|
|
|
| |
single record.
llvm-svn: 166206
|
|
|
|
|
|
|
| |
metadata record, which already had other version information. Clean up
the block info block along the way.
llvm-svn: 166204
|
|
|
|
|
|
| |
file's control block.
llvm-svn: 166195
|
|
|
|
|
|
| |
namespace.
llvm-svn: 166194
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
block, which stores information about how the AST file to generated,
from the AST block, which stores the actual serialized AST. The
information in the control block should be enough to determine whether
the AST file is up-to-date and compatible with the current translation
unit, and reading it should not cause any side effects that aren't
easy to undo. That way, we can back out from an attempt to read an
incompatible or out-of-date AST file.
Note that there is still more factoring to do. In particular,
information about the source files used to generate the AST file
(along with their time stamps, sizes, etc.) still resides in the
source manager block.
llvm-svn: 166166
|
|
|
|
|
|
|
|
|
| |
has ivars that require destruction, but none that require anything
except zero-initialization. This is common in ARC and (when true
throughout a class hierarchy) permits the elimination of an
unnecessary message-send during allocation.
llvm-svn: 166088
|
|
|
|
|
|
|
| |
target options around so they can be accessed at any point (rather
than keeping them transient).
llvm-svn: 166072
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 165921
|
|
|
|
| |
llvm-svn: 165788
|
|
|
|
|
|
| |
#undef only occurs if that submodule is imported.
llvm-svn: 165773
|
|
|
|
|
|
|
| |
only with modules, when two disjoint modules #define the same
identifier to different token sequences.
llvm-svn: 165746
|
|
|
|
|
|
| |
associated with deserializing macro history for an identifier.
llvm-svn: 165729
|
|
|
|
| |
llvm-svn: 165727
|
|
|
|
|
|
|
|
|
| |
The ASTUnit needs to initialize an ASTWriter at the beginning of
parsing to fully handle serialization of a translation unit that
imports modules. Do this by introducing an option to enable it, which
corresponds to CXTranslationUnit_ForSerialization on the C API side.
llvm-svn: 165717
|
|
|
|
|
|
|
| |
is no longer necessary, as well as the little bit of infrastructure in
the AST writer that used it.
llvm-svn: 165684
|
|
|
|
| |
llvm-svn: 165683
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 165682
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This more accurately reflects its use: this flag is set when a method
matches the getter or setter name for a property in the same class,
and does not actually specify whether or not the definition of the method
will be synthesized (either implicitly or explicitly with @synthesize).
This renames the setter and backing field as well, and changes the
(soon-to-be-obsolete?) XML dump format to use 'property_accessor'
instead of 'synthesized'.
llvm-svn: 165626
|