289 Commits

Author SHA1 Message Date
Mitch Phillips
074f6fd61d Revert "[C++20][Modules] Introduce an implementation module."
This reverts commit c6e9823724ef6bdfee262289ee34d162db436af0.

Reason: Broke the ASan buildbots, see https://reviews.llvm.org/D126959
(the original phabricator review) for more info.
2023-03-27 05:01:53 -07:00
Mitch Phillips
5ca710ab14 Revert "Silence unused variable warning in NDEBUG builds"
This reverts commit 8c7c1f11ffaacf762e612c65440fd2cbb58ee426.

Reason: Dependent change https://reviews.llvm.org/D126959 broke the ASan
buildbots. See that phabricator review for more comments.
2023-03-27 05:01:53 -07:00
Benjamin Kramer
8c7c1f11ff Silence unused variable warning in NDEBUG builds
I usually would fold this into the assert, but the comment there
suggests side effects. NFC.

ModuleMap.cpp:938:9: error: unused variable 'MainFile' [-Werror,-Wunused-variable]
  auto *MainFile = SourceMgr.getFileEntryForID(SourceMgr.getMainFileID());
2023-03-23 14:41:03 +01:00
Iain Sandoe
c6e9823724 [C++20][Modules] Introduce an implementation module.
We need to be able to distinguish individual TUs from the same module in cases
where TU-local entities either need to be hidden (or, for some cases of ADL in
template instantiation, need to be detected as exposures).

This creates a module type for the implementation which implicitly imports its
primary module interface per C++20:
[module.unit/8] 'A module-declaration that contains neither an export-keyword
nor a module-partition implicitly imports the primary module interface unit of
the module as if by a module-import-declaration.

Implementation modules are never serialized (-emit-module-interface for an
implementation unit is diagnosed and rejected).

Differential Revision: https://reviews.llvm.org/D126959
2023-03-23 12:47:44 +00:00
Juergen Ributzka
29e2a4eff8 [clang] Unconditionally add autolink hints for frameworks.
Clang infers framework autolink hints when parsing a modulemap. In order to do
so, it checks if the module is a framework and if there is a framework binary
or TBD file in the SDK. Only when Clang finds the filei, then the autolink hint
is added to the module metadata.

During a project build many clang processes perform this check, which causes
many stat calls - even for modules/frameworks that are not even used.

The linker is already resilient to non-existing framework links that come from
the autolink metadata, so there is no need for Clang to do this check.

Instead the autolink hints are now added unconditionally and the linker only
needs to do the check once. This reduces the overall number of stat calls.

This fixes rdar://106578342.

Differential Revision: https://reviews.llvm.org/D146255
2023-03-16 15:31:17 -07:00
Chuanqi Xu
bf52ead24c [C++20] [Modules] Support to export declarations in language linkage
Close https://github.com/llvm/llvm-project/issues/60405

See the discussion in the above link for the background.

What the patch does:
- Rename `Module::ModuleKind::GlobalModuleFragment` to
  `Module::ModuleKind::ExplicitGlobalModuleFragment`.
- Add another module kind `ImplicitGlobalModuleFragment` to
  `ModuleKind`.
- Create an implicit global module fragment for the language linkage
  declarations inside a module purview.
    - If the language linkage lives inside the scope of an export decl,
      the created modules is marked as exported to outer modules.
- In fact, Sema will only create at most 2 implicit global module
  fragments to avoid creating a lot of unnecessary modules in the edging
case.

Reviewed By: iains

Differential Revision: https://reviews.llvm.org/D144367
2023-03-03 10:31:48 +08:00
James Y Knight
ab0116e2f0 [Clang] Improve error message for violations of -fmodules-decluse.
Now it reports the name of the indirectly-used module which is
missing.

Reviewed By: ChuanqiXu

Differential Revision: https://reviews.llvm.org/D142925
2023-01-31 09:57:23 -05:00
Richard Howell
75fbb5d223 [clang][nfc] refactor Module::Header to use OptionalFileEntryRef
Refactor the `Module::Header` class to use an `OptionalFileEntryRef`
instead of a `FileEntry*`. This is preparation for refactoring the
`TopHeaderNames` to use `FileEntryRef` so that we preserve the
lookup path of the headers when serializing.

This is mostly based on https://reviews.llvm.org/D90497

Reviewed By: jansvoboda11

Differential Revision: https://reviews.llvm.org/D142113
2023-01-20 07:23:11 -08:00
Kazu Hirata
6ad0788c33 [clang] Use std::optional instead of llvm::Optional (NFC)
This patch replaces (llvm::|)Optional< with std::optional<.  I'll post
a separate patch to remove #include "llvm/ADT/Optional.h".

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2023-01-14 12:31:01 -08:00
Kazu Hirata
a1580d7b59 [clang] Add #include <optional> (NFC)
This patch adds #include <optional> to those files containing
llvm::Optional<...> or Optional<...>.

I'll post a separate patch to actually replace llvm::Optional with
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2023-01-14 11:07:21 -08:00
Benjamin Kramer
854c10f8d1 [Clang] Prepare for llvm::Optional becoming std::optional.
The needed tweaks are mostly trivial, the one nasty bit is Clang's usage
of OptionalStorage. To keep this working old Optional stays around as
clang::CustomizableOptional, with the default Storage removed.
Optional<File/DirectoryEntryRef> is replaced with a typedef.

I tested this with GCC 7.5, the oldest supported GCC I had around.

Differential Revision: https://reviews.llvm.org/D140332
2022-12-20 00:41:40 +01:00
Krzysztof Parzyszek
205c0589f9 Revert "[clang] Convert OptionalFileEntryRefDegradesToFileEntryPtr to std::optional"
This reverts commit 8f0df9f3bbc6d7f3d5cbfd955c5ee4404c53a75d.

The Optional*RefDegradesTo*EntryPtr types want to keep the same size as
the underlying type, which std::optional doesn't guarantee. For use with
llvm::Optional, they define their own storage class, and there is no way
to do that in std::optional.

On top of that, that commit broke builds with older GCCs, where
std::optional was not trivially copyable (static_assert in the clang
sources was failing).
2022-12-18 11:23:54 -08:00
Krzysztof Parzyszek
8f0df9f3bb [clang] Convert OptionalFileEntryRefDegradesToFileEntryPtr to std::optional 2022-12-17 15:24:14 -08:00
Fangrui Song
53e5cd4d3e llvm::Optional::value => operator*/operator->
std::optional::value() has undesired exception checking semantics and is
unavailable in older Xcode (see _LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS). The
call sites block std::optional migration.

This makes `ninja clang` work in the absence of llvm::Optional::value.
2022-12-17 06:37:59 +00:00
Kazu Hirata
f7dffc28b3 Don't include None.h (NFC)
I've converted all known uses of None to std::nullopt, so we no longer
need to include None.h.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-12-10 11:24:26 -08:00
Kazu Hirata
5891420e68 [clang] Use std::nullopt instead of None (NFC)
This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated.  The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-12-03 11:54:46 -08:00
Jan Svoboda
935a07ed21 [clang][deps][lex] Avoid canonicalization of remapped framework directories
In D134923, the scanner introduced canonicalization of framework directories when reporting module map paths in order to increase module sharing. However, if we canonicalize framework directory that plays a role in a VFS remapping, and later try to use that module map to build the module, header lookup can fail. This happens when the module headers are remapped using the original framework path.

This patch fixes that. The implementation relies on the fact that the chain of directories in VFS remapping are assigned `DirectoryEntry` objects distinct from their on-disk counterparts. If we detect that case, we avoid the canonicalization.

Reviewed By: benlangmuir

Differential Revision: https://reviews.llvm.org/D135841
2022-12-01 19:59:54 -08:00
Chuanqi Xu
4a7be42d92 [C++20] [Modules] Remove unmaintained Header Module
Currently there is a -emit-header-module mode, which can combine several
headers together as a module interface. However, this breaks our
assumption (for standard c++ modules) about module interface. The module
interface should come from a module interface unit. And if it is a
header, it should be a header unit. And currently we have no ideas to
combine several headers together.

So I think this mode is an experimental one and it is not maintained and
it is not used. So it will be better to remove them.

Reviewed By: Bigcheese, dblaikie, bruno

Differential Revision: https://reviews.llvm.org/D137609
2022-11-18 10:39:33 +08:00
Chuanqi Xu
9044226ba2 [NFC] [C++20] [Modules] Remove unused Global Module Fragment variables/arguments 2022-11-15 11:51:13 +08:00
Jan Svoboda
5865476879 [clang][modules] Fix handling of ModuleHeaderRole::ExcludedHeader
This is a follow-up to D134224. The original patch added new `ExcludedHeader` enumerator to `ModuleMap::ModuleHeaderRole` and started associating headers with the modules they were excluded from. This was necessary to consider their module maps as "affecting" in certain situations and in turn serialize them into the PCM.

The association of the header and module needs to be handled when deserializing the PCM as well, though. This patch fixes a potential assertion failure and a regression. This essentially reverts parts of feb54b6ded123f8118fdc20620d3f657dfeab485.

Reviewed By: Bigcheese

Differential Revision: https://reviews.llvm.org/D135381
2022-10-06 16:20:24 -07:00
Ben Langmuir
074fcec1ea [clang][deps] Canonicalize module map path
When dep-scanning, canonicalize the module map path as much as we can.
This avoids unnecessarily needing to build multiple versions of a module
due to symlinks or case-insensitive file paths.

Despite the name `tryGetRealPathName`, the previous implementation did
not actually return the realpath most of the time, and indeed it would
be incorrect to do so since the realpath could be outside the module
directory, which would have broken finding headers relative to the
module.

Instead, use a canonicalization that is specific to the needs of
modulemap files (canonicalize the directory separately from the
filename).

Differential Revision: https://reviews.llvm.org/D134923
2022-10-05 15:42:38 -07:00
Ben Langmuir
5ea78c4113 [clang] Update ModuleMap::getModuleMapFile* to use FileEntryRef
Update SourceManager::ContentCache::OrigEntry to keep the original
FileEntryRef, and use that to enable ModuleMap::getModuleMapFile* to
return the original FileEntryRef. This change should be NFC for
most users of SourceManager::ContentCache, but it could affect behaviour
for users of getNameAsRequested such as in compileModuleImpl. I have not
found a way to detect that difference without additional functional
changes, other than incidental cases like changes from / to \ on
Windows so there is no new test.

Differential Revision: https://reviews.llvm.org/D135220
2022-10-05 13:12:43 -07:00
Jan Svoboda
f35230ae0a [clang][modules][deps] Report modulemaps describing excluded headers
Module map files describing excluded headers do affect compilation. Track them in the compiler, serialize them into the PCM file and report them in the scanner.

Depends on D134222.

Reviewed By: Bigcheese

Differential Revision: https://reviews.llvm.org/D134224
2022-09-22 12:36:05 -07:00
Ian Anderson
260fb2bc3f [clang][modules] Don't hard code [no_undeclared_includes] for the Darwin module
The Darwin module has specified [no_undeclared_includes] for at least five years now, there's no need to hard code it in the compiler.

Reviewed By: ributzka, Bigcheese

Differential Revision: https://reviews.llvm.org/D132971
2022-08-30 14:57:15 -07:00
Fangrui Song
3f18f7c007 [clang] LLVM_FALLTHROUGH => [[fallthrough]]. NFC
With C++17 there is no Clang pedantic warning or MSVC C5051.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D131346
2022-08-08 09:12:46 -07:00
Kazu Hirata
70257fab68 Use any_of (NFC) 2022-07-22 01:05:17 -07:00
Kazu Hirata
cb2c8f694d [clang] Use value instead of getValue (NFC) 2022-07-13 23:39:33 -07:00
Kazu Hirata
3b7c3a654c Revert "Don't use Optional::hasValue (NFC)"
This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.
2022-06-25 11:56:50 -07:00
Kazu Hirata
aa8feeefd3 Don't use Optional::hasValue (NFC) 2022-06-25 11:55:57 -07:00
Jan Svoboda
99cfccdcb3 [clang][lex] NFCI: Use FileEntryRef in ModuleMap::diagnoseHeaderInclusion()
This patch removes uses of the deprecated `DirectoryEntry::getName()` from the `ModuleMap::diagnoseHeaderInclusion()` function by using `{File,Directory}EntryRef` instead.

Reviewed By: bnbarham

Differential Revision: https://reviews.llvm.org/D123856
2022-04-20 20:27:13 +02:00
Iain Sandoe
6c0e60e884 [C++20][Modules][HU 1/5] Introduce header units as a module type.
This is the first in a series of patches that introduce C++20 importable
header units.

These differ from clang header modules in that:
 (a) they are identifiable by an internal name
 (b) they represent the top level source for a single header - although
     that might include or import other headers.

We name importable header units with the path by which they are specified
(although that need not be the absolute path for the file).

So "foo/bar.h" would have a name "foo/bar.h".  Header units are made a
separate module type so that we can deal with diagnosing places where they
are permitted but a named module is not.

Differential Revision: https://reviews.llvm.org/D121095
2022-03-25 09:17:14 +00:00
Dawid Jurczak
d813116c9d [NFC][Lexer] Remove getLangOpts function from Lexer
Given that there is only one external user of Lexer::getLangOpts
we can remove getter entirely without much pain.

Differential Revision: https://reviews.llvm.org/D120404
2022-03-02 11:17:05 +01:00
Adam Czachorowski
8f4ea36bfe [clang] Improve laziness of resolving module map headers.
clang has support for lazy headers in module maps - if size and/or
modtime and provided in the cppmap file, headers are only resolved when
an include directive for a file with that size/modtime is encoutered.

Before this change, the lazy resolution was all-or-nothing per module.
That means as soon as even one file in that module potentially matched
an include, all lazy files in that module were resolved. With this
change, only files with matching size/modtime will be resolved.

The goal is to avoid unnecessary stat() calls on non-included files,
which is especially valuable on networked file systems, with higher
latency.

Differential Revision: https://reviews.llvm.org/D120569
2022-03-01 15:56:23 +01:00
Chuanqi Xu
e587372f85 [C++20] [Module] Support extern C/C++ semantics
According to [module.unit]p7.2.3, a declaration within a linkage-specification
should be attached to the global module.
This let user to forward declare types across modules.

Reviewed by: rsmith, aaron.ballman

Differential Revision: https://reviews.llvm.org/D110215
2021-12-08 13:29:16 +08:00
Benjamin Kramer
8adb6d6de2 [clang] Use llvm::reverse. NFCI. 2021-11-07 14:24:33 +01:00
Kazu Hirata
7cc8fa2dd2 Use llvm::is_contained (NFC) 2021-10-24 09:32:57 -07:00
Volodymyr Sapsai
d0e7bdc208 [modules] Make a module map referenced by a system map a system one too.
Mimic the behavior of including headers where a system includer makes an
includee a system header too.

rdar://84049469

Differential Revision: https://reviews.llvm.org/D111476
2021-10-15 12:46:51 -07:00
Kazu Hirata
e567f37dab [clang] Use llvm::is_contained (NFC) 2021-10-13 20:41:55 -07:00
Corentin Jabot
601102d282 Cleanup identifier parsing; NFC
Rename methods to clearly signal when they only deal with ASCII,
simplify the parsing of identifier, and use start/continue instead of
head/body for consistency with Unicode terminology.
2021-09-14 09:12:22 -04:00
Simon Tatham
21401a7262 [clang] Introduce SourceLocation::[U]IntTy typedefs.
This is part of a patch series working towards the ability to make
SourceLocation into a 64-bit type to handle larger translation units.

NFC: this patch introduces typedefs for the integer type used by
SourceLocation and makes all the boring changes to use the typedefs
everywhere, but for the moment, they are unconditionally defined to
uint32_t.

Patch originally by Mikhail Maltsev.

Reviewed By: tmatheson

Differential Revision: https://reviews.llvm.org/D105492
2021-07-21 10:45:46 +01:00
Michael Spencer
d3676d4b66 [clang][modules] Build inferred modules
This patch enables explicitly building inferred modules.

Effectively a cherry-pick of https://github.com/apple/llvm-project/pull/699 authored by @Bigcheese with libclang and dependency scanner changes omitted.

Contains the following changes:

1. [Clang] Fix the header paths in clang::Module for inferred modules.
  * The UmbrellaAsWritten and NameAsWritten fields in clang::Module are a lie for framework modules. For those they actually are the path to the header or umbrella relative to the clang::Module::Directory.
  * The exception to this case is for inferred modules. Here it actually is the name as written, because we print out the module and read it back in when implicitly building modules. This causes a problem when explicitly building an inferred module, as we skip the printing out step.
  * In order to fix this issue this patch adds a new field for the path we want to use in getInputBufferForModule. It also makes NameAsWritten actually be the name written in the module map file (or that would be, in the case of an inferred module).

2. [Clang] Allow explicitly building an inferred module.
  * Building the actual module still fails, but make sure it fails for the right reason.

Split from D100934.

Reviewed By: dexonsmith

Differential Revision: https://reviews.llvm.org/D102491
2021-05-17 10:40:51 +02:00
Duncan P. N. Exon Smith
64d8c7818d Revert "Module: Use FileEntryRef and DirectoryEntryRef in Umbrella, Header, and DirectoryName, NFC"
This (mostly) reverts 32c501dd88b62787d3a5ffda7aabcf4650dbe3cd.  Hit a
case where this causes a behaviour change, perhaps the same root cause
that triggered the revert of a40db5502b2515a6f2f1676b5d7a655ae0f41179 in
7799ef7121aa7d59f4bd95cdf70035de724ead6f.

(The API changes in DirectoryEntry.h have NOT been reverted as a number
of subsequent commits depend on those.)

https://reviews.llvm.org/D90497#2582166
2021-02-23 09:57:28 -08:00
Nico Weber
7799ef7121 Revert "Lex: Migrate HeaderSearch::LoadedModuleMaps to FileEntryRef"
This reverts commit a40db5502b2515a6f2f1676b5d7a655ae0f41179.
and follow-up d636b881bb9214938973098a012fad453082c444

Somewhat speculative, likely broke check-clang on Windows:
https://reviews.llvm.org/D92975#2453482
2020-12-14 22:05:08 -05:00
Duncan P. N. Exon Smith
a40db5502b Lex: Migrate HeaderSearch::LoadedModuleMaps to FileEntryRef
Migrate `HeaderSearch::LoadedModuleMaps` and a number of APIs over to
`FileEntryRef`. This should have no functionality change. Note that two
`FileEntryRef`s hash the same if they point at the same `FileEntry`.

Differential Revision: https://reviews.llvm.org/D92975
2020-12-14 14:35:11 -08:00
Duncan P. N. Exon Smith
32c501dd88 Module: Use FileEntryRef and DirectoryEntryRef in Umbrella, Header, and DirectoryName, NFC
Push `FileEntryRef` and `DirectoryEntryRef` further, using it them
`Module::Umbrella`, `Module::Header::Entry`, and
`Module::DirectoryName::Entry`.

- Add `DirectoryEntryRef::operator const DirectoryEntry *` and
  `OptionalDirectoryEntryRefDegradesToDirectoryEntryPtr`, to get the
  same "degrades to `DirectoryEntry*` behaviour `FileEntryRef` enjoys
  (this avoids a bunch of churn in various clang tools).
- Fix the `DirectoryEntryRef` constructor from `MapEntry` to take it by
  `const&`.

Note that we cannot get rid of the `...AsWritten` names leveraging the
new classes, since these need to be as written in the `ModuleMap` file
and the module directory path is preprended for the lookup in the
`FileManager`.

Differential Revision: https://reviews.llvm.org/D90497
2020-12-02 14:07:23 -08:00
Duncan P. N. Exon Smith
f85db7f7ba Lex: Update Module::findHeader to return FileEntryRef, NFC
Update `Module::findHeader` to return `Optional<FileEntryRef>` and
fix its one caller.

Differential Revision: https://reviews.llvm.org/D90485
2020-11-30 17:13:03 -08:00
Duncan P. N. Exon Smith
6e73cfa836 Basic: Change Module::Umbrella to a PointerUnion, NFC
Change `Module::Umbrella` from a `const void *` to a `PointerUnion` of
`FileEntry` and `DirectoryEntry`. We can drop the `HasUmbrellaDir` bit
(since `PointerUnion` includes that).

This change makes it safer to update to `FileEntryRef` and
`DirectoryEntryRef` in a future patch.

Differential Revision: https://reviews.llvm.org/D90481
2020-11-04 16:19:39 -05:00
Duncan P. N. Exon Smith
b03ae74319 clang/Lex: Stop using SourceManager::getBuffer
Update clang/lib/Lex to stop relying on a `MemoryBuffer*`, using the
`MemoryBufferRef` from `getBufferOrNone` since both locations had logic
for checking validity of the buffer. There's potentially a functionality
change, since the logic was wrong (it checked for `nullptr`, which was
never returned by the old API), but if that was reachable the new
behaviour should be better.

Differential Revision: https://reviews.llvm.org/D89402
2020-10-19 20:27:56 -04:00
Volodymyr Sapsai
8839e278ff [Modules] Improve error message when cannot find parent module for submodule definition.
Before the change the diagnostic for

    module unknown.submodule {}

was "error: expected module name" which is incorrect and misleading
because both "unknown" and "submodule" are valid module names.

We already have a better error message when a parent module is a
submodule itself and is missing. Make the error for a missing top-level
module more like the one for a submodule.

rdar://problem/64424407

Reviewed By: bruno

Differential Revision: https://reviews.llvm.org/D84458
2020-08-25 16:31:27 -07:00
Martin Boehme
8d74de9de6 [clang] Always allow including builtin headers in [no_undeclared_headers] modules.
Previously, this would fail if the builtin headers had been "claimed" by
a different module that wraps these builtin headers. libc++ does this,
for example.

This change adds a test demonstrating this situation; the test fails
without the fix.
2020-06-04 08:33:39 +02:00