On Sat, Jun 12, 2021 at 3:31 PM David Blaikie <dblaikie_at_[hidden]> wrote:

> * Dependency Graph of Modules External to the Build: "Having to perform
> the discoverability of module dependencies topologically for modules
> outside of the current build will result in an undesirable performance
> penalty. Therefore it’s important that the module dependency graph should
> be exposed in a way that is cheaper to parse."
> My understanding is the spec was designed to make this cheap - to ensure
> that not a lot of C++ parsing complexity would be required to read the
> start of a module to discovery its dependencies. Do you find this not to be
> the case, or to be inadequate for practical purposes?
>

After doing another review, I think R3 is still needed. While the standard
limits this in a very concrete way[1], I can't see anything stopping you
from using a preprocessing macro in an import statement, so you can't just
use a simple lexer to identify dependencies, you need to evaluate with a
complete preprocessor, including the possibility of having to open included
files in order to be able to evaluate macros. In fact, it seems to
explicitly allow module names to be macros[2]. Therefore the dependency
scanning needs to open an unbounded number of files for each module.

I'll incorporate information to that effect into the paper.

[1] : https://eel.is/c++draft/cpp#import-3 -- "If a pp-import is produced
by source file inclusion (including by the rewrite produced when a #include
directive names an importable header) while processing the group of a
module-file, the program is ill-formed."
[2]: https://eel.is/c++draft/cpp#import-2 -- "The preprocessing tokens
after the import preprocessing token in the import control-line are
processed just as in normal text (i.e., each identifier currently defined
as a macro name is replaced by its replacement list of preprocessing
tokens)."