| Age | Commit message (Collapse) | Author |
|---|
|
|
|
The CI is complaining about unexpected indentation. It seems multiple-line list entries must start at the beginning of each line.
|
|
As documented in 20.x, we'd like to keep reduced BMI off by default for
1~2 versions. And now we're in 22.x.
I rarely receive bug reports for reduced BMI. I am not sure about the
reason. Maybe not a lot of people are using it. Or it is really stable
enough.
And also, we've been enabling the reduced BMI internally for roughly half a
year.
So I think it's the time to move on. See the document changes for other
information.
|
|
|
|
Doc (#136719)
"Dependant BMI" / "Dependent BMI" was used incorrectly in the
documentation:
"Dependent BMI" refers to a BMI that depends on the current TU, but it
was used for the BMI that current TU depends on.
I replaced all the mentions with "BMI dependency".
|
|
StandardCPlusPlusModules.rst"
This reverts commit 82dc2d403066a84ef0051b06f1d179e00331f319.
The fix has been reverted in f63e8ed16ef1fd2deb80cd88b5ca9d5b631b1c36
|
|
The issue has been fixed in https://github.com/llvm/llvm-project/pull/122726
|
|
'-fmodules-reduced-bmi' (#114382)
According to our previous consensus in
https://clang.llvm.org/docs/StandardCPlusPlusModules.html#reduced-bmi,
the reduced BMI will be the default and recommend users to use the new
option.
The `-fexperimental-modules-reduced-bmi ` option is introduced in
https://github.com/llvm/llvm-project/pull/85050 in Mar13 and released in
19.x. And now we are in 20's release cycle. Also I rarely receive issue
reports about reduced BMI. No matter it is due to the quality of reduced
BMI is really good or no one uses it.
This patch literally did the second point in
https://clang.llvm.org/docs/StandardCPlusPlusModules.html#reduced-bmi
|
|
See
https://discourse.llvm.org/t/rfc-modules-should-we-embed-sources-to-the-bmi/81029
for details.
Close https://github.com/llvm/llvm-project/issues/72383
|
|
'-Wdecls-in-multiple-modules'
As the title shows.
|
|
This landed as https://github.com/llvm/llvm-project/pull/102287 for main
& https://github.com/llvm/llvm-project/pull/102561 for 19.x
CC @ChuanqiXu9
|
|
(#102572)
Motivated by https://github.com/llvm/llvm-project/issues/101348
Although I don't want the tool's doc to explain the standard's wording,
the wording itself has some unspecified thing. So I feel it will be
helpful to make it clear. At least it may help us receive less invalid
issue reports.
|
|
Clang-CL (#98761)
This PR is the first step in improving the situation for `clang-cl`
detailed in [this LLVM Discourse
thread](https://discourse.llvm.org/t/clang-cl-exe-support-for-c-modules/72257/28).
There has been some work done in #89772. I believe this is somewhat
orthogonal.
This is a work-in-progress; the functionality has only been tested with
the [basic 'Hello World'
example](https://clang.llvm.org/docs/StandardCPlusPlusModules.html#quick-start),
and proper test cases need to be written. I'd like some thoughts on
this, thanks!
Partially resolves #64118.
|
|
(Some backgrounds, not required to read:
https://discourse.llvm.org/t/rfc-c-20-modules-introduce-thin-bmi-and-decls-hash/74755)
This is the document part for the no-transitive-change
(https://github.com/llvm/llvm-project/pull/86912,
https://github.com/llvm/llvm-project/pull/92083,
https://github.com/llvm/llvm-project/pull/92085,
https://github.com/llvm/llvm-project/pull/92511) to provide the ability
for build system to skip some unnecessary recompilations.
See the patch for examples.
|
|
Due to https://github.com/llvm/llvm-project/pull/75912 is reverted and
https://github.com/llvm/llvm-project/issues/70585 is reopened. It looks
riskful to fix the issue correctly before 19. So we provide a workaround
here to help people in this trouble as much as possible.
|
|
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.
|
|
See
https://discourse.llvm.org/t/rfc-c-20-modules-introduce-thin-bmi-and-decls-hash/74755,
https://github.com/llvm/llvm-project/pull/75894 and
https://github.com/llvm/llvm-project/pull/85050 for the background.
|
|
|
|
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.
|
|
We support to import C++20 named modules now in in clang-repl in
https://github.com/llvm/llvm-project/commit/dd3e6c87f3f4affd17d05a4d25fa77d224a98d94.
Then we should document how can we do that.
|
|
Changed Things:
- Mentioning we need to specify BMIs for indirectly dependent BMIs too.
- Remove the note for `delayed-template-parsing` since
https://github.com/llvm/llvm-project/issues/61068 got closed.
- Add a note for https://github.com/llvm/llvm-project/issues/78850 since
we've seen it for a lot of times.
- Add a note for https://github.com/llvm/llvm-project/issues/78173 since
we've seen it for a lot of times.
|
|
After
https://github.com/llvm/llvm-project/commit/dc4e85bd79ff17014cbbe4a9db1d9b91929e91ce,
we need to update the examples in the documents.
This patch also fix some other places where is no longer relevant.
|
|
'-fmodule-file=<module-name>='
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.
|
|
working with modules
Catched in https://github.com/llvm/llvm-project/issues/61068.
Add this to the document to avoid further misunderstandings.
|
|
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.
|
|
See
https://discourse.llvm.org/t/clang-cl-exe-support-for-c-modules/72257
for details. Simply, the user of clang-cl.exe can't get a good
experience with C++20 modules now. While we don't have resources to
support it well now, we should make it clear in the documentation.
|
|
|
|
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.
|
|
A lot of editors remove trailing whitespaces. This patch removes any trailing whitespaces and makes sure that no new ones are added.
Reviewed By: erichkeane, paulkirth, #libc, philnik
Spies: wangpc, aheejin, MaskRay, pcwang-thead, cfe-commits, libcxx-commits, dschuff, nemanjai, arichardson, kbarton, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, jrtc27, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, Jim, s.egerton, sameer.abuasal, apazos, luismarques, martong, frasercrmck, steakhal, luke
Differential Revision: https://reviews.llvm.org/D151963
|
|
|
|
Since the C++20 named modules won't check source files consistency after
5b388f8, it would be better to remove this section 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
|
|
experimental
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.
|
|
classes
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.
|
|
import declarations
|
|
|
|
modules in the document
The option '-fmodule-file=<module-name>=<path-BMI>' is already
deprecated now. This patch mentions it in the document.
|
|
This was discussed in https://llvm.org/PR61006.
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D144894
|
|
After reading about the documentation improvements on LLVM weekly this
part seems obsolete.
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D144497
|
|
The patches for `clang-scan-deps` have been landed. And we need to
document the behavior then.
|
|
implementation unit and document the behavior
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.
|
|
document
|
|
We would diagnose about the reserved names in b8ceb9f4e4bd. And the
patch documents about the related behaviors.
|
|
modules
From the discussion in
https://discourse.llvm.org/t/how-should-we-support-dependency-scanner-for-c-20-modules/66027,
we get a consensus that we want to support clang modules and c++ modules
at the same time. This patch documents this intention.
Reviewed By: bruno
Differential Revision: https://reviews.llvm.org/D136221
|
|
|
