Revert "[Serialization] Downgrade inconsistent flags from erros to warnings (#115416)"

This reverts commit 74449ab86b8bc8d7388ede0cc7fc3a679da0c567.

See the post commit message in
https://github.co

Revert "[Serialization] Downgrade inconsistent flags from erros to warnings (#115416)"

This reverts commit 74449ab86b8bc8d7388ede0cc7fc3a679da0c567.

See the post commit message in
https://github.com/llvm/llvm-project/pull/115416

show more ...

[Serialization] Downgrade inconsistent flags from erros to warnings (#115416)

There were many many "voices" about the too strict flags checking in
modules. Although they rarely challenge this, mayb

[Serialization] Downgrade inconsistent flags from erros to warnings (#115416)

There were many many "voices" about the too strict flags checking in
modules. Although they rarely challenge this, maybe due to they respect
to the compiler implementation details. But from my point of view, there
are cases it is "fine" to have different flags. Especially we're too
conservative to mark almost language options in
`clang/include/clang/Basic/LangOptions.def` as incompatible options (see
the comments in the front of the file).

In my understanding, this should come from PCH initially since it is
natural to ask your headers to be compiled with the same flags with your
TU. And then, when Apple and Google goes to implement clang module, they
don't challenge it too since they have a closed world where they have a
strong control over the ecosystem so that they can make it consistent.

Yes, consistency is great and ODR violation are awful. But this is the
world we're living today. This is the C++'s ecosystem in the open ended
world. Image a situation that we're using a third party module and we
add a new option to our library, then the build bails out! THIS IS SUPER
ANNOYING. And makes it non practical to make a modular C++ ecosystem.

(
This was discussed many times in SG15. And the consensus is, the build
systems should generate different BMI based on different flags. But this
manner can't avoid ODR violation completely and it would add the times
of module files that need to be built, which may kill the benefit of
faster compilation of modules.

However, I think the build systems may need to do the similar things in
the end of the day. Considering libc++'s hardening mechanism
(https://libcxx.llvm.org/Hardening.html). So the conclusion of the
paragraph is, although this seems related to build systems, I think they
are actually unrelated story.
)

I think we should give our users a chance to disable such checks. It is
theoretically unsafe. But we've done our job to tell the users that it
**MAY** be bad. Then I feel it is C++-ish to give users more freedom
even if they may shoot their foot.

This shouldn't change any thing. Users who want previous behavior can
get it easily by `-Werror=`.

show more ...

[clang][modules] Move `SLocEntry` search into `ASTReader` (#66966)

In `SourceManager::getFileID()`, Clang performs binary search over its
buffer of `SLocEntries`. For modules, this binary search fu

[clang][modules] Move `SLocEntry` search into `ASTReader` (#66966)

In `SourceManager::getFileID()`, Clang performs binary search over its
buffer of `SLocEntries`. For modules, this binary search fully
deserializes the entire `SLocEntry` block for each visited entry. For
some entries, that includes decompressing the associated buffer (e.g.
the predefines buffer, macro expansion buffers, contents of volatile
files), which shows up in profiles of the dependency scanner.

This patch moves the binary search over loaded entries into `ASTReader`,
which can perform cheaper partial deserialization during the binary
search, reducing the wall time of dependency scans by ~3%. This also
reduces the number of retired instructions by ~1.4% on regular
(implicit) modules compilation.

Note that this patch drops the optimizations based on the last lookup ID
(pruning the search space and performing linear search before resorting
to the full binary search). Instead, it reduces the search space by
asking `ASTReader::GlobalSLocOffsetMap` for the containing `ModuleFile`
and only does binary search over entries of single module file.

show more ...

[modules] Extend r266113 to cope with submodules.

llvm-svn: 266116

[modules] When an incompatible module file is explicitly provided for a module,
and we fall back to textual inclusion, don't require the module as a whole to
be marked available; it's OK if some othe

[modules] When an incompatible module file is explicitly provided for a module,
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

show more ...

[modules] Add -cc1 flag -fmodules-embed-all-files.

This flag causes all files that were read by the compilation to be embedded
into a produced module file. This is useful for distributed build syste

[modules] Add -cc1 flag -fmodules-embed-all-files.

This flag causes all files that were read by the compilation to be embedded
into a produced module file. This is useful for distributed build systems that
use an include scanning system to determine which files are "needed" by a
compilation, and only provide those files to remote compilation workers. Since
using a module can require any file that is part of that module (or anything it
transitively includes), files that are not found by an include scanner can be
required in a regular build using explicit modules. With this flag, only files
that are actually referenced by transitively-#included files are required to be
present on the build machine.

llvm-svn: 253950

show more ...

[modules] When explicitly building a module file, don't include timestamps in
the produced pcm file for stable file creation across distributed build
systems.

llvm-svn: 245199

Don't run explicit-modules-missing-files.cpp on Windows

It is flaky due to inability to remove files with open handles. We
could paper over it with rm -f, but then the file would still be
present.

Don't run explicit-modules-missing-files.cpp on Windows

It is flaky due to inability to remove files with open handles. We
could paper over it with rm -f, but then the file would still be
present.

This is more evidence to me that we should roll our own 'rm'
implementation in LLVM.

llvm-svn: 245083

show more ...

[modules] Add an experimental -cc1 feature to embed the contents of an input
file in the .pcm files. This allows a smaller set of files to be sent to a
remote build worker when building with explicit

[modules] Add an experimental -cc1 feature to embed the contents of an input
file in the .pcm files. This allows a smaller set of files to be sent to a
remote build worker when building with explicit modules (for instance, module
map files need not be sent along with the corresponding precompiled modules).

This doesn't actually make the embedded files visible to header search, so
it's not useful as a packaging format for public header files.

llvm-svn: 245028

show more ...

[modules] Don't suggest deleting the module cache on an error if there is no module cache for this build.

llvm-svn: 244547

[modules] Properly diagnose errors in module files for which we have no
corresponding include location (those specified on the command line).

llvm-svn: 244538

[modules] PR22534: Load files specified by -fmodule-file= eagerly. In particular, this avoids the need to re-parse module map files when using such a module.

llvm-svn: 244416