r276653 suppressed the pragma once warning when generating a PCH file.
This patch extends that to any main file for which clang is told (with
the -x option) that it's a header file. It will also suppress the
warning "#include_next in primary source file".
Differential Revision: http://reviews.llvm.org/D25989
llvm-svn: 285295
All values are returned by a method as size_t, and subsequently passed
to functions taking a size_t, or used where a size_t is also valid.
Better still, two loops (which had an unsigned), can be replaced by
a range-based for loop.
Differential Revision: http://reviews.llvm.org/D25939
llvm-svn: 285182
Differential Revision: http://reviews.llvm.org/D19843
Corresponding LLVM change: http://reviews.llvm.org/D19842
Re-commit after addressing issues with of generating too many warnings for Windows and asan test failures.
Patch by Eric Niebler
llvm-svn: 272562
If we are processing a #include from a module build, we should treat it
as a system header if we're building a system module. Passing an optional
flag to HeaderSearch::LookupFile.
Before this, the testing case will crash when accessing a freed FileEntry.
rdar://26214027
llvm-svn: 269730
and we fall back to textual inclusion, don't require the module as a whole to
be marked available; it's OK if some other file in the same module is missing,
just as it would be if the header were explicitly marked textual.
llvm-svn: 266113
This reverts commit r261780. It turns out the original code was just
fine. An overload for ltrim which takes char was added but the Doxygen
docs haven't seemed to pick it up.
llvm-svn: 261784
option. Previously these options could both be used to specify that you were
compiling the implementation file of a module, with a different set of minor
bugs in each case.
This change removes -fmodule-implementation-of, and instead tracks a flag to
determine whether we're currently building a module. -fmodule-name now behaves
the same way that -fmodule-implementation-of previously did.
llvm-svn: 261372
r260925 introduced a version of the *trim methods which is preferable
when trimming a single kind of character. Update all users in clang.
llvm-svn: 260927
While this won't help fix things like the bug that r260219 addressed, it
seems like good tidy up to have anyway.
(it might be nice if "makeArrayRef" always produced a MutableArrayRef &
let it decay to an ArrayRef when needed - then I'd use that for the
MutableArrayRefs in this patch)
If we had std::dynarray I'd use that instead of unique_ptr+size_t,
ideally (but then it'd have to be threaded down through the Preprocessor
all the way - no idea how painful that would be)
llvm-svn: 260246
This works around existing system headers which unconditionally
redefine these macros.
This is reasonably safe to do because we used to warn about it anyway
(outside of system headers). Continue to warn if the redefinition
would have changed the expansion. Still permit redefinition if the
macro is explicitly #undef'ed first.
rdar://23788307
llvm-svn: 255311
Summary:
If a module was unavailable (either a missing requirement on the module
being imported, or a missing file anywhere in the top-level module (and
not dominated by an unsatisfied `requires`)), we would silently treat
inclusions as textual. This would cause all manner of crazy and
confusing errors (and would also silently "work" sometimes, making the
problem difficult to track down).
I'm really not a fan of the `M->isAvailable(getLangOpts(), getTargetInfo(),
Requirement, MissingHeader)` function; it seems to do too many things at
once, but for now I've done things in a sort of awkward way.
The changes to test/Modules/Inputs/declare-use/module.map
were necessitated because the thing that was meant to be tested there
(introduced in r197805) was predicated on silently falling back to textual
inclusion, which we no longer do.
The changes to test/Modules/Inputs/macro-reexport/module.modulemap
are just an overlooked missing header that seems to have been missing since
this code was committed (r213922), which is now caught.
Reviewers: rsmith, benlangmuir, djasper
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D10423
llvm-svn: 245228
re-entering a modular header.
When we do the include guard check, we're in the visibility state for the file
with the #include; the include guard may not be visible there, but we don't
actually need it to be: if we've already parsed the submodule we're considering
entering, it's always safe to skip it.
llvm-svn: 241135
Introduce the clang pragmas "assume_nonnull begin" and "assume_nonnull
end" in which we make default assumptions about the nullability of many
unannotated pointers:
- Single-level pointers are inferred to __nonnull
- NSError** in a (function or method) parameter list is inferred to
NSError * __nullable * __nullable.
- CFErrorRef * in a (function or method) parameter list is inferred
to CFErrorRef __nullable * __nullable.
- Other multi-level pointers are never inferred to anything.
Implements rdar://problem/19191042.
llvm-svn: 240156
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.
llvm-svn: 239789
glibc's headers use __need_* macros to selectively export parts of themselves
to each other. This requires us to enter those files repeatedly when building
a glibc module.
This can be unreverted once we have a better mechanism to deal with that
non-modular aspect of glibc (possibly some way to mark a header as "textual if
this macro is defined").
llvm-svn: 237718
enter it more than once, even if it doesn't have #include guards -- we already
know that it is intended to have the same effect every time it's included, and
it's already had that effect. This particularly helps with local submodule
visibility builds, where the include guard macro may not be visible in the
includer, but will become visible the moment we enter the included file.
llvm-svn: 237609
It has no place there; it's not a property of the Module, and it makes
restoring the visibility set when we leave a submodule more difficult.
llvm-svn: 236300
Modules builds fundamentally have a non-linear macro history. In the interest
of better source fidelity, represent the macro definition information
faithfully: we have a linear macro directive history within each module, and at
any point we have a unique "latest" local macro directive and a collection of
visible imported directives. This also removes the attendent complexity of
attempting to create a correct MacroDirective history (which we got wrong
in the general case).
No functionality change intended.
llvm-svn: 236176
the active module macros at the point of definition, rather than reconstructing
it from the macro history. No functionality change intended.
llvm-svn: 235941
Erik Verbruggen