Date: Wed, 14 Jan 2026 14:15:06 -0500
On Wed, Jan 14, 2026 at 11:28:59 +0800, Jason Merrill via SG15 wrote:
> On Wed, Jan 14, 2026 at 10:09 AM Chuanqi Xu via SG15 <sg15_at_[hidden]>
> wrote:
>
> > > IMO, if you have a non-exported partition that you don't want exported,
> > remove the partition name. It can (must) then be listed outside of a
> > `CXX_MODULES` file set and won't make a BMI (whatever the costs may be).
> > The standard already has a mechanism to do the "part of a module, but
> > not making a BMI". Why do we need another subflavor of translation unit?
> >
>
> IIUC the issue is that if you have a TU that implements the interface of a
> particular partition, and only needs to import that partition, removing the
> partition name creates an interface dependency on the entire module,
> resulting in unnecessary rebuilding if a different interface partition
> changes.
>
> Chuanqi proposes to handle this by giving the implementation unit its own
> dummy partition name, and then wants a way to suppress BMI generation for
> that dummy partition. But this seems a bit like piling kludge on kludge to
> work around the lack of a way in the standard to specify an implementation
> unit for a specific partition.
Ok, not wanting the dependency on the entire module makes sense to me.
However, IIUC, this causes confusion on the MSVC side. Right now, a TU
`module mod:part;` can have two meanings:
- in a `CXX_MODULES` file set -> add `-internalPartition` and get a BMI
- not in a `CXX_MODULES` file set -> "partition implementation" MSVC
extension
Adding support for "internal partition that does not make a BMI" to
Clang and GCC sounds fine, but I'd prefer that the *scanner* report that
it won't make a BMI (so that the compiler doesn't dump a BMI somewhere
that CMake isn't tracking; how else will the compiler know this BMI is
unwanted?). Can we get an attribute like:
module [[never_imported]] mod:part;
to indicate this situation? If the scanner says no BMI will be
generated, the CMake (as it currently exists) has no qualms about such a
TU being in a non-`CXX_MODULES` file set.
Thanks,
--Ben
> On Wed, Jan 14, 2026 at 10:09 AM Chuanqi Xu via SG15 <sg15_at_[hidden]>
> wrote:
>
> > > IMO, if you have a non-exported partition that you don't want exported,
> > remove the partition name. It can (must) then be listed outside of a
> > `CXX_MODULES` file set and won't make a BMI (whatever the costs may be).
> > The standard already has a mechanism to do the "part of a module, but
> > not making a BMI". Why do we need another subflavor of translation unit?
> >
>
> IIUC the issue is that if you have a TU that implements the interface of a
> particular partition, and only needs to import that partition, removing the
> partition name creates an interface dependency on the entire module,
> resulting in unnecessary rebuilding if a different interface partition
> changes.
>
> Chuanqi proposes to handle this by giving the implementation unit its own
> dummy partition name, and then wants a way to suppress BMI generation for
> that dummy partition. But this seems a bit like piling kludge on kludge to
> work around the lack of a way in the standard to specify an implementation
> unit for a specific partition.
Ok, not wanting the dependency on the entire module makes sense to me.
However, IIUC, this causes confusion on the MSVC side. Right now, a TU
`module mod:part;` can have two meanings:
- in a `CXX_MODULES` file set -> add `-internalPartition` and get a BMI
- not in a `CXX_MODULES` file set -> "partition implementation" MSVC
extension
Adding support for "internal partition that does not make a BMI" to
Clang and GCC sounds fine, but I'd prefer that the *scanner* report that
it won't make a BMI (so that the compiler doesn't dump a BMI somewhere
that CMake isn't tracking; how else will the compiler know this BMI is
unwanted?). Can we get an attribute like:
module [[never_imported]] mod:part;
to indicate this situation? If the scanner says no BMI will be
generated, the CMake (as it currently exists) has no qualms about such a
TU being in a non-`CXX_MODULES` file set.
Thanks,
--Ben
Received on 2026-01-14 19:15:19
