[PATCH] D117416: [clang-format] Handle C variables with name that matches c++ access specifier

MyDeveloperDay via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Jan 18 00:21:49 PST 2022

MyDeveloperDay added a comment.

For me the push back on the second language and having to pass it on the command line for the .h case  is about VS Code, Vim, Visual Studio, Emacs having to recognize what language they are in and having to pass the -language=XXX flag, now we are pushing the interpretation of what language we are to them and not to us, which mean we are now out of control.

Each editor will make different assessments as to what language it is (likely only 98% correctly) and we'll get the blame when they say its C# and not C because they made the wrong decision

Personally, If we are going to add `C` as a language we need something that can control it without external intervention

something like..

  // clang-format language='C' 

or something that reads the header (like we used to have in Makefile)

  ---*- C++ -*-===//

especially if there is a sudo standard for that, and uses that as a language hint to say this is a "C" .h header

But I think it might be a mistake for us to rely on the editors to provide us that, and even adding the option could open a tsunami of incorrect language issues which we cannot solve.

  rG LLVM Github Monorepo



More information about the cfe-commits mailing list