4 ms·

Thanks for reporting this. It's the first evidence I've heard of someone (Google?) abusing their power with LLVM in order to protect Google's products. Mind sh

Thanks for reporting this. It's the first evidence I've heard of someone (Google?) abusing their power with LLVM in order to protect Google's products. Mind sharing a link to your submission's discussion thread(s)?

hvdijk 6y ago
I don't think it's productive to speak of the LLVM maintainer's decision as an abuse of power. The actual revert happened in contradiction of documented LLVM policies (which, according to the maintainer, do not match actual LLVM policies), so I did take issue with that, but the maintainer wanted to first make sure clang had a different conforming extension that Chromium could use instead before removing the non-conforming extension, and assuming that a non-Google project would be given the same treatment -- and I have no reason to assume otherwise -- I think that is defensible. The change was <https://reviews.llvm.org/D91913 https://reviews.llvm.org/D91913>, addressing a conflict between GCC's ,##__VA_ARGS__ extension with the C and C++ standards in the corner case where a macro, let's call it FOO, takes no named parameters and is invoked as FOO(). In standards-conforming C modes, clang already acts as required by the standard, but in meant-to-be-conforming C++ modes, it does not.
- DoofusOfDeath 6y ago
  Thanks for the context! You saved me from foolishly wandering into crowd-with-pitchforks mode.
  - gpderetta 6y ago
    I was also reaching for my pitchfork, but in this case there is probably more code in the wild that relies on the (very useful) GCC extension as opposed to the standard behaviour.
    - hvdijk 6y ago
      I'm not too sure about the "more code in the wild" that would be broken though. GCC already disables this extension, in the cases where it conflicts with the standard, in -std=c++11 mode. I expect almost all code to either use -std=c++11 consistently, in which case it would already be broken with GCC, or to use -std=gnu++11 consistently, in which case it would continue to work with clang even after that patch. Chromium is weird in that it builds with -std=c++11 if building with clang, and it builds with -std=gnu++11 if building with GCC. (Change 11 to 14 or whatever else as needed.)
      - gpderetta 6y ago
        Thas clang distinguish between g++11 and c++11? If so chrome should probably use the former.
        hvdijk 6y ago
        Yup, I made sure my change would make clang agree with GCC as far as this particular extension is concerned, so it was fully enabled in -std=gnu++11 mode and only enabled where it didn't conflict with standard C++ in -std=c++11 mode. I felt the same way that Chromium should just use the same flags for clang as for GCC if they want to keep using this extension, but they don't.
        gpderetta 6y ago
        it seems that their reasoning is that they, understandably, do not want more gnu-ism in gnu++11 to creep up in their code base. But it seems that they are happy for this specific gnu-ism to creep up in other teams code bases... Odd at the very least.

hvdijk 6y ago

I don't think it's productive to speak of the LLVM maintainer's decision as an abuse of power. The actual revert happened in contradiction of documented LLVM policies (which, according to the maintainer, do not match actual LLVM policies), so I did take issue with that, but the maintainer wanted to first make sure clang had a different conforming extension that Chromium could use instead before removing the non-conforming extension, and assuming that a non-Google project would be given the same treatment -- and I have no reason to assume otherwise -- I think that is defensible. The change was <https://reviews.llvm.org/D91913 https://reviews.llvm.org/D91913>, addressing a conflict between GCC's ,##__VA_ARGS__ extension with the C and C++ standards in the corner case where a macro, let's call it FOO, takes no named parameters and is invoked as FOO(). In standards-conforming C modes, clang already acts as required by the standard, but in meant-to-be-conforming C++ modes, it does not.

DoofusOfDeath 6y ago
Thanks for the context! You saved me from foolishly wandering into crowd-with-pitchforks mode.
- gpderetta 6y ago
  I was also reaching for my pitchfork, but in this case there is probably more code in the wild that relies on the (very useful) GCC extension as opposed to the standard behaviour.
  - hvdijk 6y ago
    I'm not too sure about the "more code in the wild" that would be broken though. GCC already disables this extension, in the cases where it conflicts with the standard, in -std=c++11 mode. I expect almost all code to either use -std=c++11 consistently, in which case it would already be broken with GCC, or to use -std=gnu++11 consistently, in which case it would continue to work with clang even after that patch. Chromium is weird in that it builds with -std=c++11 if building with clang, and it builds with -std=gnu++11 if building with GCC. (Change 11 to 14 or whatever else as needed.)
    - gpderetta 6y ago
      Thas clang distinguish between g++11 and c++11? If so chrome should probably use the former.
      - hvdijk 6y ago
        Yup, I made sure my change would make clang agree with GCC as far as this particular extension is concerned, so it was fully enabled in -std=gnu++11 mode and only enabled where it didn't conflict with standard C++ in -std=c++11 mode. I felt the same way that Chromium should just use the same flags for clang as for GCC if they want to keep using this extension, but they don't.
        gpderetta 6y ago
        it seems that their reasoning is that they, understandably, do not want more gnu-ism in gnu++11 to creep up in their code base. But it seems that they are happy for this specific gnu-ism to creep up in other teams code bases... Odd at the very least.