Raising LLVM minimum required, 'dumb question'

James

Good question. If you look at the entire thing and tried to evaluate how big of a job you might become ill!

I have another dumb question...

How big of a job would it be to SIZE that job? Maybe you could count the errors in one file, then multiply it times the number of files.

One way to size it is look at wxwidgets. There is a lot more there than just fixing the api header stack, but you can see all the system calls, how they are wrapped etc, and the product WORKS across mac linux and windows, so its a good starting place. It is not overly concerned with the latest c++ however.

that is a good suggestion. WxWidgets is just the kind of project that would have had to already address these sorts of things.

I guess the crux of my question is to ask whether it is a case of huge numbers of headers that rely on alleged broken compiler behavior or...is it a case where there is a handful of problem headers that cascade down through the header hierarchy and look like 10 million different problems when you compile?

-James

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.” 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?

Or is your opinion that the problem is addressed to your satisfaction and you just want people to quit griping and accept what has been decided..and your approach is just to dismiss the discussion with “off topic”?

>
> 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.

For me, I’m undecided. I’m trying to understand the issues involved so that I can have an informed opinion. For instance, when I see the boost fellow from a few weeks back complain that now he cannot trust clang to have a rational preprocessor under some circumstances, my gut reaction is that he has a legitimate gripe. That complicates his life as a client of clang. As a client of clang myself who advocates and pushes its use in my sphere, that matters to me. certainly, situations like that need to have a quality solution.

You personally expend quite a lot of energy traveling to conferences playing cheerleader for clang to get folks like us interested in it. When those who do get interested in it kvetch a little…and the kvetch isn’t an irrational kvetch, perhaps you should spend some of that energy addressing their kvetches rather than just dismissing them with “you aren’t a contributor” and leave us with the impression that we don’t really matter. Take the time to explain the situation, the decision that was made and get your customers on board with it. Make sure we have the things we need from a compiler standpoint to work around the imperfections.

yes it does. Because if the problem is one or two header files that cascade across dozens or more files in win32, then perhaps what one should do is address those couple of files by providing a solution that wraps them and adapts their behavior by some means. However, if the referenced problems are scattered all over the place, then such an approach is not practical.

If the details were debated and a decision made, then explain the details. It is also perfectly acceptable to say “we discussed this issue and decided XXXX. Please refer to the archives and read what was already said before discussing it all over again." I wasn’t there for the discussion, but I have been following this thread keenly to see where it was going. You’ll pardon me if I desired additional information and wasn’t satisfied with the spot at which it fizzled out.

I’m not interested in that mindset at all. The code that Microsoft wrote back then was for that day and age. We’ve what…20 years of experience to look back upon that those guys didn’t have. It is what it is and I have no interest in finding fault with it. The question for me is…WHAT doesn’t compile, WHY doesn’t it compile and HOW does one address the situation in the real-world today.

I’ve give you that one. However, the conversation did drift where it drifted and did raise the questions (at least in my mind) that it raised. However, you’ve now told me what I needed to know….that adapting the headers was considered and rejected. I’ll dig into the archives for further info.

thanks for taking the time to create a thoughtful response.

-James

Hi James, I’ll bite the bullet by trying to paraphrase Chandler. I think that he was just trying to keep the discussion on topic. It happens quite often that someone has additional questions, like you in this case. But as Chandler pointed out, brokenness of platform headers on windows really doesn’t have anything to do with minimum version of msvc needed to compile clang and that’s what the discussion was all about.

Please start a new thread and people will be more than happy to answer your questions. You can also try and search the archive for specific information on how broken the headers are, but I don’t think any sort of wrapping can solve these issues, conforming compiler doesn’t understand their dialect of C++, it’s that simple.

hi. thanks for the response.

“we discussed that and it wasn’t the best approach” is good enough for me for now. I don’t have an immediate need, and the folks who looked at it likely know as much or more than I do about the subject. When I have some time to tinker, I’ll try it and see what I get and/or go dig into the archives to see what was said. if the answer to the question is in the archives, then there is no point to rehashing it. To me, not knowing the history, the two obvious question weren’t being asked…WHAT exactly is “broken" in the headers and CAN it be bypassed with some some preprocessor game-playing?

I wasn’t trying to a jerk. I just did’t like being shut down on what to me is a legitimate issue to hash out.

-James

Your question isn’t actually that clear. What kind of brokenness do you care about? Are you looking for C++ that clang can’t parse, or standard library features that behave incompatibly on Windows? I think you mean the former.

The answer to that question is complicated. It depends on what you want to parse. I’d say there’s several classes of stuff in order of increasing difficulty to parse:- Plain C Windows SDK headers: windows.h

  • MSVC C++ STL headers: vector, string
  • Templateless COM headers: DirectX etc
  • Template libraries: ATL, WRL

The first three classes aren’t that hard to parse. When they use standard language features, they are mostly well-formed. The difficulty in parsing them is that they use lots and lots of language extensions. The basic stuff is dllexport and __stdcall, but it gets harder. There are weird IDL attributes involving square brackets, for example.

The final category is really something all on its own. MSVC’s template model is drastically different from ours. You could hypothetically hack these headers in probably 20 or so places to get them to parse with Clang without any compatibility hacks, but you end up fighting an uphill battle. This is the category that native GUI apps tend to have, while batch processing apps like LLVM can get by with the first three sets.