The intention isn't to add or change the information provided, but to
improve clarity through some grammar fixes, improvements to the
markdown, and so forth.
Although we want to treat the module initializer as a transparent
concept to users, but it shows that people need to understand
the concept to understand how to understand and distribute modules.
So it is better to mention this too.
This patch tries to provide some ideas to transform an existing
libraries to modules. I feel this is helpful for users who is interested
in modules from my observation. While the syntax of modules look easy to
understand, the practice gets harder if the users want to make
compatible work with headers. Especially the `std` module can be
installed in clang18, I think such document may be helpful.
I tried to not be too wordy in this document and I don't want the users
to have impressions that they have to follow this or this is the best
practice. So I tried to use the term `idea` imply the users this is not
compulsory.
I add some regular reviewers for modules, but review opinions from users
are highly recommended.
I want to land this before the releasing of clang18 (in the early
March). We can and should improve this continuously.
Close https://github.com/llvm/llvm-project/issues/79240
Cite the comment from @mizvekov in
//github.com/llvm/llvm-project/issues/79240:
> There are two kinds of bugs / issues relevant here:
>
> Clang bugs that this change hides
> Here we can add a Frontend flag that disables the GMF ODR check, just
> so
> we can keep tracking, testing and fixing these issues.
> The Driver would just always pass that flag.
> We could add that flag in this current issue.
> Bugs in user code:
> I don't think it's worth adding a corresponding Driver flag for
> controlling the above Frontend flag, since we intend it's behavior to
> become default as we fix the problems, and users interested in testing
> the more strict behavior can just use the Frontend flag directly.
This patch follows the suggestion:
- Introduce the CC1 flag `-fskip-odr-check-in-gmf` which is by default
off, so that the every existing test will still be tested with checking
ODR violations.
- Passing `-fskip-odr-check-in-gmf` in the driver to keep the behavior
we intended.
- Edit the document to tell the users who are still interested in more
strict checks can use `-Xclang -fno-skip-odr-check-in-gmf` to get the
existing behavior.
This patch clarifies that in case there are multiple
'-fmodule-file=<module-name>=' optins for the same `<module-name>`,
the last '-fmodule-file=<module-name>=' will override the previous
'-fmodule-file=<module-name>=' option.
This is a nicer way to suppress the diagnostic instead of using the
pre-processor work-around.
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D158523
Address https://github.com/llvm/llvm-project/issues/61006.
The actual reason for the issue is about the usage of clang-scan-deps
instead of its functionalities since clang-scan-deps has
already considered the problem before for clang modules.
So this patch tries to document the corresponding solution
and add a test case for it to address the issue.
It is a known problem that the compiler isn't efficiency when there are
a lot of duplications in the modules to developers. But it may not be
verbose to the (potential) new users of C++20 modules.
It may be necessary to mention this in the document.
During the ISO C++ Committee meeting plenary session the C++23 Standard
has been voted as technical complete.
This updates the reference to c++2b to c++23 and updates the __cplusplus
macro.
Drive-by fixes c++1z -> c++17 and c++2a -> c++20 when seen.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D149553
Close https://github.com/llvm/llvm-project/issues/62241
In tooling group (SG15), it is still unclear how tools should support
header units. Add a warning in the documentation to avoid further
confusions.
Close https://github.com/llvm/llvm-project/issues/56916
Within C++20 modules, we may have multiple same constructors in
multiple same RecordDecls. And it doesn't make sense naturally to create
duplicated deduction guides for the duplicated constructors.
After reading about the documentation improvements on LLVM weekly this
part seems obsolete.
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D144497
Close https://github.com/llvm/llvm-project/issues/57293.
Previsouly we can't use `-fmodule-file=<module-name>=<BMI-Path>` for
implementation units, it is a bug. Also the behavior of the above option
is not tested nor documented for C++20 Modules. This patch addresses the
2 problems.
As the summary explained in https://reviews.llvm.org/D137058,
the design of `-fmodule-output` changes relatively frequently
so I skipped the release notes and docs for -fmodule-output in the
the patches. And the patches get accepted and landed. The patch adds
the related release notes and docs.
We get some standard C++ module things done in clang15.x. But we lack a
user documentation for it. The implementation of standard C++ modules
share a big part of codes with clang modules. But they have very
different semantics and user interfaces, so I think it is necessary to
add a document for Standard C++ modules. Previously, there were also
some people ask the document for standard C++ Modules and I couldn't
offer that time.
Reviewed By: iains, Mordante, h-vetinari, ruoso, dblaikie, JohelEGP,
aaronmondal
Differential Revision: https://reviews.llvm.org/D131388
