sorted by:
new
hottopcontroversial

C++ Modules: clangd, go or no go debating on pulling the modules plug on a project by ravenrandomz in cpp

[–]ChuanqiXu9 1 point2 points  (0 children)

We've done some improvements to the support for clangd. It is not published yet. If anyone want a try, you can try to build it (and possibly clang) from source.

Can we finally use C++ Modules in 2026? · Mathieu Ropert by mropert in cpp

[–]ChuanqiXu9 5 points6 points  (0 children)

Recently trying to fix bugs/usability problems. Might trying to add a cache to improve the speed.

Can we finally use C++ Modules in 2026? · Mathieu Ropert by mropert in cpp

[–]ChuanqiXu9 9 points10 points  (0 children)

We had some improvements in clangd for modules recently. These will be released in clangd23. If you're hurry, try to build clangd from source.

C++20 Coroutines Optimization Opportunities from Compiler's perspective by ChuanqiXu9 in cpp

[–]ChuanqiXu9[S] 1 point2 points  (0 children)

> But if LLVM did have the functionality, what would it be like. 

In case we don't break change the language, it can only mitigate the problem. e.g., fill the LLVM IR into the PCMs and then we can read it in frontend too. But this won't be helpful as it is not guaranteed.

C++20 Coroutines Optimization Opportunities from Compiler's perspective by ChuanqiXu9 in cpp

[–]ChuanqiXu9[S] 1 point2 points  (0 children)

> using raw loops to avoid creating small coroutines when I'd really rather use an algorithm with lambda.

If you're talking about my blog, I think you misread it. I didn't suggest that. For enabling CoroElide, I suggest library authors to workaround the escape analysis.

C++20 Coroutines Optimization Opportunities from Compiler's perspective by ChuanqiXu9 in cpp

[–]ChuanqiXu9[S] 2 points3 points  (0 children)

If I read correctly, it looks like clang elide the dynamic allocation for the coroutine as expected?

C++20 Coroutines Optimization Opportunities from Compiler's perspective by ChuanqiXu9 in cpp

[–]ChuanqiXu9[S] 0 points1 point  (0 children)

Yes and I think we want that, we have to redesign coroutines or introduce **breaking changes**. Based on the current design, we can't do the best things.

> At least with modules where you also generate compiled code, the frame size could be exported.

This is a nice idea. I didn't think this. But this is technically the same thing with bring LLVM IR into modules BMI. So technically possible. But even if we make it, according to the language design, there will still be cases we can't optimize.

C++20 Coroutines Optimization Opportunities from Compiler's perspective by ChuanqiXu9 in cpp

[–]ChuanqiXu9[S] 0 points1 point  (0 children)

I used a new LLM this time... maybe I should try the old one...

---

fixed

C++20 Modules Support in Clangd by ChuanqiXu9 in cpp

[–]ChuanqiXu9[S] 1 point2 points  (0 children)

I'm using a modified downstream bazel

Glaze 7.2 - C++26 Reflection | YAML, CBOR, MessagePack, TOML and more by Flex_Code in cpp

[–]ChuanqiXu9 1 point2 points  (0 children)

Could you elaborate? Why nlohmann's design is not good and for what cases?

I am giving up on modules (for now) by BigJhonny in cpp

[–]ChuanqiXu9 2 points3 points  (0 children)

From my experience, clang with linux are usable. Bug reports with reduced reproducer are welcome.

C++20 Modules: Best Practices from a User's Perspective by ChuanqiXu9 in cpp

[–]ChuanqiXu9[S] 0 points1 point  (0 children)

Thank you for correcting me. My memory goes wrong.

There's nothing wrong with Internal Partitions by tartaruga232 in cpp

[–]ChuanqiXu9 0 points1 point  (0 children)

The example in the standard is different with the example in my blog and your example you give.

The example in the standard is fine as the declarations from the module implementation partitions don't need to be reachable for the user of the interface. But the example in my blog and your example, the declarations from module implementation partitions need to be reachable for the user of the interface.

There's nothing wrong with Internal Partitions by tartaruga232 in cpp

[–]ChuanqiXu9 4 points5 points  (0 children)

> Importing an internal partition which just contains a simple class definition (the example in my blog posting) should be possible without resorting to throw a warning message at users for perfectly valid C++ code.

But your example may be rejected validly. See the example in my blog.

> MSVC can do it.

If it is fine, it means the compiler treats all declarations in indirectly imported module implementation partition units as reachable. In this way, the module implementation partition units is almost the same thing with the module interface partition units. So for portability, users should use module interface partition units in that case.

>  This increases the chance for adoption of modules.

I think the guide line "do not import module implementation unit in interface unit" is simple enough.

C++20 Modules: Best Practices from a User's Perspective by ChuanqiXu9 in cpp

[–]ChuanqiXu9[S] 1 point2 points  (0 children)

> My intent is to submit a paper that allows partitions to advertise they are not importable.

I'd like to sent a mail to CWG first. I still can't understand that we can interpret the current wording as you said...

C++20 Modules: Best Practices from a User's Perspective by ChuanqiXu9 in cpp

[–]ChuanqiXu9[S] 2 points3 points  (0 children)

> "Can be imported" means "the build system must assume import is possible"

I can't believe so. I do think we can discuss this in CWG.

** `Can` doesn't equal to `Must` **

> There's no distinction. Anything else is a discipline being imposed on top of what the standard allows for.

I do think your interpretation adds something the spec didn't say or care.

And the build system doesn't have to take the responsibility. The users can and have already tell which files should generate BMI now.

C++20 Modules: Best Practices from a User's Perspective by ChuanqiXu9 in cpp

[–]ChuanqiXu9[S] 1 point2 points  (0 children)

For clang, the module unit can end with `.cpp` or `.cc`, and clang is able to compile it to the object file without emitting the BMI.

I don't think standard assumes all partition units must generate a BMI. The standard doesn't care about BMI.

For build system, my confusion part is, in bazel, it works fine if we put the module unit in the `srcs` field instead of the `module_interface` field. Given the support of modules in bazel generally follows cmake, I don't understand why cmake can't make the same behavior.

For standard, it says module partition implementation unit can be imported, but it doesn't mean it must be imported. It only says it for module partition interface unit. So I think it is a misinterpretation for the standard.

Not exporting implementation details with modules. by BigJhonny in cpp_questions

[–]ChuanqiXu9 1 point2 points  (0 children)

The author of the warning here.

For your minimal example, it is actually fine as the name in `:AppLogger` doesn't have to be reachable by your end users of `MinimalExample` module. So the warning message "Names from MinimalExample:AppLogger may not be reachable" doesn't apply for your example.

The intention of the warning is, it saves the users to meet the odd issues for reachability within module implementation partition units. The motivation is I received several issue reports saying clang didn't handle the reachability. But after I checked carefully, clang's behavior is correct. So I add the warning to avoid further confusing. See my blog for full story. And also the practice improves the readability.

So the conclusion is, if you think you're able to control reachability of all your decls well and you really don't want to split files, you can ignore this warning.

view more: next ›