[PATCH] D142932: Multilib YAML parsing

[Petr Hosek via Phabricator via cfe-commits]

phosek added inline comments.


================
Comment at: clang/lib/Driver/Multilib.cpp:137
+struct MultilibSetSerialization {
+  std::string ClangMinimumVersion;
+  std::vector<MultilibSerialization> Multilibs;
----------------
Can we use a separate versioning scheme rather than tying the version to Clang? That is start at version 1.0 and bump it every time we make backwards incompatible change. That's the strategy we've for YAML formats used in other tools such as [llvm-ifs](https://llvm.org/docs/CommandGuide/llvm-ifs.html#ifs-formats).

The reason I think that would be preferable is that Clang will be at version //N.0.0// for ~9 months; we bump the version when we branch of the release, then spent 6 months developing and then typically another 3 months stabilizing the release branch. So for example, we bump the version to 16.0.0 in July 2022, and that version will get released in March 2023. However, during those 9 months, we may want to make more than one breaking change to the format.

This may not be an issue for projects that only follow stable releases, but there's plenty of major projects that live at HEAD, such as Android, Chromium or Fuchsia, for which this could cause an issue. Using a dedicated versioning scheme allows us to decouple the format evolution from Clang releases.


================
Comment at: clang/lib/Driver/Multilib.cpp:137
+struct MultilibSetSerialization {
+  std::string ClangMinimumVersion;
+  std::vector<MultilibSerialization> Multilibs;
----------------
phosek wrote:
> Can we use a separate versioning scheme rather than tying the version to Clang? That is start at version 1.0 and bump it every time we make backwards incompatible change. That's the strategy we've for YAML formats used in other tools such as [llvm-ifs](https://llvm.org/docs/CommandGuide/llvm-ifs.html#ifs-formats).
> 
> The reason I think that would be preferable is that Clang will be at version //N.0.0// for ~9 months; we bump the version when we branch of the release, then spent 6 months developing and then typically another 3 months stabilizing the release branch. So for example, we bump the version to 16.0.0 in July 2022, and that version will get released in March 2023. However, during those 9 months, we may want to make more than one breaking change to the format.
> 
> This may not be an issue for projects that only follow stable releases, but there's plenty of major projects that live at HEAD, such as Android, Chromium or Fuchsia, for which this could cause an issue. Using a dedicated versioning scheme allows us to decouple the format evolution from Clang releases.
Use `llvm::VersionTuple` rather than `std::string` which is intended for this purpose.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D142932/new/

https://reviews.llvm.org/D142932