Date: Mon, 16 Oct 2023 10:30:06 +0200
On Mon, Oct 16, 2023, 04:21 Chuanqi Xu via SG15 <sg15_at_[hidden]>
wrote:
> In 2.1, it should be `P1689R5` instead of `P1689R4` as far as I know.
>
Ack, will fix.
But as far as I know, all the compilers require to compile the module
> interface unit to object files and link that.
>
Yes, clang was the only one I verified the behavior. But I was aware of the
convergence there. I'll change the wording a little bit to clarify that.
For 2.3.1, I am trying to support C++20 modules in clangd:
> https://github.com/llvm/llvm-project/pull/66462. But I understand it is
> OK to not mention it since it is not landed. I just mention it here FYI.
>
I'll add the context. I was not aware of that. Thanks.
For 3.4, from my experience in clangd, it looks sufficient to have the
> existing compilation database and a map from module name to the source
> files for the static analyzing tools to create BMIs for their own.
>
This is in line with the other discussion. We also need to support "local
processor arguments".
Also I am suggesting to add a section for the current state of std module
> in some places of section2.
>
My secret goal is for us to make the std modules look just like any named
modules without any special cases.
But, I'm opening to adding that more explicitly to the roadmap.
Daniel
wrote:
> In 2.1, it should be `P1689R5` instead of `P1689R4` as far as I know.
>
Ack, will fix.
But as far as I know, all the compilers require to compile the module
> interface unit to object files and link that.
>
Yes, clang was the only one I verified the behavior. But I was aware of the
convergence there. I'll change the wording a little bit to clarify that.
For 2.3.1, I am trying to support C++20 modules in clangd:
> https://github.com/llvm/llvm-project/pull/66462. But I understand it is
> OK to not mention it since it is not landed. I just mention it here FYI.
>
I'll add the context. I was not aware of that. Thanks.
For 3.4, from my experience in clangd, it looks sufficient to have the
> existing compilation database and a map from module name to the source
> files for the static analyzing tools to create BMIs for their own.
>
This is in line with the other discussion. We also need to support "local
processor arguments".
Also I am suggesting to add a section for the current state of std module
> in some places of section2.
>
My secret goal is for us to make the std modules look just like any named
modules without any special cases.
But, I'm opening to adding that more explicitly to the roadmap.
Daniel
Received on 2023-10-16 08:30:18