On 5/2/22 9:53 AM, Daniel Ruoso wrote:
> Em seg., 2 de mai. de 2022 às 00:24, Tom Honermann<tom_at_[hidden]> 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