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
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.there can be only one parse result for a given source file.Yeah, but that's not the only source of bmi format changes.
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 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. 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 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.
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.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.
Yes, once per module per desired baseline. The result can be cached by the build system.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.
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