Meinersbur wrote: Source compiled for the runtime has different requirements than the source compiled into the compiler. Any source that is not not used in the runtime yet will probably be incompatible with the runtime requirements. Even if it does, there is no reason to enforce runtime requirements to those sources that are not even used in the runtime.
Additional requirements include: * Must not cause a link-time dependency on the C++ standard library with any supported toolchain * Must be compilable as device code with nvcc/clang * Must not use `#include <optional>` or `#include <variant>`, but the replacements `#include "optional.h"` and `#include "variant.h"` * Must use the annotation macros from `api-attrs.h` * ... These requirements should really be formalized if we want to keep it maintanable. The first step is to separate the sources for which these requirements apply from the sources to which they do not, done in this PR. Mistakes not complying to these requirements already happened, see #110244, #112188, and https://github.com/llvm/llvm-project/pull/122069/files#diff-849ce0fa56b431a9789f5edb13f3ef46386024e6c4344529326856c39501323dR27. LLVM coding policy actively discourages compiling only a subset of the sources, see `PARTIAL_SOURCES_INTENDED`. Currently all of the runtime-included files are header-only[^1], but there are any in the future[^2], it would require `PARTIAL_SOURCES_INTENDED`, i.e. such thing is *actively discouraged* by the LLVM coding policy. `PARTIAL_SOURCES_INTENDED` currently can only check translation units, and `FortranCommon` has none needed for the runtime right now, but I don't think to stay like that forever[^2]. If in the future one source file is handy for the runtime as well, it can be moved into Common, but I doubt it would be the entirety of its defintions but only some that are actually needed. If that happens, the patch would need to ensure that the runtime requirements are met. This applies to any file in any directory btw. IMHO it is a bad argument to retain bad coding practices. It is needed in the sense that without this separation, I would never have understood what defintions are actually part of the runtime. Why `Fortran-features.h` uses `#include <optional>` but `fast-int-set.h` must use `#include "optional.h"`. Please don't make anyone else go through this. [^1]: With the exception of FortranDecimal and `Fortran.h` which was resolved in #110244. [^2]: I suspect some of these are header-only only because they are included into the runtime. Some definitions and tables from e.g. `format.h` and `leading-zero-bit-count.h` are usually considered way too large to be inline defintions. I would have considered `FortranDecimal` to be typical common code. I don't think we want to introduce yet another library for every common utility just because `FortranCommon` is not structured well. https://github.com/llvm/llvm-project/pull/122069 _______________________________________________ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
