IssueRaiser

Modules support

It would be nice if some of {C++20 modules, clang header modules} worked in clangd. Essentially no configurations of this work today: occasionally things may happen to work but there are many reported problems and crashes. These are not just bugs that can be fixed, a design and new infrastructure is needed. Because clang's module functionality can be enabled by setting driver flags, it is possible/easy for people to end up in this broken and unsupportable state, and wasting (their + our) time debugging it. We should consider failing early and explicitly instead. **AFAIK nobody has plans/availability to work on this soon.** Some issues that need to be addressed: - which subset of clang's many module features/flags are in scope? - explicit modules provided by build system: we can't assume these are compatible (may be a different compiler version). So may need to convert to implicitly building modules needed. - having AST workers/background threads spawning module builds independently and coordinating through the module cache is probably not good, we'll want some kind of worker pool and coordination - we presumably want to parse modules in the same lite mode as preambles (e.g. skip-function-bodies) - gcc modules flags are different than clang modules flags (and MSVC presumably different again), we need to parse them - how do modules fit into the dynamic index? what does a preamble with modules in it look like? - scattered places where we assume mainfile/preamble dicho

Posted by sam-mccall on Sep 15, 2022, 7:08 PM

Tags

Related issues

Raise real-world problems, find people facing the same issue, and discuss solutions.2,500 issues0 comments

reliability (Software)

Modules support

sam-mccallSep 15, 2022, 7:08 PM

It would be nice if some of {C++20 modules, clang header modules} worked in clangd. Essentially no configurations of this work today: occasionally things may happen to work but there are many reported problems and crashes. These are not just bugs that can be fixed, a design and new infrastructure is needed. Because clang's module functionality can be enabled by setting driver flags, it is possible/easy for people to end up in this broken and unsupportable state, and wasting (their + our) time debugging it. We should consider failing early and explicitly instead. **AFAIK nobody has plans/availability to work on this soon.** Some issues that need to be addressed: - which subset of clang's many module features/flags are in scope? - explicit modules provided by build system: we can't assume these are compatible (may be a different compiler version). So may need to convert to implicitly building modules needed. - having AST workers/background threads spawning module builds independently and coordinating through the module cache is probably not good, we'll want some kind of worker pool and coordination - we presumably want to parse modules in the same lite mode as preambles (e.g. skip-function-bodies) - gcc modules flags are different than clang modules flags (and MSVC presumably different again), we need to parse them - how do modules fit into the dynamic index? what does a preamble with modules in it look like? - scattered places where we assume mainfile/preamble dicho

Comments (0)

No comments yet. Start the discussion.

Comment on this issue