Clang & C++ 20 modules round table meeting notes

Community US Developer Meeting
1

Topics discussed:

64-bit source location proposal

  • There is general pessimism about supporting this in the room. There was discussion around allowing this as a configurable option, but there was criticism around the maintenance burden of needing to support both upstream.
  • Concerns that overflow bugs caused by the current encoding are often due to a lack of modularization and duplicate types that require type merging to handle correctly.

Modulemaps as header units & discovery for C++20 modules

  • There’s a proposal in the standard & desire to represent header units as clang modules.
  • Google often does not rely on headersearch to resolve modulemaps because they specify explicit dependencies within their own build configuration. They also have a simple verifier tool for checking against those explicit dependencies. This differs from clang-scan-deps or lib/DependencyScanning where it resolves modulemaps through header inclusions.

Diagnostics when adopting modules

  • It was stated that diagnostics around bad modules is often very hard to understand and diagnose. Below are a couple of examples and mitigations, if they were presented.
  • One example of the extreme cases is ODR violations that are difficult to debug within Google codebases.
  • Another is search path misconfigurations resulting in inconsistent headers being resolved when, from a user perspective, the reported source locations seem the same, within Xcode projects. There was a suggestion to replay the header search when this error happens as a diagnostic improvement.
  • As an extension of the 64bit source loc discussion, this was pointed out as another example of poor modularization causing difficult to diagnose symptoms. One suggestion here was to inspect which header files cause the most amount of source location entries as a diagnostic note.

assert.h as a textual header

Config macros

  • As an extension of the conversation around assert.h, Michael suggested that config macros in a specified module map should be treated and resolved transitively through modular dependencies.
  • Interestingly enough, there was an old idea to take the preprocessor state before entering a modular header and transform #define’s macros into config macros when building a module, but that was never implemented.
  • A question was raised on how to compute a given library’s config macros for handling in modules. Richard suggested allowing a mode where modular headers get treated textually and collect what macro expansions happened that otherwise would have been missed.

ODR checker

  • There is no clear maintainer. The checks are getting weaker as new contributions collide with this functionality, and it has false positives.
  • There was an explicit request to do something about this, but it’s unclear what the path forward will be.

Treating modules as their own translation unit

  • This is already true today when building a PCM through creating a unique compiler instance.
  • There was a suggestion that being able to treat modules as separate translation units, while also reading, would support better build times because it would mean the compiler could avoid (de)serialization cost.
  • This seems like an exciting direction. However, much of the compiler assumes it’s only operating over one TU, so it may require significant changes.
  • There was a similar experiment to try to avoid (de)serialization overhead by communicating across compiler instances the module dependencies, but it didn’t work well due to memory overhead. But maybe there is more promise within a single compiler instance.

Visibility vs Reachability

  • With clang modules, specifying export * makes declarations from transitive module dependencies available. Without it, there are stricter rules of what decls are visible to a client. However, there are various bugs where this checking breaks down when composing e.g. template instantiations from definitions in other modules. Folks mentioned clang does not have a strong distinction between visibility and reachability in this regard, though the standard does. It was suggested that treating modules as their own TU would also help with this class of issues.

Global module fragments

  • There are issues around respecting -include for global module fragments, but that is currently being addressed.
  • There are potentially overzealous rules around what’s allowed in the fragment in an effort to make it fast to scan for module names. Richard suggested that having a pragma to specify this at the top of the file would simplify.

I didn’t record who said what precisely, but tagged folks who were involved in the discussion. @vsapsai @bigcheese @zygoloid @efriedma-quic @blangmuir @mizvekov

2 Likes