clang-15: failure tracking, for potential compiler bugs/reversions

[mascguy (Christopher Nielsen)]

Tracking ticket for build failures, when clang-15 is in play. The vast majority of these are likely to be legitimate code issues, caught by stricter validation checks, and/or standards evolution.

However, we may occasionally encounter a legitimate compiler bug. And we'll want to report those to upstream.

Port	Issue
Inkscape	Use of unary_function, no longer available in C++17 and C++20

[mascguy (Christopher Nielsen)]

Edit: comment not relevant

[kencu (Ken)]

inkscape is actually wrong here, and clang-15 is right. gcc-12 currently still allows std::unary_function, but not for long, as it’s announcing it deprecated

​https://github.com/llvm/llvm-project/commit/681cde7dd8b5613dbafc9ca54e0288477f946be3

I have been going through this for many years, as 10.6.8 has traditionally always used the newest clang, and with every new compiler release, things get tighter and codebase errors show up. I also asked a few years ago if we could hang back a few cycles on updating compilers, and leave the work to others — I don’t have to tell you what the response to that request was :)

NO.

So for many years I found and fixed these nearly daily as those on newer systems using older clangs cruised merrily by.

We can use this (defaulting to clang-15 on some systems) as a good method to help upstream keep their codebase correct… macports has traditionally done that frequently.

If you’re taking on too many ports as maintainer, just ease off a bit. You went from zero to about 1000 in six months :)

The crash with darktable now is something different… but I don’t think anyone ever opened up an issue with llvm, so it will not be fixed until they know about it.

[mascguy (Christopher Nielsen)]

Edit: comment not relevant

[Christopher Nielsen <mascguy@…>]

In a66c19532113565c4a73700b3888fa14823c3fc7/macports-ports (master):

inkscape*: blacklist mp-clang-15, until upstream cleanup
See: #65895

[mascguy (Christopher Nielsen)]

First off, I sincerely apologize for the negativity, and pessimistic tone. Ditto for any suggestion that our organization's approach isn't good, as I don't believe that whatsoever. The last thing I want to do is alienate any of you folks, and/or contribute to negativity!

MacPorts has been - and continues to be - an incredibly awesome resource for the community. And I fully support the approach we're taking, as it does benefit upstream projects: By moving forward, we help pay it forward, and assist them with identifying and tackling code issues.

My only thought/suggestion - in the interest of balancing all of that, with the limited time of our maintainers - is this: If there's a way that we can gradually migrate to the latest Clang version - maybe by starting with ports that declare a need for the latest C++ standards (2017+ for example) - that might be something to consider.

After that's been in play for at least a few weeks - or a month - then expand that to C++ 2014 and later. And so on.

Is that a potential compromise that might be worth trying?

[cjones051073 (Chris Jones)]

The list is defined by

​https://github.com/macports/macports-ports/blob/master/_resources/port1.0/compilers/clang_compilers.tcl

So far we have only had this list change depending on os.major, so by OS. I've no idea if given the way this file is used it would be able to read and react to compiler.cxx_standard or compiler.c_standard, but its an interesting idea to try..