On 5/2/22 9:53 AM, Daniel Ruoso wrote:
Em seg., 2 de mai. de 2022 às 00:24, Tom Honermann <tom@honermann.net> escreveu:
Given an initial configuration of predefined macros (and enabled attributes, enabled features
that impact semantics, present header files, etc...)
"enabled attributes" and "enabled features" is what I meant by a
completeness problem. You would need to know the complete feature set
from the compiler, and make sure any one of them that would
potentially affect the bmi are set in a particular way.

Only the has-attribute checks actually performed during the parse are relevant. In the following example, the BMI build would record that __has_cpp_attribute(carries_dependency) was true and that __has_cpp_attribute(deprecated) was false. Whether __has_cpp_attribute(fallthrough) would have been true or false is immaterial had it been tested is immaterial because it wasn't tested; thus, there is no need to record nor query that attribute's availability when determining re-usability because it wouldn't affect the parse result.

#if __has_cpp_attribute(carries_dependency)
/* Parsed */
#endif
#if !__has_cpp_attribute(deprecated)
/* Parsed */
#endif


there can be only one parse result for a given source file.
Yeah, but that's not the only source of bmi format changes.
Could you please elaborate? Anything that might cause the BMI to be differently generated would be something that belongs in the set of initial conditions.

I acknowledge the desire to avoid invoking the compiler to make
 such a determination, so consider this the low QoI approach. But then again,
invoking just the preprocessor may perform sufficiently well.
I don't think that is true. There are various other things that may
affect the usability of a bmi beyond the preprocessed contents of the
module interface unit.
Yes there are; I didn't claim that there were not. As we discussed, include paths, existence of headers, and some options (e.g., /Zc:char8_t[-]) are relevant as well.

I previously stated that this approach could eliminate the need to consider
compiler options by themselves, but that was not correct. A good example
 is the MSVC /Zc:char8_t[-] option. Though that option is associated with
a feature test macro, there is no guarantee that code that is sensitive to use
of the option be guarded by the macro. In the following example, p will
conditionally have type const char* or const char8_t* depending on use
of that option. Thus, that option would need to be reflected as part of the
salient properties of the initial configuration.
Exactly, that's what I meant by completeness problem. You would need
to enumerate all options that *could* behave like this.
Yes. In practice, I don't think there are all that many of them. The ones that matter are those that change what code means; where the same code is well-formed with and without the option, but changes meaning.

I think that would have a negative impact on the ability to adopt modules. In particular,
it seems to me that it would greatly reduce the ability to consume a BMI distributed
from a compiler implementor.
The trade-off here is that in an environment with a coherent set of
configurations (let's say, the system compiler on a Debian system),
the toolchain configuration discovered by the build system (e.g.:
CMake) has a very likely chance to match what was distributed, and at
that point, the build system doesn't have to recursively parse all
modules consumed by this project before it can start using them.
I strongly disagree with that expectation. The majority of projects I've worked on, and packages I've seen built, add compiler options to opt-in or opt-out of various features.

The alternative is that we make it more likely to find a reusable bmi,
but now we need to invoke the compiler for all modules that are
consumed in order to determine if they are usable or not.
Yes, once per module per desired baseline. The result can be cached by the build system.

The goal of this paper is to offer an optimization mechanism such that
when you have fully coherent distributions, you can skip an additional
scanning step.

I understand that goal, but I don't think it is feasible. Build systems are going to continue to define macros and pass compiler options that must be assumed to impact how BMIs would be built unless there is evidence otherwise.

Tom.


daniel