<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/libcxx/modules/std/string.inc, branch main</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/'/>
<entry>
<title>[libc++] Refactor the configuration macros to being always defined (#112094)</title>
<updated>2024-11-06T09:39:19+00:00</updated>
<author>
<name>Nikolas Klauser</name>
<email>nikolasklauser@berlin.de</email>
</author>
<published>2024-11-06T09:39:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=c6f3b7bcd0596d30f8dabecdfb9e44f9a07b6e4c'/>
<id>c6f3b7bcd0596d30f8dabecdfb9e44f9a07b6e4c</id>
<content type='text'>
This is a follow-up to #89178. This updates the `&lt;__config_site&gt;`
macros.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is a follow-up to #89178. This updates the `&lt;__config_site&gt;`
macros.</pre>
</div>
</content>
</entry>
<entry>
<title>[libc++][RFC] Always define internal feature test macros (#89178)</title>
<updated>2024-10-12T07:49:52+00:00</updated>
<author>
<name>Nikolas Klauser</name>
<email>nikolasklauser@berlin.de</email>
</author>
<published>2024-10-12T07:49:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=ba87515fea90b5d55836a8e3be63a7e683ce299d'/>
<id>ba87515fea90b5d55836a8e3be63a7e683ce299d</id>
<content type='text'>
Currently, the library-internal feature test macros are only defined if
the feature is not available, and always have the prefix
`_LIBCPP_HAS_NO_`. This patch changes that, so that they are always
defined and have the prefix `_LIBCPP_HAS_` instead. This changes the
canonical use of these macros to `#if _LIBCPP_HAS_FEATURE`, which means
that using an undefined macro (e.g. due to a missing include) is
diagnosed now. While this is rather unlikely currently, a similar change
in `&lt;__configuration/availability.h&gt;` caught a few bugs. This also
improves readability, since it removes the double-negation of `#ifndef
_LIBCPP_HAS_NO_FEATURE`.

The current patch only touches the macros defined in `&lt;__config&gt;`. If
people are happy with this approach, I'll make a follow-up PR to also
change the macros defined in `&lt;__config_site&gt;`.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently, the library-internal feature test macros are only defined if
the feature is not available, and always have the prefix
`_LIBCPP_HAS_NO_`. This patch changes that, so that they are always
defined and have the prefix `_LIBCPP_HAS_` instead. This changes the
canonical use of these macros to `#if _LIBCPP_HAS_FEATURE`, which means
that using an undefined macro (e.g. due to a missing include) is
diagnosed now. While this is rather unlikely currently, a similar change
in `&lt;__configuration/availability.h&gt;` caught a few bugs. This also
improves readability, since it removes the double-negation of `#ifndef
_LIBCPP_HAS_NO_FEATURE`.

The current patch only touches the macros defined in `&lt;__config&gt;`. If
people are happy with this approach, I'll make a follow-up PR to also
change the macros defined in `&lt;__config_site&gt;`.</pre>
</div>
</content>
</entry>
<entry>
<title>[libc++][modules] Support using the module std with -fno-char8_t. (#79155)</title>
<updated>2024-01-30T05:40:21+00:00</updated>
<author>
<name>Po-yao Chang</name>
<email>poyaoc97@gmail.com</email>
</author>
<published>2024-01-30T05:40:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=dc4483659fc51890fdc732acc66a4dcda6e68047'/>
<id>dc4483659fc51890fdc732acc66a4dcda6e68047</id>
<content type='text'>
Exclude some using-declarations in the module purview when compiling
with `-fno-char8_t`.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Exclude some using-declarations in the module purview when compiling
with `-fno-char8_t`.</pre>
</div>
</content>
</entry>
<entry>
<title>[libc++][module] Fixes std::string UDL. (#75000)</title>
<updated>2023-12-12T21:17:02+00:00</updated>
<author>
<name>Mark de Wever</name>
<email>koraq@xs4all.nl</email>
</author>
<published>2023-12-12T21:17:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=7d34f8c09ee17327668c337ff3a7c30656f8daca'/>
<id>7d34f8c09ee17327668c337ff3a7c30656f8daca</id>
<content type='text'>
The fix changes the way the validation script determines the qualified
name of a declaration. Inline namespaces without a reserved name are now
always part of the name. The Clang code only does this when the names
are ambigious. This method is often used for the operator""foo for UDLs.

Adjusted the newly flagged issue and removed a work-around in the test
code that is no longer required.

Fixes https://github.com/llvm/llvm-project/issues/72427</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The fix changes the way the validation script determines the qualified
name of a declaration. Inline namespaces without a reserved name are now
always part of the name. The Clang code only does this when the names
are ambigious. This method is often used for the operator""foo for UDLs.

Adjusted the newly flagged issue and removed a work-around in the test
code that is no longer required.

Fixes https://github.com/llvm/llvm-project/issues/72427</pre>
</div>
</content>
</entry>
<entry>
<title>[libc++][C++20 modules] Enabling in C++20.</title>
<updated>2023-09-05T16:10:46+00:00</updated>
<author>
<name>Mark de Wever</name>
<email>koraq@xs4all.nl</email>
</author>
<published>2023-08-20T10:30:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=b9f24033f7f2d3485fbabbc56e3b31b5bc90e874'/>
<id>b9f24033f7f2d3485fbabbc56e3b31b5bc90e874</id>
<content type='text'>
The vendors of the MSVC STL, libstdc++ and libc++ have agreed [1] to
make the C++23 modules std and std.compat available in C++20. This
provides the std module; libc++ has not implemented the std.compat
module yet.

[1] https://github.com/microsoft/STL/issues/3945

Depends on D158357

Reviewed By: #libc, ldionne

Differential Revision: https://reviews.llvm.org/D158358
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The vendors of the MSVC STL, libstdc++ and libc++ have agreed [1] to
make the C++23 modules std and std.compat available in C++20. This
provides the std module; libc++ has not implemented the std.compat
module yet.

[1] https://github.com/microsoft/STL/issues/3945

Depends on D158357

Reviewed By: #libc, ldionne

Differential Revision: https://reviews.llvm.org/D158358
</pre>
</div>
</content>
</entry>
<entry>
<title>[libc++][modules] Removes the module partitions.</title>
<updated>2023-08-09T17:39:08+00:00</updated>
<author>
<name>Mark de Wever</name>
<email>koraq@xs4all.nl</email>
</author>
<published>2023-08-02T06:16:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=4d4c70c91c5511f8c051623bcc1a76064d5bf687'/>
<id>4d4c70c91c5511f8c051623bcc1a76064d5bf687</id>
<content type='text'>
This patch is based on the suggestion by @ChuanqiXu on discourse
(https://discourse.llvm.org/t/alternatives-to-the-implementation-of-std-modules/71958)

Instead of making a module partition per header every header gets an inc
file which contains the exports per header. The std module then includes
all public headers and these inc files. The one file per header is
useful for testing purposes. The CI tests whether the exports of a
header's module partition matches the "public" named declarations in the
header. With one file per header this can still be done.

The patch improves compilation time of files using "import std;" and the
size of the std module.

A comparision of the compilation speed using a libc++ test
  build/bin/llvm-lit -a -Dstd=c++23 -Denable_modules=std libcxx/test/std/modules/std.pass.cpp

Which boils down to
  import std;

  int main(int, char**) {
    std::println("Hello modular world");
    return 0;
  }
and has -ftime-report enabled

Before
===-------------------------------------------------------------------------===
                          Clang front-end time report
===-------------------------------------------------------------------------===
  Total Execution Time: 8.6585 seconds (8.6619 wall clock)

   ---User Time---   --System Time--   --User+System--   ---Wall Time---  --- Name ---
   4.5041 ( 57.2%)   0.4264 ( 54.4%)   4.9305 ( 56.9%)   4.9331 ( 57.0%)  Clang front-end timer
   3.2037 ( 40.7%)   0.2408 ( 30.7%)   3.4445 ( 39.8%)   3.4452 ( 39.8%)  Reading modules
   0.1665 (  2.1%)   0.1170 ( 14.9%)   0.2835 (  3.3%)   0.2837 (  3.3%)  Loading .../build/test/__config_module__/CMakeFiles/std.dir/std.pcm
   7.8744 (100.0%)   0.7842 (100.0%)   8.6585 (100.0%)   8.6619 (100.0%)  Total

After
===-------------------------------------------------------------------------===
                          Clang front-end time report
===-------------------------------------------------------------------------===
  Total Execution Time: 1.2420 seconds (1.2423 wall clock)

   ---User Time---   --System Time--   --User+System--   ---Wall Time---  --- Name ---
   0.8892 ( 84.6%)   0.1698 ( 88.8%)   1.0590 ( 85.3%)   1.0590 ( 85.2%)  Clang front-end timer
   0.1533 ( 14.6%)   0.0168 (  8.8%)   0.1701 ( 13.7%)   0.1704 ( 13.7%)  Reading modules
   0.0082 (  0.8%)   0.0047 (  2.5%)   0.0129 (  1.0%)   0.0129 (  1.0%)  Loading .../build/test/__config_module__/CMakeFiles/std.dir/std.pcm
   1.0507 (100.0%)   0.1913 (100.0%)   1.2420 (100.0%)   1.2423 (100.0%)  Total

Using "include &lt;print&gt;" instead of "import module;"
===-------------------------------------------------------------------------===
                          Clang front-end time report
===-------------------------------------------------------------------------===
  Total Execution Time: 2.1507 seconds (2.1517 wall clock)

   ---User Time---   --System Time--   --User+System--   ---Wall Time---  --- Name ---
   1.9714 (100.0%)   0.1793 (100.0%)   2.1507 (100.0%)   2.1517 (100.0%)  Clang front-end timer
   1.9714 (100.0%)   0.1793 (100.0%)   2.1507 (100.0%)   2.1517 (100.0%)  Total

It's possible to use the std module in external projects
(https://libcxx.llvm.org/Modules.html#using-in-external-projects)

Tested this with a private project to validate the size of the generated files:

Before
$ du -sch std-*
448M	std-build
508K	std-src
120K	std-subbuild
449M	total

After
$ du -sch std-*
29M	std-build
1004K	std-src
132K	std-subbuild
30M	total

Reviewed By: ldionne, #libc

Differential Revision: https://reviews.llvm.org/D156907
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch is based on the suggestion by @ChuanqiXu on discourse
(https://discourse.llvm.org/t/alternatives-to-the-implementation-of-std-modules/71958)

Instead of making a module partition per header every header gets an inc
file which contains the exports per header. The std module then includes
all public headers and these inc files. The one file per header is
useful for testing purposes. The CI tests whether the exports of a
header's module partition matches the "public" named declarations in the
header. With one file per header this can still be done.

The patch improves compilation time of files using "import std;" and the
size of the std module.

A comparision of the compilation speed using a libc++ test
  build/bin/llvm-lit -a -Dstd=c++23 -Denable_modules=std libcxx/test/std/modules/std.pass.cpp

Which boils down to
  import std;

  int main(int, char**) {
    std::println("Hello modular world");
    return 0;
  }
and has -ftime-report enabled

Before
===-------------------------------------------------------------------------===
                          Clang front-end time report
===-------------------------------------------------------------------------===
  Total Execution Time: 8.6585 seconds (8.6619 wall clock)

   ---User Time---   --System Time--   --User+System--   ---Wall Time---  --- Name ---
   4.5041 ( 57.2%)   0.4264 ( 54.4%)   4.9305 ( 56.9%)   4.9331 ( 57.0%)  Clang front-end timer
   3.2037 ( 40.7%)   0.2408 ( 30.7%)   3.4445 ( 39.8%)   3.4452 ( 39.8%)  Reading modules
   0.1665 (  2.1%)   0.1170 ( 14.9%)   0.2835 (  3.3%)   0.2837 (  3.3%)  Loading .../build/test/__config_module__/CMakeFiles/std.dir/std.pcm
   7.8744 (100.0%)   0.7842 (100.0%)   8.6585 (100.0%)   8.6619 (100.0%)  Total

After
===-------------------------------------------------------------------------===
                          Clang front-end time report
===-------------------------------------------------------------------------===
  Total Execution Time: 1.2420 seconds (1.2423 wall clock)

   ---User Time---   --System Time--   --User+System--   ---Wall Time---  --- Name ---
   0.8892 ( 84.6%)   0.1698 ( 88.8%)   1.0590 ( 85.3%)   1.0590 ( 85.2%)  Clang front-end timer
   0.1533 ( 14.6%)   0.0168 (  8.8%)   0.1701 ( 13.7%)   0.1704 ( 13.7%)  Reading modules
   0.0082 (  0.8%)   0.0047 (  2.5%)   0.0129 (  1.0%)   0.0129 (  1.0%)  Loading .../build/test/__config_module__/CMakeFiles/std.dir/std.pcm
   1.0507 (100.0%)   0.1913 (100.0%)   1.2420 (100.0%)   1.2423 (100.0%)  Total

Using "include &lt;print&gt;" instead of "import module;"
===-------------------------------------------------------------------------===
                          Clang front-end time report
===-------------------------------------------------------------------------===
  Total Execution Time: 2.1507 seconds (2.1517 wall clock)

   ---User Time---   --System Time--   --User+System--   ---Wall Time---  --- Name ---
   1.9714 (100.0%)   0.1793 (100.0%)   2.1507 (100.0%)   2.1517 (100.0%)  Clang front-end timer
   1.9714 (100.0%)   0.1793 (100.0%)   2.1507 (100.0%)   2.1517 (100.0%)  Total

It's possible to use the std module in external projects
(https://libcxx.llvm.org/Modules.html#using-in-external-projects)

Tested this with a private project to validate the size of the generated files:

Before
$ du -sch std-*
448M	std-build
508K	std-src
120K	std-subbuild
449M	total

After
$ du -sch std-*
29M	std-build
1004K	std-src
132K	std-subbuild
30M	total

Reviewed By: ldionne, #libc

Differential Revision: https://reviews.llvm.org/D156907
</pre>
</div>
</content>
</entry>
</feed>
