| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
to r169831.
"ansi-escape-sequences" is easy convenient to exclude win32. Please be patient.
llvm-svn: 169945
|
|
|
|
| |
llvm-svn: 169922
|
|
|
|
|
|
| |
latter is rather a mess to type.
llvm-svn: 169919
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 169434
|
|
|
|
|
|
| |
expressions, for now.
llvm-svn: 169375
|
|
|
|
|
|
|
| |
the LHS of a token paste. Use "expanded from here" instead when we're not sure
it's actually a macro.
llvm-svn: 169373
|
|
|
|
| |
llvm-svn: 169058
|
|
|
|
|
|
|
|
|
|
| |
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>
llvm-svn: 169057
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
llvm-svn: 169042
|
|
|
|
|
|
|
|
|
| |
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>.
llvm-svn: 169021
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>.
llvm-svn: 168961
|
|
|
|
| |
llvm-svn: 168077
|
|
|
|
|
|
| |
module in place. <rdar://problem/10138913>
llvm-svn: 167539
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 167482
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 167423
|
|
|
|
|
|
|
|
| |
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).
llvm-svn: 167398
|
|
|
|
|
|
| |
(so that it can have additional options set when trying to debug issues causing regressions).
llvm-svn: 166681
|
|
|
|
|
|
| |
VerifyDiagnosticConsumer, make the necessary adjustment to 580 test-cases which will henceforth require this new directive.
llvm-svn: 166280
|
|
|
|
|
|
|
|
| |
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: 165822
|
|
|
|
|
|
|
| |
or directories, to make sure that they are identifiers that are not
keywords in any dialect. Fixes <rdar://problem/12489495>.
llvm-svn: 165821
|
|
|
|
|
|
| |
#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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 165560
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 165513
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 165005
|
|
|
|
|
|
| |
the ASTConsumer.
llvm-svn: 165001
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 164993
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 164932
|
|
|
|
|
|
| |
Don't require specializations (of existing and read template) to be unique.
llvm-svn: 164931
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 164927
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 164605
|
|
|
|
|
|
|
| |
statement starts with an identifier for which name lookup will fail either way,
look at later tokens to disambiguate in order to improve error recovery.
llvm-svn: 162464
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The old behavior was to re-scan any files (like modules) where we may have
directives but won't actually be parsing during the -verify invocation.
Now, we keep the old behavior in Debug builds as a sanity check (though
modules are a known entity), and expect all legitimate directives to come
from comments seen by the preprocessor.
This also affects the ARC migration tool, which captures diagnostics in
order to filter some out. This change adds an explicit cleanup to
CaptureDiagnosticsConsumer in order to let its sub-consumer handle the
real end of diagnostics.
This was originally split into four patches, but the tests do not run
cleanly without all four, so I've combined them into one commit.
Patches by Andy Gibbs, with slight modifications from me.
llvm-svn: 161650
|
|
|
|
| |
llvm-svn: 160622
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is accomplished by making VerifyDiagnosticsConsumer a CommentHandler,
which then only reads the -verify directives that are actually in live
blocks of code. It also makes it simpler to handle -verify directives that
appear in header files, though we still have to manually reparse some files
depending on how they are generated.
This requires some test changes. In particular, all PCH tests now have their
-verify directives outside the "header" portion of the file, using the @line
syntax added in r159978. Other tests have been modified mostly to make it
clear what is being tested, and to prevent polluting the expected output with
the directives themselves.
Patch by Andy Gibbs! (with slight modifications)
The new Frontend/verify-* tests exercise the functionality of this commit,
as well as r159978, r159979, and r160053 (Andy's other -verify enhancements).
llvm-svn: 160068
|
|
|
|
| |
llvm-svn: 156923
|
|
|
|
|
|
|
| |
turns out that it's actually needed for C++ modules support. Since simplifying
it didn't cause any test failures, I'll add a test for it.
llvm-svn: 154582
|
|
|
|
|
|
|
|
|
| |
root class is intentionally declared.
The warning this inhibits, -Wobjc-root-class, is opt-in for now. However, all clang unit tests that would trigger
the warning have been updated to use -Wno-objc-root-class. <rdar://problem/7446698>
llvm-svn: 154187
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The deferred lookup table building step couldn't accurately tell which Decls
should be included in the lookup table, and consequently built different tables
in some cases.
Fix this by removing lazy building of DeclContext name lookup tables. In
practice, the laziness was frequently not worthwhile in C++, because we
performed lookup into most DeclContexts. In C, it had a bit more value,
since there is no qualified lookup.
In the place of lazy lookup table building, we simply don't build lookup tables
for function DeclContexts at all. Such name lookup tables are not useful, since
they don't capture the scoping information required to correctly perform name
lookup in a function scope.
The resulting performance delta is within the noise on my testing, but appears
to be a very slight win for C++ and a very slight loss for C. The C performance
can probably be recovered (if it is a measurable problem) by avoiding building
the lookup table for the translation unit.
llvm-svn: 152608
|
|
|
|
|
|
|
|
| |
commit to a particular syntax for modules,
and don't have time to push it forward in the near future.
llvm-svn: 151841
|
|
|
|
| |
llvm-svn: 149626
|
|
|
|
| |
llvm-svn: 149624
|
|
|
|
|
|
| |
don't need it here
llvm-svn: 149613
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
into using non-absolute system includes (<foo>)...
... and introduce another hack that is simultaneously more heineous
and more effective. We whitelist Clang-supplied headers that augment
or override system headers (such as float.h, stdarg.h, and
tgmath.h). For these headers, Clang does not provide a module
mapping. Instead, a system-supplied module map can refer to these
headers in a system module, and Clang will look both in its own
include directory and wherever the system-supplied module map
suggests, then adds either or both headers. The end result is that
Clang-supplied headers get merged into the system-supplied module for
the C standard library.
As a drive-by, fix up a few dependencies in the _Builtin_instrinsics
module.
llvm-svn: 149611
|
|
|
|
|
|
|
|
| |
On Cygwin, at first, <stddef.h> is included without __need_wint_t.
Next, <stddef.h> is included with __need_wint_t, though Modules feature would not process <stddef.h> twice.
Then, wint_t is not found in system headers.
llvm-svn: 149500
|
|
|
|
|
|
| |
provides size_t.
llvm-svn: 149499
|
|
|
|
|
|
|
|
| |
builds, and bring mm_alloc.h into the fold. Start playing some tricks
with these builtin modules to mirror the include_next tricks that the
headers already perform.
llvm-svn: 149434
|
|
|
|
|
|
|
| |
cyclic module dependency due to its inclusion of math.h and
complex.h. I'll take another shot at it later.
llvm-svn: 149283
|