It has been introduced in 2011 for gcc compat:
it is probably time to remove it
Actually, I don't think removing -dumpversion is a great idea. it will remove the capability of clang to be a dropped in replacement.
I see a lot of occurrences:
(just in the source of Firefox, I see 6 different usage)
But, based on the github search, I don't think we could reasonably change dumpversion to print 8.0.0, so I'm not sure it really matters. Firefox builds with clang these days, so I'm not sure what they could possibly be using -dumpversion for that would matter.
One concern that I have is that we don't have a replacement for -dumpversion. I thought I saw someone propose adding such a flag, but I can't find it. Basically, we should do something to handle this user's use case:
|83 ↗||(On Diff #207481)|
Maybe "It had been introduced..." or "It was introduced..." instead.
Actually, I think it's worth taking the time to elaborate a bit. Users *will* trip over this, and it's likely that the release notes will become the canonical documentation for it.
Try this text:
- The ``-dumpversion`` flag and the ``__VERSION__`` macro have been removed. Previously they both produced information designed for compatibility with GCC 4.2.1, but that should no longer be necessary. To get clang's version, use the `clang namespaced version macros`_ and ``--version``. _ https://clang.llvm.org/docs/LanguageExtensions.html#builtin-macros
That's true, but users seem to want some programmatic way to extract the compiler version number without having to resort to sed & co, and we don't provide that right now. -dumpversion can easily be the name for that feature.
lgtm, minor changes
|82 ↗||(On Diff #209474)|
I guess move the bullet to the generic "list of changes", since this isn't a flag or option.
|85 ↗||(On Diff #209474)|
|86–87 ↗||(On Diff #209474)|
"Previously this macro was set to a string aiming to achieve compatibility with GCC 4.2.1, but that should no longer be necessary. To get Clang's version..."
This revision breaks python 2.7.16 builds, which are still supported by upstream python for a few more months. I'm preparing a revert.
The file is getcompiler.c:
/* Return the compiler identification, if possible. */
#define COMPILER "\n[GCC " VERSION "]"
#endif /* !COMPILER */
#define COMPILER "[C++]"
#define COMPILER "[C]"
#endif /* !COMPILER */
const char *
From the failure mode I was seeing, any value at all for VERSION will be fine, as long as it is a valid preprocessor string.
It would also solve this particular problem to not define GNUC, but I as that would create other, more severe, problems, as long as clang identifies itself as GNUC, we should maintain compatibility with it.
I just want to point out that this code was already doing the wrong thing. It will report that the compiler is some incorrect version of GCC. After we add VERSION back it will keep doing the wrong thing, which was sort of the point of removing it in the first place: to find such broken code and fix it. In any case, it sounds like it's not worth the effort, so let's just change the value of VERSION instead of removing it.