Also notice that while a dependency scanner needs to chase #included or imported files (via the appropriate implementation-defined mapping), it actually does not need to fully preprocess the source code found therein; the spec has been carefully crafted to that effect. This is not science fiction, it is done today by tools like clang-scan-deps - and I would like to see more open source dependency scanner projects/libraries in that line so w can put to bed some canards while democratizing access to dependency computation.

-- Gaby

From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Daniel Ruoso via SG15
Sent: Friday, June 18, 2021 9:19 AM
To: David Blaikie <dblaikie_at_[hidden]>
Cc: Daniel Ruoso <daniel_at_[hidden]>; sg15_at_[hidden]
Subject: Re: [SG15] Draft: Requirements for Usage of C++ Modules at Bloomberg

On Sat, Jun 12, 2021 at 3:31 PM David Blaikie <dblaikie_at_[hidden]<mailto: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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fcpp%23import-3&data=04%7C01%7Cgdr%40microsoft.com%7Ce09d0776e4794a597c6b08d93274ce5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637596299564972493%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EMk%2BB4efiQMr%2Fg%2FTLtamuEjrxTvFE6w13uWZ8yiFh2Y%3D&reserved=0> -- "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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Feel.is%2Fc%2B%2Bdraft%2Fcpp%23import-2&data=04%7C01%7Cgdr%40microsoft.com%7Ce09d0776e4794a597c6b08d93274ce5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637596299564982486%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=eKsgyEGLz20ICIvWlgQ8x4whRNwg9LQmcBYgKtOIpoQ%3D&reserved=0> -- "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)."