[Daniel]
> The output ddi file does not list "Foo:Internal" as a logical name
> provided by this file, unless -internalPartition is also in the
> arguments.

There was a bug in the MSVC dependency scanner that KitWare reported to the MSVC team (thanks!), and it was fixed; the fix will be (or is) available in one of the 17.2 preview.

-- Gaby

-----Original Message-----
From: Daniel Ruoso <daniel_at_ruoso.com>
Sent: Thursday, May 5, 2022 11:31 AM
To: Gabriel Dos Reis <gdr_at_[hidden]>
Cc: Ben Boeckel <ben.boeckel_at_kitware.com>; sg15_at_lists.isocpp.org; Tom Honermann <tom_at_honermann.net>
Subject: Re: [SG15] P2581R0: Specifying the Interoperability of Binary Module Interface Files

Em ter., 3 de mai. de 2022 às 20:44, Gabriel Dos Reis
<gdr_at_[hidden]> escreveu:
> I would like to understand better the logical steps that lead to that conclusion,
> and in particular the (sometimes unspoken) assumptions underlying each of
> those logical steps. Maybe that can help ease the disconnect.

Ok. I had misunderstood what the specifics of the problem were. I sat
down with Bill from Kitware today and we got a concrete understanding
of what the problem is.

Given an "implementation partition" (foo_internal.cxx) with:

```
module Foo:Internal;
void internal_f() {}
```

That partition needs to be importable from the primary unit, or from
any other partition. Therefore this unit provides the logical name
"Foo:Internal". However, when the following command is run:

```
cl.exe -std:c++20 foo_internal.cxx -nologo \
  -scanDependencies t1.cxx.obj.ddi \
  -Fofoo_internal.cxx.obj
```

The output ddi file does not list "Foo:Internal" as a logical name
provided by this file, unless -internalPartition is also in the
arguments.

There are two aspects to this:

 1) The compiler is the one that can identify if this is a "primary
interface unit", an "interface partition" or an "implementation
partition", since the build system is not actually reading that file.
Therefore the build system can't decide which one it is. The only
thing the build system knows is that this is an "importable partition"
(because it helps with the installation steps).

 2) The standard guarantees that "A module partition is a module unit
whose module-declaration contains a module-partition. A named module
shall not contain multiple module partitions with the same
module-partition."(10.1.3), therefore it is not clear what is the goal
of requiring that additional argument, since that unit can only be
interpreted one way. Note that an argument is not required for the
primary interface unit nor for interface partitions.

Given we're talking about the -scanDependencies output, I don't think
we have any concern about implicit outputs.

But regardless of implicit outputs, there's no ambiguity in the
interpretation of "foo_internal.cxx". It is always an importable unit,
and by definition it's the only unit with that partition. Therefore,
it always requires a bmi to be generated. They operate the same way as
all other importable units.

It is not clear to me what is the use case for "foo_internal.cxx" not
generating a bmi.

daniel