[cfe-dev] Raising LLVM minimum required, 'dumb question'

[Chandler Carruth]

On Mon, Aug 25, 2014 at 4:33 PM, James Gregurich <bayoubengal at mac.com>
wrote:

> On Aug 25, 2014, at 5:44 PM, Chandler Carruth <chandlerc at google.com>
> wrote:
> >
> > As was mentioned, this is *completely* off topic for the clang
> developers mailing list. Please discuss this somewhere else.
>
> I don’t really get this.  So here you have people upset with a direction
> the project is taking….which IS “on topic.”


FWIW, I don't think many people are at all upset. I think there are a
couple of people upset on a mailing list, but none of them are significant
contributors, and the contributors are quite happy with the direction.


> The direction of the project is determined by the existence of a
> particular problem…which is also apparently “on topic.”  And yet it is “off
> topic” to ask the very fundamental question: "What is the exact nature and
> scope of the problem?” How is that rational?
>
> How do you know how to address the problem if you don’t know what exactly
> what it is?
>

You're assuming that your questions from the original email were
highlighting the problem that Clang's Windows C++ compatibility is trying
to solve. To repeat from the original email:

"""
How many actual known instances of alleged broken lines are there in the
entire Microsoft API header stack?

If one had the dream of just fixing the headers, how big of a job would it
actually be?
"""

This is (IMO) not the relevant question for how or why we should be
compatible. It doesn't matter how many lines there are or how big of a job
fixing them would or wouldn't be. What folks are working on is being
compatible with *existing* code on the Windows platform. The goal expressly
isn't to change that code or fix those headers. So it doesn't really matter
how big of a job it is to fix the headers.

Now, you could reasonably ask "why not try to fix the headers" and in fact
that *did* come up when the project was first undertaken (many years ago)
to start supporting Windows C++ code better. The simple answer was that in
many cases the headers could not be changed. Additionally, in other cases
the change wasn't always clearly a "fix" or not; it would be a matter that
people disagree on with some preferring the code as-is. And that really
wasn't an interesting debate to enter into because it is hard to argue that
legacy code which works today should change to support some hypothetical
future compiler.


When Clang originally started, it worked *very* hard to support
non-standard C and C++ that was accepted by GCC because as the new
compiler, compatibility was the key to adoption. This was essential to its
success. We still did a cost/benefit tradeoff on supporting truly egregious
constructs, but its pretty hard to argue that supporting the operating
system's default system headers isn't worthwhile. We support *terrible*
things to allow us to parse very old versions of glibc's public headers. We
also have warnings to diagnose them and worked with the upstream
maintainers to get some of these things fixed. But we still support the old
headers because that's the key to adoption.


Now, what was off topic? The idea of going into some other operating
system's header files and trying to make value judgements about what
constitutes a "bad" line of code, and how many of them there are or how
hard it would be to change them. It's mostly off topic because of the
non-technical nature of the assessment: these lines of code are not broken
or bad, they simply don't conform to C++ in the strictest sense. I suspect
LLVM itself contains such header files. ;] It's also somewhat off topic
because it is no longer relevant - we've already gone down the path of
compatibility, and Clang is (at this point) essentially 99.99% compatible
with the header files. If you want to work with Microsoft or any other
operating system vendor to improve their header files, cool, but I think
that discussion should be had primarily in those development communities
unless there are technical questions about *why* one C++ construct is
non-conforming.

And of course *all* of this is incredibly far afield from the actual
subject of the thread on which it came up: switching the minimum supported
*host* compiler from MSVC 2012 to MSVC 2013! This has zero bearing on how
compatible Clang is with extensions used in system header files when *it*
is the host compiler on a particular platform.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140825/13e9057b/attachment.html>