| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239789 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As an optimization, we only kept declared methods with distinct
signatures in the global method pool, to keep the method lists
small. Under modules, however, one could have two different methods
with the same signature that occur in different (sub)modules. If only
the later submodule is important, message sends to 'id' with that
selector would fail because the first method (the only one that got
into the method pool) was hidden. When building a module, keep *all*
of the declared methods.
I did a quick check of both module build time and uses of modules, and
found no performance regression despite this causing us to keep more
methods in the global method pool. Fixes <rdar://problem/14148896>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184504 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
VerifyDiagnosticConsumer previously would not check that the diagnostic and
its matching directive referenced the same source file. Common practice was
to create directives that referenced other files but only by line number,
and this led to problems such as when the file containing the directive
didn't have enough lines to match the location of the diagnostic in the
other file, leading to bizarre file formatting and other oddities.
This patch causes VerifyDiagnosticConsumer to match source files as well as
line numbers. Therefore, a new syntax is made available for directives, for
example:
// expected-error@file:line {{diagnostic message}}
This extends the @line feature where "file" is the file where the diagnostic
is generated. The @line syntax is still available and uses the current file
for the diagnostic. "file" can be specified either as a relative or absolute
path - although the latter has less usefulness, I think! The #include search
paths will be used to locate the file and if it is not found an error will be
generated.
The new check is not optional: if the directive is in a different file to the
diagnostic, the file must be specified. Therefore, a number of test-cases
have been updated with regard to this.
This closes out PR15613.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179677 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
| |
visible, not when they become deserialized <rdar://problem/13203033>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175018 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
| |
visible <rdar://problem/13172858>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174648 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
| |
consistency.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174645 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
| |
when the methods are declared in a submodule that has not yet been
imported. Part of <rdar://problem/10634711>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172635 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
| |
latter is rather a mess to type.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169919 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
| |
commit to a particular syntax for modules,
and don't have time to push it forward in the near future.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151841 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
additional data from the external Sema source. This properly copes
with modules that are imported after we have already searched in the
global method pool for a given selector. For PCH, it's a slight
pessimization to be fixed soon.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148891 91177308-0d34-0410-b5e6-96231b3b80d8
|
