framework module SomeKitCore {
...
export_as SomeKit
}
Given the module above, while generting autolink information during
codegen, clang should to emit '-framework SomeKitCore' only if SomeKit
was not imported in the relevant TU, otherwise it should use '-framework
SomeKit' instead.
rdar://problem/38269782
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@330152 91177308-0d34-0410-b5e6-96231b3b80d8
The current support of the feature produces only 2 lines in report:
-Some general Code Generation Time;
-Total time of Backend Consumer actions.
This patch extends Clang time report with new lines related to Preprocessor, Include Filea Search, Parsing, etc.
Differential Revision: https://reviews.llvm.org/D43578
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@329684 91177308-0d34-0410-b5e6-96231b3b80d8
Found via codespell -q 3 -I ../clang-whitelist.txt
Where whitelist consists of:
archtype
cas
classs
checkk
compres
definit
frome
iff
inteval
ith
lod
methode
nd
optin
ot
pres
statics
te
thru
Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few
files that have dubious fixes reverted.)
Differential revision: https://reviews.llvm.org/D44188
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@329399 91177308-0d34-0410-b5e6-96231b3b80d8
This make -ivfsoverlay behave more like other fatal errors (e.g. missing
-include file) by skipping the missing file instead of bailing out of
the whole compilation. This makes it possible for libclang to still
provide some functionallity as well as to correctly produce the fatal
error diagnostic (previously we lost the diagnostic in libclang since
there was no TU to tie it to).
rdar://33385423
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@328337 91177308-0d34-0410-b5e6-96231b3b80d8
I'm not sure /why/ this is causing issues for libclang, but it is.
Unbreak the buildbots since it's already consumed an hour of my time.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@328286 91177308-0d34-0410-b5e6-96231b3b80d8
...and add some very basic stack trace entries for module building.
This would have helped track down rdar://problem/38434694 sooner.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@328276 91177308-0d34-0410-b5e6-96231b3b80d8
When skipping building the module for a private framework module,
LangOpts.CurrentModule isn't enough for implict modules builds; for
instance, in case a private module is built while building a public one,
LangOpts.CurrentModule doesn't reflect the -fmodule-name being passed
down, but instead the module name which triggered the build.
Store the actual -fmodule-name in LangOpts.ModuleName and actually
check a name was provided during compiler invocation in order to
skip building the private module.
rdar://problem/38434694
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@328053 91177308-0d34-0410-b5e6-96231b3b80d8
In case `@import Foo.Private` fails because the submodule doesn't exist,
look for `Foo_Private` (if available) and build/load that module
instead. In that process emit a warning and tell the user about the
assumption.
The intention here is to assist all existing private modules owners
(in ObjC and Swift) to migrate to the new `Foo_Private` syntax.
rdar://problem/36023940
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@321342 91177308-0d34-0410-b5e6-96231b3b80d8
Move the logic for determining the `wchar_t` type information into the
driver. Rather than passing the single bit of information of
`-fshort-wchar` indicate to the frontend the desired type of `wchar_t`
through a new `-cc1` option of `-fwchar-type` and indicate the
signedness through `-f{,no-}signed-wchar`. This replicates the current
logic which was spread throughout Basic into the
`RenderCharacterOptions`.
Most of the changes to the tests are to ensure that the frontend uses
the correct type. Add a new test set under `test/Driver/wchar_t.c` to
ensure that we calculate the proper types for the various cases.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315126 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The CompilerInstance should create its default VFS from its CompilerInvocation. Right now the
user has to manually create the VFS before creating the FileManager even though
`-ivfsoverlay file.yaml` was passed via the CompilerInvocation (which is exactly how we worked
around this issue in `FrontendAction.cpp` so far).
This patch uses the invocation's VFS by default and also tests this behavior now from the
point of view of a program that uses the clang API.
Reviewers: benlangmuir, v.g.vassilev
Reviewed By: v.g.vassilev
Subscribers: mgorny, cfe-commits, v.g.vassilev
Differential Revision: https://reviews.llvm.org/D37416
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@313049 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes a possible crash on certain kinds of corrupted AST file, but
checking in an AST file corrupted in just the right way will be a maintenance
nightmare because the format changes frequently.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@312851 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
That is, instead of "1 error generated", we now say "1 error generated
when compiling for sm_35".
This (partially) solves a usability foogtun wherein e.g. users call a
function that's only defined on sm_60 when compiling for sm_35, and they
get an unhelpful error message.
Reviewers: tra
Subscribers: sanjoy, cfe-commits
Differential Revision: https://reviews.llvm.org/D37548
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@312736 91177308-0d34-0410-b5e6-96231b3b80d8
Extend the -fmodule-file option to support the [<name>=]<file> value format.
If the name is omitted, then the old semantics is preserved (the module file
is loaded whether needed or not). If the name is specified, then the mapping
is treated as just another prebuilt module search mechanism, similar to
-fprebuilt-module-path, and the module file is only loaded if actually used
(e.g., via import). With one exception: this mapping also overrides module
file references embedded in other modules (which can be useful if module files
are moved/renamed as often happens during remote compilation).
This override semantics requires some extra work: we now store the module name
in addition to the file name in the serialized AST representation.
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D35020
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@312220 91177308-0d34-0410-b5e6-96231b3b80d8
Extend the -fmodule-file option to support the [<name>=]<file> value format.
If the name is omitted, then the old semantics is preserved (the module file
is loaded whether needed or not). If the name is specified, then the mapping
is treated as just another prebuilt module search mechanism, similar to
-fprebuilt-module-path, and the module file is only loaded if actually used
(e.g., via import). With one exception: this mapping also overrides module
file references embedded in other modules (which can be useful if module files
are moved/renamed as often happens during remote compilation).
This override semantics requires some extra work: we now store the module name
in addition to the file name in the serialized AST representation.
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D35020
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@312105 91177308-0d34-0410-b5e6-96231b3b80d8
If a TS module name has more than one component (e.g., foo.bar) then we
erroneously activated the submodule semantics when encountering a module
declaration in the module implementation unit (e.g., 'module foo.bar;').
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D35678
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@312007 91177308-0d34-0410-b5e6-96231b3b80d8
This helps some tools that do things based on the output's extension.
For example, we got reports from users on Windows that have a tool that scan a
build output dir (but skip .obj files). The tool would keep the "foo.obj-12345"
file open, and then when clang tried to rename the temp file to the final
output filename, that would fail. By making the tempfile end in ".obj.tmp",
tools like this could now have a rule to ignore .tmp files.
This is a less ambitious reland of https://reviews.llvm.org/D36238https://reviews.llvm.org/D36413
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@310376 91177308-0d34-0410-b5e6-96231b3b80d8
It generates MODULE-XXXXXXXXXXXX-%%%%%%%%.pcm, then GlobalModuleIndex.cpp is confused with the suffix ".pcm"
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@310030 91177308-0d34-0410-b5e6-96231b3b80d8
This helps some tools that do things based on the output's extension.
For example, we got reports from users on Windows that have a tool that scan a
build output dir (but skip .obj files). The tool would keep the "foo.obj-12345"
file open, and then when clang tried to rename the temp file to the final
output filename, that would fail. By making the tempfile end in ".obj", tools
like this will now skip the temp files as well.
https://reviews.llvm.org/D36238
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@309984 91177308-0d34-0410-b5e6-96231b3b80d8
We use this when running a preprocessor-only action on an AST file in order to
avoid paying the runtime cost of loading the extra information.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@306760 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: Device offloading requires the specification of an additional flag containing the triple of the //other// architecture the code is being compiled on if such an architecture exists. If compiling for the host, the auxiliary triple flag will contain the triple describing the device and vice versa.
Reviewers: arpith-jacob, sfantao, caomhin, carlo.bertolli, ABataev, Hahnfeld, jlebar, hfinkel, tstellar
Reviewed By: Hahnfeld
Subscribers: rengolin, cfe-commits
Differential Revision: https://reviews.llvm.org/D29339
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@306689 91177308-0d34-0410-b5e6-96231b3b80d8
If specified, when preprocessing, the contents of imported .pcm files will be
included in preprocessed output. The resulting preprocessed file can then be
compiled standalone without the module sources or .pcm files.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@305116 91177308-0d34-0410-b5e6-96231b3b80d8
as part of a compilation.
This is intended for two purposes:
1) Writing self-contained test cases for modules: we can now write a single
source file test that builds some number of module files on the side and
imports them.
2) Debugging / test case reduction. A single-source testcase is much more
amenable to reduction, compared to a VFS tarball or .pcm files.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@305101 91177308-0d34-0410-b5e6-96231b3b80d8
action to the general FrontendAction infrastructure.
This permits applying -E, -ast-dump, -fsyntax-only, and so on to a module map
compilation. (The -E form is not currently especially useful yet as there's no
good way to take the output and use it to actually build a module.)
In order to support this, -cc1 now accepts -x <lang>-module-map in all cases
where it accepts -x <lang> for a language we can parse (not ir/ast). And for
uniformity, we also accept -x <lang>-header for all such languages (we used
to reject for cuda and renderscript), and -x <lang>-cpp-output for all such
languages (we used to reject for c, cl, and renderscript).
(None of these new alternatives are accepted by the driver yet, so no
user-visible changes.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@301610 91177308-0d34-0410-b5e6-96231b3b80d8
If a file search involves a header map, suppress
-Wnonportable-include-path. It's firing lots of false positives for
framework authors internally, and it's not trivial to fix.
Consider a framework called "Foo" with a main (installed) framework header
"Foo/Foo.h". It's atypical for "Foo.h" to actually live inside a
directory called "Foo" in the source repository. Instead, the
build system generates a header map while building the framework.
If Foo.h lives at the top-level of the source repository (common), and
the git repo is called ssh://some.url/foo.git, then the header map will
have something like:
Foo/Foo.h -> /Users/myname/code/foo/Foo.h
where "/Users/myname/code/foo" is the clone of ssh://some.url/foo.git.
After #import <Foo/Foo.h>, the current implementation of
-Wnonportable-include-path will falsely assume that Foo.h was found in a
nonportable way, because of the name of the git clone (.../foo/Foo.h).
However, that directory name was not involved in the header search at
all.
This commit adds an extra parameter to Preprocessor::LookupFile and
HeaderSearch::LookupFile to track if the search used a header map,
making it easy to suppress the warning. Longer term, once we find a way
to avoid the false positive, we should turn the warning back on.
rdar://problem/28863903
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@301592 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
When a PCH is included via -include-pch, clang should treat the
current TU as dependent on the sourcefile that the PCH was generated from.
This is currently _partly_ accomplished by InitializePreprocessor calling
AddImplicitIncludePCH to synthesize an implicit #include of the sourcefile,
into the preprocessor's Predefines buffer.
For FrontendActions such as PreprocessOnlyAction (which is, curiously, what the
driver winds up running one of in response to a plain clang -M) this is
sufficient: the preprocessor cranks over its Predefines and emits a dependency
reference to the initial sourcefile.
For other FrontendActions (for example -emit-obj or -fsyntax-only) the
Predefines buffer is reset to the suggested predefines buffer from the PCH, so
the dependency edge is lost. The result is that clang emits a .d file in those
cases that lacks a reference to the .h file responsible for the input (and in
Swift's case, our .swiftdeps file winds up not including a reference to the
source file for a PCH bridging header.)
This patch fixes the problem by taking a different tack: ignoring the
Predefines buffer (which seems a bit like a hack anyways) and directly
attaching the CompilerInstance's DependencyCollectors (and legacy
DependencyFileGenerator) to the ASTReader for the external AST.
This approach is similar to the one chosen in earlier consultation with Bruno
and Ben, and I think it's the least-bad solution, given several options.
Reviewers: bruno, benlangmuir, doug.gregor
Reviewed By: bruno, doug.gregor
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D31378
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299009 91177308-0d34-0410-b5e6-96231b3b80d8
and into TargetInfo::adjust so that it gets called in more places
throughout the compiler (AST serialization in particular).
Should fix PPC modules after removing of faltivec.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@298487 91177308-0d34-0410-b5e6-96231b3b80d8
The alias was only ever used on darwin and had some issues there,
and isn't used in practice much. Also fixes a problem with -mno-altivec
not turning off -maltivec.
Also add a diagnostic for faltivec/fno-altivec that directs users to use
maltivec options and include the altivec.h file explicitly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@298449 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r298185, effectively reapplying r298165, after fixing the
new unit tests (PR32338). The memory buffer generator doesn't null-terminate
the MemoryBuffer it creates; this version of the commit informs getMemBuffer
about that to avoid the assert.
Original commit message follows:
----
Clang's internal build system for implicit modules uses lock files to
ensure that after a process writes a PCM it will read the same one back
in (without contention from other -cc1 commands). Since PCMs are read
from disk repeatedly while invalidating, building, and importing, the
lock is not released quickly. Furthermore, the LockFileManager is not
robust in every environment. Other -cc1 commands can stall until
timeout (after about eight minutes).
This commit changes the lock file from being necessary for correctness
to a (possibly dubious) performance hack. The remaining benefit is to
reduce duplicate work in competing -cc1 commands which depend on the
same module. Follow-up commits will change the internal build system to
continue after a timeout, and reduce the timeout. Perhaps we should
reconsider blocking at all.
This also fixes a use-after-free, when one part of a compilation
validates a PCM and starts using it, and another tries to swap out the
PCM for something new.
The PCMCache is a new type called MemoryBufferCache, which saves memory
buffers based on their filename. Its ownership is shared by the
CompilerInstance and ModuleManager.
- The ModuleManager stores PCMs there that it loads from disk, never
touching the disk if the cache is hot.
- When modules fail to validate, they're removed from the cache.
- When a CompilerInstance is spawned to build a new module, each
already-loaded PCM is assumed to be valid, and is frozen to avoid
the use-after-free.
- Any newly-built module is written directly to the cache to avoid the
round-trip to the filesystem, making lock files unnecessary for
correctness.
Original patch by Manman Ren; most testcases by Adrian Prantl!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@298278 91177308-0d34-0410-b5e6-96231b3b80d8
Duncan's r298165 introduced the PCMCache mechanism, which guarantees
that locks aren't necessary anymore for correctness but only for
performance, by avoiding building it twice when possible.
Change the logic to avoid an error but actually build the module in case
the timeout happens. Instead of an error, still emit a remark for
debugging purposes.
rdar://problem/30297862
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@298175 91177308-0d34-0410-b5e6-96231b3b80d8
Clang's internal build system for implicit modules uses lock files to
ensure that after a process writes a PCM it will read the same one back
in (without contention from other -cc1 commands). Since PCMs are read
from disk repeatedly while invalidating, building, and importing, the
lock is not released quickly. Furthermore, the LockFileManager is not
robust in every environment. Other -cc1 commands can stall until
timeout (after about eight minutes).
This commit changes the lock file from being necessary for correctness
to a (possibly dubious) performance hack. The remaining benefit is to
reduce duplicate work in competing -cc1 commands which depend on the
same module. Follow-up commits will change the internal build system to
continue after a timeout, and reduce the timeout. Perhaps we should
reconsider blocking at all.
This also fixes a use-after-free, when one part of a compilation
validates a PCM and starts using it, and another tries to swap out the
PCM for something new.
The PCMCache is a new type called MemoryBufferCache, which saves memory
buffers based on their filename. Its ownership is shared by the
CompilerInstance and ModuleManager.
- The ModuleManager stores PCMs there that it loads from disk, never
touching the disk if the cache is hot.
- When modules fail to validate, they're removed from the cache.
- When a CompilerInstance is spawned to build a new module, each
already-loaded PCM is assumed to be valid, and is frozen to avoid
the use-after-free.
- Any newly-built module is written directly to the cache to avoid the
round-trip to the filesystem, making lock files unnecessary for
correctness.
Original patch by Manman Ren; most testcases by Adrian Prantl!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@298165 91177308-0d34-0410-b5e6-96231b3b80d8
Change ASTFileSignature from a random 32-bit number to the hash of the
PCM content.
- Move definition ASTFileSignature to Basic/Module.h so Module and
ASTSourceDescriptor can use it.
- Change the signature from uint64_t to std::array<uint32_t,5>.
- Stop using (saving/reading) the size and modification time of PCM
files when there is a valid SIGNATURE.
- Add UNHASHED_CONTROL_BLOCK, and use it to store the SIGNATURE record
and other records that shouldn't affect the hash. Because implicit
modules reuses the same file for multiple levels of -Werror, this
includes DIAGNOSTIC_OPTIONS and DIAG_PRAGMA_MAPPINGS.
This helps to solve a PCH + implicit Modules dependency issue: PCH files
are handled by the external build system, whereas implicit modules are
handled by internal compiler build system. This prevents invalidating a
PCH when the compiler overwrites a PCM file with the same content
(modulo the diagnostic differences).
Design and original patch by Manman Ren!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@297655 91177308-0d34-0410-b5e6-96231b3b80d8
Initialize fields directly in header. Note that the ModuleManager field is an
IntrusiveRefCntPtr, so there's no need for explicit initialization.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@293863 91177308-0d34-0410-b5e6-96231b3b80d8
Aleksey Shlypanikov pointed out my mistake in migrating an explicit
unique_ptr to auto - I was expecting the function returned a unique_ptr,
but instead it returned a raw pointer - introducing a leak.
Thanks Aleksey!
This reapplies r291184, reverted in r291249.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291270 91177308-0d34-0410-b5e6-96231b3b80d8
Merge all VFS mapped files inside -ivfsoverlay inputs into the vfs
overlay provided by the crash reproducer. This is the last missing piece
to allow crash reproducers to fully work with user frameworks; when
combined with headermaps, it allows clang to find additional frameworks.
rdar://problem/27913709
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290326 91177308-0d34-0410-b5e6-96231b3b80d8
Bruno Cardoso Lopes